Insecure Deserialization
Serialization, Marshalling (Ruby) or Pickling (Python).
Serialization is the process of converting complex data structures into a "flatter" format such as a sequential stream of bytes. Deserialization is the process of restoring this byte stream into the original object. Insecure deserialization is when user-controllable data is deserialized by a website. This potentially enables an attacker to manipulate serialized objects in order to pass harmful data into the application code. It can be argued that it is not possible to securely deserialize untrusted input.
Burp Scanner will automatically flag any HTTP messages that appear to contain serialized objects. With Hackvertor, you can modify the serialized data as a string, and it will automatically update the binary data, adjusting the offsets accordingly
Example Serialization
User
object
Methods: serialize()
and unserialize()
O:4:"User"
An object with the 4-character class name "User"
2
The object has 2 attributes
s:4:"name"
The key of the first attribute is the 4-character string "name"
s:6:"carlos"
The value of the first attribute is the 6-character string "carlos"
s:10:"isLoggedIn"
The key of the second attribute is the 10-character string "isLoggedIn"
b:1
The value of the second attribute is the boolean value true
Attacks
Of course you can change the values of the serialized object or create a new one.
Magic Methods
Magic methods are a special subset of methods that you do not have to explicitly invoke. Instead, they are invoked automatically whenever a particular event or scenario occurs. Magic methods are a common feature of object-oriented programming in various languages. They are sometimes indicated by prefixing or surrounding the method name with double-underscores.
(ex. PHP __construct()
, Python __init__
)
Some languages have magic methods that are invoked automatically during the deserialization process. You should pay close attention to any classes that contain these types of magic methods. They allow you to pass data from a serialized object into the website's code before the object is fully deserialized.
If an attacker has access to the source code, they can study all of the available classes in detail. To construct a simple exploit, they would look for classes containing deserialization magic methods, then check whether any of them perform dangerous operations on controllable data. The attacker can then pass in a serialized object of this class to use its magic method for an exploit.
Tools
One such tool for Java deserialization is "ysoserial". This lets you choose one of the provided gadget chains for a library that you think the target application is using, then pass in a command that you want to execute. It then creates an appropriate serialized object based on the selected chain. This still involves a certain amount of trial and error, but it is considerably less labor-intensive than constructing your own gadget chains manually.
In Java versions 15 and below
In Java versions 16 and above
ex.
Not all of the gadget chains in ysoserial enable you to run arbitrary code. Instead, they may be useful for other purposes. For example, you can use the following ones to help you quickly detect insecure deserialization on virtually any server:
The
URLDNS
chain triggers a DNS lookup for a supplied URL. Most importantly, it does not rely on the target application using a specific vulnerable library and works in any known Java version. This makes it the most universal gadget chain for detection purposes. If you spot a serialized object in the traffic, you can try using this gadget chain to generate an object that triggers a DNS interaction with the Burp Collaborator server. If it does, you can be sure that deserialization occurred on your target.JRMPClient
is another universal chain that you can use for initial detection. It causes the server to try establishing a TCP connection to the supplied IP address. Note that you need to provide a raw IP address rather than a hostname. This chain may be useful in environments where all outbound traffic is firewalled, including DNS lookups. You can try generating payloads with two different IP addresses: a local one and a firewalled, external one. If the application responds immediately for a payload with a local address, but hangs for a payload with an external address, causing a delay in the response, this indicates that the gadget chain worked because the server tried to connect to the firewalled address. In this case, the subtle time difference in responses can help you to detect whether deserialization occurs on the server, even in blind cases.
Last updated