From PoC to Shell – CVE-2010-1871

Jul 30th, 2011

Comments: 0
Category: Uncategorized

From PoC to Shell – CVE-2010-1871

I had a chance to look at CVE-2010-1871 recently which is a vulnerability in JBoss expression language.  As it was an interesting looking vulnerability, I thought it’d be worth walking it through to the point of getting a shell on a vulnerable box, and as it took a bit of fiddling and googling on my part to get there, I figured it could be worth writing up.

There’s a good write-up from the guy who discovered the vulnerability here but the basics of the vulnerability is that version of the JBoss SEAM framework have an expression language which can be used to directly execute java code.  (Un)fortuntely it was possible for certain URL parameters passed by users of the application to be executed, which introduces a vulnerability.

In the blog post Meder goes through the process of finding the appropriate java classess and executing code using reflection, so far so good.  When I came to walk through the PoC exploit (creating a directory on the vulnerable server) the last command
/seam-booking/home.seam?actionOutcome=/pwn.xhtml?pwned%3d%23{expressions.getClass().forName('java.lang.Runtime').getDeclaredMethods()[19].invoke(expressions.getClass().forName('java.lang.Runtime').getDeclaredMethods()[7].invoke(null), 'mkdir /tmp/PWNED')}

wasn’t working for me… so Google time 🙂 (NB, the reference to seam-booking/home.seam is for the sample app used for the PoC, but this should work on any SEAM framework app)

Looking round to see if anyone else had any joy with this vuln. I came across a post on Stackoverflow , where it looked like someone was getting targeted with this issue in the wild (one to take note of if you run  JBoss!).  From that it looks like the attackers had come to a slightly different means of exploiting the issue, and testing it seemed to work well.  So the basic PoC is setting the actionOutcome parameter to


This has worked ok for me on Linux and windows (as target platforms).

Great, so now we have a basic PoC how do we move onto getting a full shell on our vulnerable system?  There’s doubtless a number of ways of doing this, but here’s one I hit on which seems to work pretty reliably.

Given that the target server is running a JBoss service, it’s a reasonable assumption that it will have java installed, so we can breakout the Java Meterpreter.  First up create the payload using msfpayload.  I used bind_tcp in the lab and it’s worth noting that the default metasploit port (4444) is in use, so using a different on (eg, 5556) was a good plan.

./msfpayload java/meterpreter/bind_tcp LPORT=5556 X > lin.jar

Gives us our file payload, now we just need to get it deployed to the target system.  On linux, it’s a fair bet that wget will be installed, so I used that to download the file from a webserver


This places the file into /tmp, so now we just need to run it, which is pretty straightforward


Having done that, it’s just a question of spinning up the metasploit exploit handler and connecting to your waiting meterpreter shell.

Add a comment

Your email address will not be shared or published. Required fields are marked *