Next message: bugzillaat_private: "[Full-Disclosure] [RHSA-2003:020-09] Updated kerberos packages fix vulnerability in ftp client"
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://>: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: eitancaspiat_private
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
This archive was generated by hypermail 2b30
: Thu Jan 30 2003 - 13:36:10 PST