[Full-disclosure] Unauthenticated access to IBM Host On-Demand administration pages
SUMMARY Vulnerability found in: IBM WebSphere Host On-Demand (HOD) Type: Unauthorized, remote access to HOD administration pages Applies to: Version 6.0, 7.0, 8.0, and 9.0 (possibly 10.0) Severity Level: High Exploit Difficulty: Very Low Initial Vendor Notification: approximately 11/3/2006 Discovered By: Dave Ferguson, FishNet Security Secunia advisory location: http://secunia.com/advisories/22652 BACKGROUND IBM's WebSphere Host On-Demand (HOD) provides a framework for accessing host applications and data from a Java-enabled web browser. The HOD administration pages consist of a set of Java applets. One applet controls user authentication. Others allow you to start and stop services, manage users, configure telnet redirectors, set up LDAP service, and manage licenses. Information about HOD can be found here: http://www-306.ibm.com/software/webservers/hostondemand. VULNERABILITY OVERVIEW FishNet Security discovered that a remote, unauthenticated user can access and interact with several of the HOD administration applets. Essentially, a simple URL manipulation attack can bypass the authentication and authorization process. This was found in HOD versions 6.0, 7.0, 8.0, and 9.0. Version 10 (released in 2006) may also be vulnerable, but was not tested. DETAILS The applet that handles user authentication is normally located at the following URL: https://server/hod/HODAdmin.html. Once this page loads and the applet is running, the URL showing in the web browser reads something like this: https://server/hod/frameset.html?Java2=true,Obplet=object,cshe=false,pnl=Logon,hgt=480,wth=640,full=fa lse,BrowserLocale=en.there. The web page displays an area for the user to logon and a menu on the left side with several links to other pages/applets. Each of these links is disabled. The links are: - Introduction - Users/Groups - Services - Redirector Service - Directory Service - OS/400 Proxy Server - Licenses - Logoff To bypass the authentication process, you change the value of "pnl" in the current URL. For example, to see the OS/400 Proxy Server page, you would change the pnl parameter from "Logon" to "os400proxy". The page loads and the functionality of the applet appears to be normal in every way. The other links in the menu become enabled, so changing the URL manually is no longer necessary. Two of the pages/applets seem to have additional access control, because the applets remain blank and/or empty and can't be used. Pages that could be accessed in an unauthenticated state: Services, Redirector Service, Directory Service, and OS/400 Proxy Server Pages that could NOT be accessed: Users/Groups and Licenses ATTACK SCENARIOS An attacker can perpetrate a number of actions: - stopping critical HOD services - reconfiguring existing services (e.g., port numbers, ip addresses) - creating and starting unnecessary services - changing the security configuration for redirectors - creating a user to administer the LDAP service Any of these could have an adverse effect on business operations and/or allow a malicious person to open more potential attack vectors. VENDOR RESPONSE Secunia notified IBM about this vulnerability around 11/3/2006. No response has been received. CONTACT You can reach the author of this advisory at: dave.ferguson[at]fishnetsecurity(dot)com ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
RE: [Full-disclosure] Session Token Remains Valid After Logout in IBM Lotus Domino Web Access
Trey, I understand what you mean about a design trade-off. In this case I believe IBM has a conflicting design. They clear the cookie, which makes the user appear to be logged out of all applications. However, they leave the token valid on the server, which doesn’t serve any useful purpose. -Dave From: Trey Keifer [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 12, 2006 11:34 AM To: Ferguson, David Subject: Re: [Full-disclosure] Session Token Remains Valid After Logout in IBM Lotus Domino Web Access > The problem I see is that the user explicitly chose to log out. The issue is when it comes to SSO, you don't know if the user wanted to log out of *that* application or *all applications* and that is the "design tradeoff" I mentioned in my response. Some vendors choose to invalidate all sessions, some make attempts to invalidate the specific instances. It is against best-practices in single-instance application design, but it is an immutable logic problem in SSO application design. The app can't guess what the user intends to do. On 9/12/06, Ferguson, David wrote: The problem I see is that the user explicitly chose to log out. I have tested other SSO applications where if you log out of the application, then the token is invalidated and you become unauthenticated in all of the apps that are part of the SSO group. To me that is the correct behavior. In fact I would say that IBM agrees with that, because their software goes to some extent to delete the cookie from the browser so that if the user tries to access any of the apps after logging out, he is given a login page to re-authenticate. IBM believes it is valid and has released a technote (http://www-1.ibm.com/support/docview.wss?rs=463&uid=swg21245589 ) on the subject. Dave From: Trey Keifer [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 12, 2006 10:58 AM To: Ferguson, David Cc: full-disclosure@lists.grok.org.uk Subject: Re: [Full-disclosure] Session Token Remains Valid After Logout in IBM Lotus Domino Web Access How is this a vulnerability? this is a common design trade-off of SSO tokens. In order to support the user opening and closing multiple applications and not requiring them to login again to individual applications (which is the point of SSO) they must invalidate the token in specific instances while leaving a more encompassing SSO token valid until a defined timeout. You also say you didn't test the difference between SSO mode and "Single Server" mode. It seems to me that this would be a key test, is it possible that this functionality *does* change when the server knows it does not have to worry about session management across multiple instances? Furthermore, this alert requires access to the token (which we are left to make assumptions about since no details on length or algorithm were included) which, unless the application only supports HTTP, is a pretty obvious issue and not even worth reporting. If we include web applications that don't invalidate sessions on the server side as reportable instances of vulnerabilities, then we open the flood-gates for worthless advisories. On 9/12/06, Ferguson, David < [EMAIL PROTECTED]> wrote: I. SYNOPSIS Title: Session Token Remains Valid After Logout in IBM Lotus Domino Web Access 7.0.1 Release Date: 09/12/2006 Affected Application: IBM Lotus Domino Web Access 7.0.1 (versions prior to 7.0.1 were not tested but may still be vulnerable). Nominal Severity: Low Severity If Successfully Exploited: High Impact: Attacker impersonates legitimate user Mitigating Factors: Requires discovery of a valid LtpaToken to exploit. Discovery: Dave Ferguson, Security Consultant, FishNet Security Initial Notification of Vendor: 08/28/2006 Permanent Advisory Location: http://www.fishnetsecurity.com/csirt/disclosure/ibm II. EXECUTIVE SUMMARY Vulnerability Overview: In Lotus Domino Web Access (DWA) 7.0.1, the session token used to identify the user (called "LtpaToken") is not invalidated on the server upon user logout. The cookie is removed from the browser, but the token continues to be recognized by the server until a configurable expiration time is reached. Attack Overview: The most likely attack scenario is session hijacking or session stealing. Knowing a valid session token would allow a malicious person to access all functionality of the web application (except changing password, which requires knowledge of the current password). Lotus DWA is a personal information management application that includes e-mail, calendar, and task management. By hijacking (or stealing) a session, an attacker is able to impersonate a legitimate user, and can read the user's e-mail, send e-mail as the user, or change the user's preference settings. III. TECHNICAL DETAIL Vulnerability Details: When a Lotus DWA user logs in, a cookie called "LtpaToken&qu
[Full-disclosure] Session Token Remains Valid After Logout in IBM Lotus Domino Web Access
I. SYNOPSIS Title: Session Token Remains Valid After Logout in IBM Lotus Domino Web Access 7.0.1 Release Date: 09/12/2006 Affected Application: IBM Lotus Domino Web Access 7.0.1 (versions prior to 7.0.1 were not tested but may still be vulnerable). Nominal Severity: Low Severity If Successfully Exploited: High Impact: Attacker impersonates legitimate user Mitigating Factors: Requires discovery of a valid LtpaToken to exploit. Discovery: Dave Ferguson, Security Consultant, FishNet Security Initial Notification of Vendor: 08/28/2006 Permanent Advisory Location: http://www.fishnetsecurity.com/csirt/disclosure/ibm II. EXECUTIVE SUMMARY Vulnerability Overview: In Lotus Domino Web Access (DWA) 7.0.1, the session token used to identify the user (called "LtpaToken") is not invalidated on the server upon user logout. The cookie is removed from the browser, but the token continues to be recognized by the server until a configurable expiration time is reached. Attack Overview: The most likely attack scenario is session hijacking or session stealing. Knowing a valid session token would allow a malicious person to access all functionality of the web application (except changing password, which requires knowledge of the current password). Lotus DWA is a personal information management application that includes e-mail, calendar, and task management. By hijacking (or stealing) a session, an attacker is able to impersonate a legitimate user, and can read the user's e-mail, send e-mail as the user, or change the user's preference settings. III. TECHNICAL DETAIL Vulnerability Details: When a Lotus DWA user logs in, a cookie called "LtpaToken" is set into the browser and is used throughout the session to uniquely identify the user. When a user logs out of DWA, the cookie is cleared from the browser, but this action has no effect on the server. The token eventually expires on the server after some configurable amount of time. A user who explicitly logs out of DWA may have a false sense of security. The LtpaToken cookie in his browser is deleted, but the token is still valid from the server's perspective and can be used by an attacker if he can discover it. Best practices in web application security would call for the LtpaToken to be invalidated/destroyed at logout time. Note that the vulnerability described here was observed with Session authentication under the Domino Web Engine tab set to "Multiple Servers (SSO)". The same behavior may occur with the "Single Server" configuration as well, but this was not tested. The "LtpaToken" described here is a component in IBM's Lightweight Third-Party Authentication (LTPA) technology. The LTPA technology was designed to be a defacto standard across the IBM product family. LTPA is used in both IBM WebSphere and Lotus Domino products and allows for single sign-on across physical servers. For example, Domino can recognize and accept LTPA tokens created by WebSphere. For more information, please see the IBM redpaper at http://www.redbooks.ibm.com/redpieces/pdfs/redp4104.pdf IV. MITIGATING FACTORS Keeping the LtpaToken confidential is critical to mitigating this issue. An attacker must be able to discover a valid LtpaToken before it expires. Because the LtpaToken is sent with each request, Lotus DWA should be deployed as a secure application. This means an SSL certificate should be installed on the server so that encrypted (https) communication between the browser and the server occurs. Cross-site scripting (XSS) is a common application-level attack that can be used to steal cookies such as LtpaToken. Running the application under SSL does not hinder XSS attacks. Fortunately, Lotus Domino includes a module called Active Content Filter that is highly effective at removing potentially harmful scripts in e-mail messages. Active Content Filtering should be turned on. Finally, the overall risk level can be lowered by enabling an idle session timeout in addition to the absolute expiration time. Ideally, from an application security perspective, the idle (inactivity) timeout would be much smaller than the absolute expiration. Be aware that the increased security from having small timeout values may negatively affect end-user satisfaction in the application. V. VENDOR RECOMMENDED ACTIONS IBM recommends running Lotus DWA run under SSL and using a token expiration time of 30 minutes. Please see IBM technote #1245589: http://www-1.ibm.com/support/docview.wss?rs=463&uid=swg21245589 VI. CONTACT You can reach the author of this advisory at: dave.ferguson[at]fishnetsecurity(dot)com ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
