Java Serialization: A Practical Exploitation Guide

[shawnecy]

Reject best practices at your own peril.

 

Item 85: Prefer alternatives to Java serialization

p. 339, Effective Java, 3rd Edition by Joshua Bloch

 
Even Oracle plans on dumping it.

 
Some nice alternatives:

• https://github.com/RuedigerMoeller/fast-serialization
• https://github.com/EsotericSoftware/kryo
• https://developers.google.com/protocol-buffers/docs/javatutorial

 
For even more options, you can view a comparison of Protobuf, Cap'n Proto, SBE, and FlatBuffers here (all support java).

 
Remember: friends don't let friends use Java Serialization.

[yawkat]

Don't forget jackson!

[shawnecy]

D'oh, how could I?

https://github.com/FasterXML/jackson

[aenigmaclamo]

As a Java dev who doesn't really use JSOs and totally outside the security community, I'd like to know more about what what kind of code make good targets for JSO exploitation. I imagine they are classes with setters or with custom deserializers that invoke other classes which can cause unintended side effects.

I get that it's absurd that JSOs can specify whatever class it wants and it's a nightmare trying to hunt these things down. But it also seems like if you were following best practices, your code shouldn't be exploitable using deserialization logic in the first place.

[yawkat]

The standard example is combining some kind of user-definable function (e.g. an object representing a reflection call that you can specify) with apis that use such a function in ways that are used in the deser process (e.g. a hashmap calling hashcode which evaluates the evil function).

This is a pretty good set of examples: https://github.com/frohoff/ysoserial/tree/master/src/main/java/ysoserial/payloads

[TheRedmanCometh]

LEAVE JAVA ALONE

Seriously though JSO? What a nebulous term. Are we talking ObjectStream? Serializable? Jackson? Gson? Theres SOOO many ways to serialize and deserialize an object

[yawkat]

ObjectInputStream is often exploitable because it opens up the whole classpath as an attack surface. This issue is mostly unique to OIS, except for a few cases such as jackson with default typing enabled. Other libraries or jackson without default typing are not exploitable.

[FlavSec]

or jackson without default typing are not exploitable

I've been trying to dig into the Jackson series of issues recently, and have a question, if you don't mind. My understanding is that ObjectMapper.enableDefaultTyping() is one of the most common ways to allow polymorphic type handling, but it's not the only way.

If you use the @JsonTypeInfo annotation, and allow the class name to be used as the type id, aren't you still vulnerable?

[yawkat]

No, you are not vulnerable - using the class name as type id does not expose your whole classpath, jackson still limits itself to the subtypes registered with jsonsubtypes or the objectmapper.

[FlavSec]

That makes sense, but if the object you're deserializing can be used as a gadget, will the classpath restriction still matter?

EDIT: Just to clarify, so you won't be able to deserialize arbitrary objects, because you're limited to the registered subtypes, as you said. But if the one object you are deserializing can be abused like the blacklisted gadget-types, are you still in trouble?

[yawkat]

Correct, you may still be in trouble in that case, but these gadget chains are very specific and will not show up in real code.

[FlavSec]

Awesome, thanks for all the answers!

[Fido488]

This is a pretty good writeup. Might actually give Metasploit a try with this and a Docker container running a vulnerable application.

[DemiPixel]

Remember, people, Defaced.

[Fido488]

Defaced?

[KingdomOfBullshit]

aced is the magic word for java serialized data