Have you read my last advisory about the HP Intelligent Management Center v5.1 E0202 topoContent.jsf Non-Persistent Cross-Site Scripting Vulnerability ? You should do! Taken by itself it’s not even an interesting vulnerability. But! You’re able to use this XSS flaw to bypass the weak implementation of the JSF javax.faces.ViewState Cross-Site Request Forgery Protection (which is used throughout the whole application) to add a new administrator to the IMC backend.
The issue has been fixed in the latest version of the IMC (v5.2 E401) - at this point I would like to thank the HP SSRT for their professional collaboration during the disclosure process!
The following demonstration should show why you should avoid using the JSF 1.x implementation of javax.faces.ViewState and also why it is important to avoid XSS flaws in general. Let’s analyse the vulnerability:
Looks like a simple XSS vulnerability, which is by the way only exploitable if the victim is logged into the IMC, which reduces the attack surface but with some Bob-Alice-like social engineering it should be possible anyways ;-)
Let’s have a look at the interesting part of the IMC - the user management:
Simple, eh ? Have a look at what happens when you post the form:
Now things are getting much more interesting. It looks like HP uses the weak implementation of the javax.faces.ViewState CSRF protection, which uses only an incremental value (in JSF 1.x - JSF >2.1 for example uses a much more complex value which is impossible to guess) as the id which is inserted into every form. This makes it quite easy for an attacker to guess or predict the next value, if he’s able to access the value using another flaw - like a XSS :-)
How to fetch the ViewState value ?:
It consists of different parts. First: the most important part. The Iframe loads the operatorList.jsf page which contains the ViewState variable.
The document.write function outputs the more complex part:
This part accesses the created Iframe and reads the javax.faces.ViewState value using the getElementsByName function. The output looks like:
Great this is the ViewState value :-)
Now the “stolen” value could be handed over to a third-party script like:
which embeds a simple link including the “substr’ed” ViewState value :
Since you’re able to read and steal the ViewState value, you can do whatever you want on your script-side. But the goal is to add another operator to the IMC database. So the following small PHP script will do the job:
First the ViewState value is put into the $id variable. Because you cannot be 100% sure that the ViewState does not change through the whole process, you can place a simple for-loop around the static part, which allows you to submit the form x-times using different incremental and decremental values for the ViewState value. Yes, this is not very silent because it opens some new tabs:
but anyways…the new administrator is finally added, if you have a look at the User-Management page again:
This might also be done silently….but it’s more important to show that you should be careful in the www especially when clicking on third-party links ;-).