Insecure deserialization prevention simplified

After starting to use the object-oriented development concept, new types of vulnerabilities were born. Insecure deserialization vulnerabilities were one of those vulnerabilities. Therefore, what is an Insecure Deserialization vulnerability, and how to prevent it?

Insecure deserialization vulnerability happens when the web application serializes or deserializes a user-controllable object. The main idea of this attack is to manipulate the execution flow of the application to perform malicious actions.

To prevent the insecure deserialization vulnerability, the developers should avoid serializing or deserializing user’s controllable objects as no filtering technique is known to be 100% safe.

Before we start analyzing this vulnerability, you will to first understand the concept of serialization and deserialization. Therefore, in the next section, we will explain what does serialization means and why it is so important in modern applications.

What is Serialization and Deserialization?

Serialization is the process of transforming a binary complex object into a simple format that can be transferred and easily manipulated. On the other hand, Deserialization is the opposite action, where this simple format is interpreted by the programing language to forge an actual binary object.

Web application functionalities are growing every day which has made source code more complex and created a need for object saving and reusing. Therefore, by using the oriented object programming techniques a new concept was created called serialization and deserialization to solve this problem.

By serializing an object, this one can be saved in a file system to be used again with the same or different program or even sent to another computer with a network connection. What makes this concept even more important is the fact that the serialized objects are platform-independent. Therefore, an object created and manipulated in host 1 will still be the same when transferred to host 2 even if they don’t use the same architecture.

Here is an examples of Serialized objects with different languages:

• PHP

The following object:

$user->name="john";
$user->age=23;

After a serialization become:

O:8:"stdClass":2:{s:4:"name";s:4:"john";s:3:"age";i:23;}

• JAVA

The following object:

class TestSerial implements Serializable {
  public byte version = 100;
  public byte count = 0;
}

After a serialization become:

AC ED 00 05 73 72 00 0A 53 65 72 69 61 6C 54 65
73 74 A0 0C 34 00 FE B1 DD F9 02 00 02 42 00 05
63 6F 75 6E 74 42 00 07 76 65 72 73 69 6F 6E 78
70 00 64

In general, all JAVA serialization starts with “AC ED” hex code, called stream magic code that indicates a start of serialization protocol.

How do deserialization attack work?

The Deserialization vulnerability could be exploited with many very different techniques. Therefore, the way the attack work, change from one situation to another. However, the idea behind this attack is to control the execution flow of the app to execute a dangerous object function that leads to a malicious impact on the server, like RCE or file deleting … etc.

To control the execution flow of the application, the attacker can:

1. Modify the deserialized object parameters and values he has to bypass for example security controls.

Let’s suppose we have a $user object with the following values:

$user->username=user1
$user->userage=10
$user->userAdmin=False

The attacker can then modify this object userAdmin value and send it back to the application to get admin privileges. This scenario is not very common on the web. However, it is still a way to exploit this vulnerability.

• Use application functionalities to cause serious damages on the applications by modifying the serialized object to point onto different information.

For example, let’s suppose that there is one more parameter in the same object already discussed:

$user->username=user1
$user->userage=10
$user->userAdmin=False
$user->userImage=”/images/user1.jpg”

By changing the userImage path, the attacker will be able to delete the victim image if there is any functionality in the server that gives it the possibility to remove his picture.

• Forge an object with a whole different class that already exists in the app and has a dangerous functions called using magic methods

Magic methods are a type of function that gets called automatically when for example an object gets created or destructed. Many developers recreate those method to define what should be done when that object, for example, get created.

The magic methods are not a vulnerability on their own, but the code written by developers that handle user’s controllable data in those redefined methods is what makes them critical.

• Use what we call Gadget chain

A Gadget is simply a small part of code in the application that can be used to perform some malicious actions. Usually, those small parts of code are not harmful. However, they are used by attackers to only pass controllable data from one part of the code to another sensitive portion of the code.

Chaining multiple parts of the codes is what makes this attack possible. This technique is usually, impossible or at least very difficult to be used without access to the source code of the attacked application.

However, many already developed tools exist that can help exploit this vulnerability by providing some already discovered gadgets without the need to access source code. Moreover, some popular gadgets are already documented in publicly published exploits and can be adapted for specific situations.

I will not get into how the exploitation of this attack is performed, as this is not the objective of this blog post. However, the techniques that I have mentioned here are not easy to perform and will require a high level of knowledge and testing to successfully create the exploit.

Object injection vs. insecure deserialization

Object injection is a technique used to exploit the insecure deserialization vulnerability. The main idea of this technique is to forge a not-expected object and send it back to the application deserialization function. I have already explained this technique in the previous section of this blog post point 3.

This technique represents the base idea to exploit the insecure deserialization technique. Basically, most critical insecure deserialization vulnerabilities that were discovered in history did use this technique to get remote code execution.

How to prevent the insecure Deserialization attack?

Unfortunately, many peoples think that filtering is the key to fix this issue. In addition, most of those filtering techniques are made after the deserialization is made.

Filtering the user data after the deserialization has ended is in general too late. Most insecure deserialization attacks would have been already executed and successfully exploited the vulnerability before the deserialization process finish. This usually happens due to the use of magic methods gadget chain that gets executed during the deserialization process.

The best way to prevent the insecure deserialization vulnerability is by avoiding using the user’s controllable data in the serialization or deserialization functions. The serialization and deserialization functions are not vulnerable on their own, but they were not designed to deal with user’s controllable data.

However, if using the user’s controllable data is inevitable, then a verification process should be performed before sending the object to the deserialization or serialization. Here is the list of checks you should perform before, during, and after the deserialization process:

• Verifying the integrity of the object you have received, to check if there is any parameters tempering. This can be done using a private key that can be stored in the server and used as a key for signing your objects.
• Isolating the deserialization portion of code and running it with the most low privileges will also reduce the risk of any intrusion, if this vulnerability was exploited.
• Logging all the errors and exceptions generated by the deserializarion process for further analysis in case of a problem.

Logging and monitoring any kind of critical code in your app, should always be performed. Moreover, this process should cover all parts of the application environment and a full team should supervise it and alert the responsible whenever a critical event happens.

Is insecure Deserialization a common vulnerability ?

In big and complex applications, where multiple APIs and devices communicate together, insecure deserialization is very common. However, when dealing with small websites and small web applications in general, the serialization process is rarely used. Therefore, the insecure deserialization vulnerability is not common.

In my personal opinion, the risk of this vulnerability compared to for example an SQL injection or even an XSS is very low. Unless this vulnerability gets discovered in a popular solution and the exploit is already developed. I say that because the level of knowledge required from a penetration tester or a hacker and the time needed to develop the exploit for this vulnerability is very high.

In addition, most discovered insecure deserialization vulnerabilities discovered on the internet have required access to source code to be able to develop a working exploit. (that’s why I always recommend new penetration tester to learn and master coding even if it is not required, for more details about this subject I invite you to take a look at this blog post)

Therefore, developing an exploit while doing a blackbox attack or blackbox penetration test is even harder and time-consuming.

However, this does not means you don’t have to fix the issue if you discover it in your application. I am just giving this information in case you do a risk analysis to see what vulnerability you should prioritize and what you want to accept it risk.

Popular solutions that was vulnerable to the insecure deserialization

As I said, this vulnerability is very common among complex applications. Here is a list of some popular solutions that was the victim of such vulnerability:

• CVE-2018-2628

The first vulnerability that I want to talk about was discovered in 2018 in the Oracle WebLogic Server. Successful exploitation of this vulnerability was giving the attacker the ability to take control over the victim server due to remote code execution.

For those who don’t have an idea about oracle WebLogic server, Oracle WebLogic Server is the industry-leading application server for building enterprise applications using Java EE standards and deploying them on a reliable, scalable runtime with low cost of ownership.

Unfortunately, this vulnerability does not require any authentication to be exploited and its exploit was publicly released.

For more details you can visit the following URL:

https://support.ixiacom.com/strikes/exploits/webapp/exec/cve_2018_2628_oracle_weblogic_server_deserialization_rce.xml

• CVE-2015-8103

Another critical insecure deserialization vulnerability was discovered in the Jenkins CLI, which gives an unauthenticated attacker, to successfully perform remote code execution on it. This vulnerability was related to a problematic webapps/ROOT/WEB-INF/lib/commons-collections-*.jar file and the “Groovy variant in ‘ysoserial'”.

Unfortunately, the exploit was released and a Metasploit module was developed, which made it even easier to be exploited (a matter of clicks).

For those who don’t know this tool, Jenkins is one of the most popular open-source automation solutions. This tool help developers reliably build, test, and deploy their software. It is also the most used in the DEVSECOPS environments.

You should know that a compromise of such tools, opens the door for a whole new attack type called supply chain which is even worst and very difficult to detect.

For more details about this vulnerability, you can visit the following URL:

https://www.jenkins.io/blog/2015/11/06/mitigating-unauthenticated-remote-code-execution-0-day-in-jenkins-cli/