Java Deserialize Request Headers

I saw an interesting HTTP request in some web traffic. Normally when you see a web request you see the method as GET or POST for example. In this case it said t3 which doesn't seem normal?

t3 12.2.1
AS: 255
HL: 19
MS: 10000000
PU: t3://us-l-breens:7001


After some quick google searching I found a link to an exploit written in python that appears to be this exact HTTP request. So what is it? Well t3 appears to be a protocol used by Oracle for Java remote method invocation. Oh boy, that doesn't sound good. In general it's used to transport data between WebLogic Server and other Java programs. I believe that 12.2.1 is the weblogic version number. I believe AS: 255 is the abbreviation size (although not sure what that means) and HL: 19 is the header length. I'm wondering if MS: 10000000 might stand for message size although I couldn't confirm that? And PU: t3://us-l-breens:7001 I believe might be the proxy url? The us-l-breens is the name of the server (in this case it's the security researcher's [Stephen Breen] local server name), but from what I read it appears the exploit works no matter what you pass in.

It appears to be related to the Java Unserialize vulnerabilities in Oracle WebLogic. At a high level, that means that Oracle WebLogic uses the Java language, and somewhere in Oracle WebLogic it is listening for some serialized user input. When it receives that serialized user input in a flat string format it tries to deserialize that string into a nicer, cleaner, Java programming object/class. The problem was that Java doesn't correctly handle or deserialize some inputs and it can be used for remote code execution.

The python script linked above appears to connect to a particular vulnerable server and port , pass the headers in bold above to establish a connection (sock.sendall). Once the connection is established (sock.recv), the script concatenates the exploit payload (to trigger the deserialize issue) with the desired payload to be executed on the the server (your evil code) and sends that to the open connection (sock.send). See this blog for more details on the vulnerability.

Although this vulnerability is getting old now and you should've already patched it, its again interesting to see that there are still plenty of scanners out there looking for unpatched victims they can exploit.

More about neonprimetime

• neonprimetime pastebin
• neonprimetime virustotal
• @neonprimetime twitter
• neonprimetime reddit

Top Blogs of all-time

1. pagerank botnet sql injection walk-thru
2. DOM XSS 101 Walk-Through
3. An Invoice email and a Hot mess of Java

Top Github Contributions

1. Qualys Scantronitor 2.0

Copyright © 2016, this post cannot be reproduced or retransmitted in any form without reference to the original post.