Proof of concept exploit, showing how to do bytecode injection through untrusted deserialization.

Proof of concept exploit, showing how to do bytecode injection through untrusted deserialization.

Spring framework is commonly used 3rd party library used by many java server projects. If spring-tx.jar, spring-commons.jar and javax.transaction-api.jar are in your class path, and you use RMI, JMS, IIOP or any other untrusted java deserialization you are vulnerable to this RCE exploit.
Spring maintainer Pivotal rejected my report on this issue, with the argument that the problem lies in the untrusted deserialization, so this issue remains unpatched.

JtaTransactionManager
+ spring-tx.jar contains a class named org.springframework.transaction.jta.JtaTransactionManager which is vulnerable to the JNDI deserialization issue described in my last post.
+ The readObject() method ends up in a chain looking like the following initUserTransactionAndTransactionManager()->initUserTransactionAndTransactionManager()-> JndiTemplate.lookup()->InitialContext.lookup(), where the argument to the InitialContextLookup() call is userTransactionName which we are able to control.
+ All we have to do is to create JtaTransactionManager object, set the userTransactionName to a RMI string pointing back to our own RMI Registry and send the object to a vulnerable server. The RMI string would look something like “rmi://x.x.x.x:1099/Object”

Server

Server

Client FIle

Client FIle

Running the PoC
To build and run the server run the following:

Source: http://zerothoughts.tumblr.com/post/137831000514/spring-framework-deserialization-rce