Insecure Deserialization - TryHackMe - OWASP top 10 series

Hi all, In this series I am not covering all the TOP 10 but I am planning to cover the difficult and new ones at this point but soon I will also have a blog on the most popular ones too. Lets start than

Insecure Deserialization is a vulnerability which occurs when untrusted data is used to abuse the logic of an application. Simply, insecure deserialization is replacing data processed by an application with malicious code; allowing anything from DoS (Denial of Service) to RCE (Remote Code Execution) that the attacker can use to gain a foothold in a penetration testing scenario.

Ultimately, any application that stores or fetches data where there are no validations or integrity checks in place for the data queried or retained. A few examples of applications of this nature are:

·         E-Commerce Sites

·         Forums

·         API's

·         Application Runtimes (Tomcat, Jenkins, Jboss, etc)

A prominent element of object-oriented programming (OOP), objects are made up of two things:

• State
•  Behaviour

Simply, objects allow you to create similar lines of code without having to do the legwork of writing the same lines of code again.

For example, a lamp would be a good object. Lamps can have different types of bulbs, this would be their state, as well as being on/off - their behaviour!

Rather than having to accommodate every type of bulb and whether that specific lamp is on or off, you can use methods to simply alter the state and behaviour of the lamp.

What Does Serialization and Deserialization mean?

Serialisation is the process of converting objects used in programming into simpler, compatible formatting for transmitting between systems or networks for further processing or storage.

 Alternatively, deserialisation is the reverse of this; converting serialised information into their complex form - an object that the application will understand.

Let’s consider an example to understand the process.

Say you have a password of "password123" from a program that needs to be stored in a database on another system. To travel across a network this string/output needs to be converted to binary. Of course, the password needs to be stored as "password123" and not its binary notation. Once this reaches the database, it is converted or deserialized back into "password123" so it can be stored.

Simply, insecure deserialization occurs when data from an untrusted party/user gets executed because there is no filtering or input validation; the system assumes that the data is trustworthy and will execute it no holds barred.

Let’s take an instance from the TryHackMe labs and start working on it and exploit the insecure deserialization vulnerability

Step 1: Access the application and create a demo account to access the functionality of the application

  

Step 2: A demo account is created and after the creation of the demo account we do check what data is present in the cookies present by using inspect element.

Step 3: After Inspecting the cookie values, we were able to see that the user sensitive data is provided in the cookie values. The session ID data that is provided is a base 64 data which will provide the First flag. The “userType” cookie help us to know what kind of the user permissions are provided for the user to access the application.

            What if we can change the user to be an admin of the application? Let’s try to be an admin.

Step 4: Change the “userType” cookie value to “admin” and modify the URL to /admin. And try accessing the admin page. And you find your second flag on the UI. As here we can see that the server is accepting the cookie values that are provided by the malicious user with out validating. So, as per the definition “Insecure Deserialization is a vulnerability which occurs when untrusted data is used to abuse the logic of an application”.

Step 5: Let’s Try performing a more Nefarious attack than just changing the cookies to know about the infamous Insecure Deserialization attack. Now change the “userType” cookie value and traverse to /myprofile page and access the “Exchange your vim” module.

Step 6: After this click on “Provide your feedback!” and you are redirected to a form. Where any comments can be written. Now let’s understand the situation and try to think what makes this feature vulnerable.

When we click on the “Exchange your vim” option a cookie is encoded and stored in the browser which is perfect for us to modify. And when we click on the feedback form the cookie data is decoded then deserialized. This Vulnerability exploits Python Pickle. A link to understand this issue is provided in the end of the blog.

Now let’s start exploiting this feature to get RCE on the server.

Step 7: Because the code being deserialized is from a base64 format, we cannot just simply spawn a reverse shell. We must encode our own commands in base64 so that the malicious code will be executed. 

From the code above we can see that a reverse shell is created, and the IP of the system where the VPN is running is provided and the PORT where we can listen is provided. And after this the malicious code is converted into the base 64 data

Step 8: Initiate netcat and start listening on port 4444.
 

Copy the Highlighted payload and paste it into the “encodedPayload” cookie data and refresh the webpage.

Step 9: We can see on the netcat tab that we have received a connection on the port 4444. By using it we were able to fetch the flag.

Summary: By completion of the lab provided by TryHackMe on Insecure Deserialization. The points to remember while testing for Insecure Deserialization bugs are :

1. Check for where the application does not validate the user provided input.

2. Depending upon the function and the functionality where the user input is not validated the severity of the issue can vary.

3. The Vulnerability can only be executed if the user provided unvalidated input persists/stores on the server.

Remediation for Insecure Deserialization.

• Implementing integrity checks such as digital signatures on any serialized objects to prevent hostile object creation or data tampering.

• Enforcing strict type constraints during deserialization before object creation as the code typically expects a definable set of classes. Bypasses to this technique have been demonstrated, so reliance solely on this is not advisable.

• Isolating and running code that deserializes in low privilege environments when possible.

• Logging deserialization exceptions and failures, such as where the incoming type is not the expected type, or the deserialization throws exceptions.

• Restricting or monitoring incoming and outgoing network connectivity from containers or servers that deserialize.

• Monitoring deserialization, alerting if a user deserializes constantly.

Thats all Folks!!!!!