Suggested Risk Level: Medium (many conditions must be fulfilled to reach exploit but results can be destructive) Types of Risk: HTTP SSL session re-use, information disclosure, gain access and control, manipulation of key management information and destructive actions (as server reboot). Affected Hardware / Software: Server side: Compaq Web Agent Service 6.0.0.0 using Compaq HTTP Server 5.1.0 on Windows 2000 Server with SP3 "Compaq Web Agent" related configuration: Settings -> http server -> options: Anonymous access: 0 Local Access: 0 Logging: 1 -> Security Error: 1 -> Security Information: 1 Client Side: Internet Explorer 6.0 with SP1 on Windows 2000 Professional with SP3 or on Windows 95 Local / Remote activated: Local and Remote Description: Compaq (Now HP) enables the management and monitoring of its "Proliant" servers via a secured HTTP session (SSL) from a browser client, either locally or remotely. The component that setup and manages this is called "Compaq Web Agent" and it has its own HTTP server (This agent is installed as a sub-component of "Foundation agents for windows" component / service). If a user has completed successfully a login into the "Compaq web agent" via a legitimate authenticated SSL session - if he closes the session by closing the browser (which is the regular habit of closing a browser session) and NOT by clicking the "Logout" link - over the next time(s) (within a 15 minutes limit) the user (or anyone logged in using the user's profile from the same client IP address / machine) is opening the same base URL (i.e. http://<server_name>:2301 (which automatically redirected into a secured SSL (https) session) - the user is not presented with the regular login form, but rather the user is entered directly into the "already logged-in" session, and with the same privileges that have been granted during the last login. This behavior is consistent for 15 minutes - which after it looks like the HTTP server is terminating the session and thus presents the regular login form. Reboot of the client machine is not solving this issue. Restarting the "Compaq Web Agent" or any other Compaq service on the serving machine did NOT solve this issue. Only restarting the whole machine of the serving server eliminated the problem (I guess due to cleanup of the sessions table held by the Compaq HTTP Server). I have tried to "steal the session" to be used by another user on the same machine, by copying cookies and history folders - but this did NOT succeed. Maybe someone more skilled about this issues will be able to do it - this needs to be further looked into. Just as a test - the same procedures have been tested against an "Insight Manager 7" (SP 1.2) session - and in this case there was NO problem and the login form of "Insight Manager 7" was displayed even if the browser was closed from the browser interface and not using the "Logout" application link. An expansion of this issue: An admin using "Compaq Insight Manager 7" (Proliant servers web based management application, following "CIM 7") is able to open a "Compaq web agent" sessions from within CIM 7 if the server browsed is configured to trust the CIM 7 installation IP address - even if the machine from which the admin started the browsing to the CIM 7 machine is NOT trusted by the installation of the specific server running the "Compaq web agent". The CIM 7 is the one counted as the session origin and thus it is allowed to be logged in automatically, with no authentication form (CIM 7 is authenticating the admin when he first logs into CIM 7 as a container). Now, if the admin performed the above, and then closed the browser showing CIM 7 (method of closing is not relevant here) - he (or anyone using its profile from the same IP address within 15 minutes) is able to get an automatic "already logged-in" session to the "Compaq web agent" session of the managed server, from his own workstation - even if the IP address of his workstation is NOT included within the list that limits the IP addresses allowed to conduct a management session to the server using the "Compaq Web Agent". It looks like the HTTP server is still relying on the session opened from within CIM 7 and somehow it is granting an implied trust over to the machine of the admin and thus do not perform the source IP address restriction check. Possible Abuses: The web agent enables login using 3 types of pre-defined and built-in users roles, the most privileged is "Administrator". "Administrator" can view and change the OS's SNMP configuration, reboot the remote machine and such. This vulnerability can be exploited by anyone with access to local OS session (on the client browser side) that uses the same profile that was used during the browser session to the web agent, and this within a time frame of 15 minutes after the closing of the browser (as long as the server was not rebooted). Possible scenarios (with either method: direct session to the target server of re-using the session made via CIM 7 session): 1. An admin who forgot to lock its OS desktop session or log out of his workstation's / server OS session after closing the browser. 2. An admin who made a web agent browser session from a regular worker's desktop with that user's profile (since the admin relied on the login form to re-appear in the next browser session) and simply closed the browser when he finished his work. locking the OS desktop session is not possible in windows 95, and sometime it is even configured not to do a "log out" process (when no domain login is performed) and can even use a common profile for all the local users. Risks: Maximum risk as Administrator: 1. Change password for the current logged in role 2. Allow anonymous access to the agent session 3. Allow local access (as anonymous or as administrator) 4. Configuring the agent security logging mechanism 5. Configuring the agent allowed source IP addresses restrictions and trust mode 6. Read, change, add and delete all the OS's SNMP values 7. Reboot of the machine being monitored (if enabled by the agents configuration) - choosing "reboot to utils" will not boot back to the OS but rather to the Proliant's boot utilities 8. Manipulate the server management agents and software settings (including enabling remote access to the server by dial-up, if the remote utilities and / or hardware is installed) Exploit Code: No code is necessary. Direct resolution: Not at the moment, Planned by the vendor. Workarounds: 1. Always use the "logout" link from within the web session - This way any further session will be prompted with the login form. This solution is efficient but hard to remember to implement since experienced users tend to close the browser as a whole and not use the "logout" unique method. This is especially true when working from within a CIM 7 session that is not "encouraging" a logout of each server session, but rather encourages a "flow" of links clicks within the CIM 7 interface envelope. Also, the version control agent browser session is opened in a new windows that doesn't have a "logout" link. 2. Don't open "Compaq web agent" or CIM 7 sessions from machines that are not a formal management / admin machines that are secured (physically or logically using log out procedures and interface locking). 3. Remember to make an OS "log out" or interface locking of the machine from which you did the browser session - to block access to the profile. Vendor Notification: The vendor (HP) was notified of this issues and here are the responses: Regarding the main issue: "If I understand this correctly, this is known and "as designed". What I understand this to mean is: I have logged into a web-managed device, then walk away from the browser WITHOUT LOGGING OUT. In this case, any hacker who can physically walk up to my machine (browser client) within 15 minutes can use my login session. This is known. The user is required to logout from the web-managed device before physically leaving his/her browser machine. Alternatively to logging out, the user must sit at the machine for 15 minutes while the session times out, or, in the latest version we are working on, simply close the browser without logging out (In the latest version of HP HTTP Server, the session cookie is stored in memory, and dies when the browser is closed. I believe IM7 already works like this). Following the response regarding the expanded issue (no source IP check is performed if the session is started from CIM 7 and then re-accesses from the admin's machine), and I think it is not fully answering my claims: "Yes. When a session is created, it is good for 15 minutes unless the user logs out. In the latest version (HP HTTP Server 5.3) this is not a problem as long as the browser is closed. Of course the admin could just Logout before physically leaving his/her browser client." Credit: Eitan Caspi Israel Email: eitancaspi@yahoo.com Past Security Notes and articles: 1. http://online.securityfocus.com/bid/4053 http://www.microsoft.com/technet/treeview/default.asp?url=/technet/secur ity/bulletin/MS02-003.asp http://support.microsoft.com/default.aspx?scid=KB;en-us;315085&; 2. http://online.securityfocus.com/bid/5972 http://online.securityfocus.com/archive/1/295341 http://support.microsoft.com/default.aspx?scid=kb;en-us;Q329350 3. http://online.securityfocus.com/bid/6280 You can also find articles I have written in http://www.themarker.com/eng/archive/one.jhtml (filters: Author = Eitan Caspi (in the second name set), From year = 1999) Regards, Eitan Caspi Israel
