Archive for November, 2012

Droppin 0day, 5 years too late…

November 9th, 2012 No comments

We all have it on our networks – old software that just won’t go away. Somebody bought it to do a specific function, but that person left or the software didn’t work or add enough value to keep up with maintenance or upgrades. But yet it sits and festers on the network. It very well may be a niche product that security researchers don’t bother looking at. But one day, for some reason, you as the security guy end up finding it, looking at it, and dropping 0day on it – 5 years after the software was released and 3 versions behind the current release.

So how do we handle this kind of stuff? One question may be what is the chance that the vulnerability has been carried forward through the various releases to the current version. At this point it’s a long-standing 0day and congrats, you can make software better! Go report that shit. But let’s say it doesn’t, the vuln (if it was ever even found) no longer exists in recent versions. If reported to the vendor, most likely they will just say ‘Upgrade to the latest version’. Why would they bother creating a patch for a non-supported, non-current software package used in a niche market? So back to the question of what to do with your 5-year old 0day. Do we just release exploits/disclosure for an unpatched vulnerability into the wild under the pretenses that a patch exists, namely the next version of the software?

Here’s my feelings on this – someone made a decision not to upgrade that software. Maybe it was running just fine and they felt they could use those funds for something more productive. Maybe they just didn’t pay attention to what was on their network. I don’t think in either case your 0day is going to convince these people to pay for that upgrade (assuming that this is a commercial product). But maybe that vulnerability, in the hands of the internal security or external auditors, might be able to help sway decision makers to either transition away from that software or upgrade it. Keeping it to yourself doesn’t really do anything to advance the cause. So in that vein, here’s my 5-year old 0day, droppin’ it hardc0r3….

HP Mercury Quality Center 9.2 Directory Traversal Vulnerability

A directory traversal vulnerability exists within a JBoss component of HP Mercury Quality Center 9.2 that allows for the exfilatration of arbitrary files. It appears that this component runs as a local privileged user by default, so most anything should be up for grabs.

Tested only on version 9.2 running on the Windows platform.

Test Case

 GET ..\..\..\..\..\..\..\..\..\..\windows\system32\drivers\etc\hosts HTTP/1.1
 Host: <host>:8083
 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:12.0) Gecko/20100101 Firefox/12.0
 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
 Accept-Language: en-US,en;q=0.5
 Accept-Encoding: gzip, deflate
 Proxy-Connection: keep-alive

The offending service, launched by the ‘QCJavaService.exe’ service, appears to be a JBoss component. The directory traversal string must be sent unencoded and therefore is not generally accessible through a browser, but the attached Metasploit module or a raw HTTP interface like BURP or handwritten HTTP packets sent through telnet or netcat will work as well. I was not able to determine whether this was an issue within JBoss or how HP/Mercury is deploying JBoss.

Metasploit code completely taken from sinn3r’s Yaws HTTP Traversal module. Total props for the code.

Metasploit Module: