Threat Analaysis

Welcome to Insecure Deserialization session. In this first part, we will focus on threat analysis. We will take our time to discuss what serialization and deserialization is. Then we will discuss how the system can be harmed, the impact of successful exploitation, and give you some insights to identify who may want to harm your system. Let’s start with serialization, the process of turning some object into a data format that can be restored later. Usually, this is done in order to save objects to storage or to send them as part of communications. Some programming languages have native support for serialization and deserialization, but others require external libraries to do it.

Since PHP supports it natively, we will discuss the topic using some PHP snippets, but keep in mind, I’m not saying that PHP is less secure than any other programming language. So on the left, we have the person class definition. It has a private property called name, and a public constructor which accepts a name to be passed as argument to set the private property. Instances of person will be able to bring their name, calling it display underscore name method. Then we have a class instance whose name is Paulo. Finally, we serialize our instance.

This means that, later on, we may want to recreate our person instance exactly as it is now with the same name and being able to call the display underscore name method to get it printed. And this is our serialized instance ready to be stored or shared through some communication channel. Take your time to figure out the format. PHP uses a mostly human readable string format with letters representing the data type and numbers representing the length of each entry. When we want to rebuild person instance from its textual representation, then we need deserialization; the reverse of serialization process, taking data structured from some format and rebuilding it into an object.

If we want to deserialize custom object like our person class, then you need to have its definition. PHP provides an unserialize function to do it. It takes a textual representation, parses it, and creates an instance of a person based on the information retrieved from that representation– all this out of the box with a single line of code. Very convenient, right? The problem is the unserialize function did it all based on what was stored in the storable data variable. A new person instance was created because that was the object type in the textual representation after deleting capital O and number 6.

If the value of storable data variable is something attackers can control, for example, a cookie value, then they can create instances of any other available class providing a valid string according to PHP serialization formats. Any source of user controlled data which is deserialized by the application represents an attack vector. Typically, serialized data is stored client side in cookies or local storage and later sent on subsequent requests in request headers or body. If attackers can tamper such values, then they might be able to compromise the application. Serialized values are commonly stored in databases– for example, session objects– or exchanged between integrated services. Exploiting deserialization, attackers might be able to access arbitrary files.

Imagine that custom deserialization loads some files from file system based on provided path. Quite often, serialized data includes roles or privileged details. Modifying serialized data may allow attackers to escalate their privileges. In some cases, special crafted serialized objects may cause denial-of-services during deserialization. Circular references are good candidates to exploit it. In some cases, remote code execution might be possible, allowing attackers to gain control over the system. Technical skills are required to exploit insecure deserialization. Off the shelf exploits rarely work, requiring changes or tweaks to the underlying exploit code. Based on successful exploitation impact, threats agents may be after sensitive information or gain control over the system. Knowledge about the system internals will greatly help attackers exploit insecure deserialization.

You’ll find this table in the OWASP Top 10. Pause the video and take your time to carefully read it. In the next part, we will exploit insecure deserialization on our intentionally vulnerable application.