Insecure Deserialization Lab 2 : Modifying serialized data types (Privilege Escalation Technique using PHP Data Comparision Concept)

Access Lab : https://portswigger.net/web-security/deserialization/exploiting/lab-deserialization-modifying-serialized-data-types

Understanding the Concept

In PHP, there’s a risky behavior involving the loose comparison operator (==) when dealing with different data types. Let’s break it down:

1. Loose Comparison Oddity: When you compare an integer with a string using ==, PHP tries to turn the string into an integer. So, 5 == “5” is true because PHP sees “5” as the number 5.
2. Starting with a Number: This gets stranger when you have an alphanumeric string starting with a number. PHP just looks at the number and ignores the rest. So, 5 == “5 of something” is treated as 5 == 5.
3. String vs. 0: Even comparing a string to the integer 0 can be surprising. If the string doesn’t have any numerals, PHP sees it as 0. So, 0 == “Example string” is true.

Now, let’s think about a scenario where we’re dealing with user data from deserialized objects:

$login = unserialize($_COOKIE);
if ($login['password'] == $password) {
    // log in successfully
}

Here, an attacker could mess with the password attribute to contain the integer 0 instead of a string. As long as the stored password doesn’t start with a number, the condition would always be true, letting them bypass authentication.

This only works because deserialization keeps the data type intact. If the password were directly fetched from the request, the integer 0 would become a string, and the condition would evaluate to false.

Remember, if you’re playing with data types in serialized objects, update type labels and length indicators in the serialized data to avoid messing up the object during deserialization.

Objective

This lab uses a serialization-based session mechanism and is vulnerable to authentication bypass as a result. To solve the lab, edit the serialized object in the session cookie to access the administrator account. Then, delete the user carlos.

You can log in to your own account using the following credentials: wiener:peter

Solution

1. Log in using your own credentials. In Burp, open the post-login GET /my-account request and examine the session cookie using the Inspector to reveal a serialized PHP object. Send this request to Burp Repeater.

2. In Burp Repeater, use the Inspector panel to modify the session cookie as follows:

   ◦ Update the length of the username attribute to 13.

   ◦ Change the username to administrator.

   ◦ Change the access token to the integer 0(We have to set it to value i:0, where i indicates a integer value). As this is no longer a string, you also need to remove the double-quotes surrounding the value.

   ◦ Update the data type label for the access token by replacing s with i. The result should look like this: O:4:"User":2:{s:8:"username";s:13:"administrator";s:12:"access_token";i:0;}

3. Click “Apply changes”. The modified object will automatically be re-encoded and updated in the request.

4. Send the request. Notice that the response now contains a link to the admin panel at /admin, indicating that you have successfully accessed the page as the administrator user.

5. Replace the cookie in the browser with the updated malicious cookie

6. Access the Admin Panel and delete the user carlos

Key Takeaway

In PHP serialized data, the format i:0; represents an integer with a value of 0. In the context of insecure deserialization, this format is used to exploit vulnerabilities where an application relies on the presence of a non-zero value for specific checks or conditions.

In the given example, the original deserialized data is:

O:4:"User":2:{s:8:"username";s:6:"wiener";s:12:"access_token";s:32:"mbur3ye1of5lv6pkyk65o7api9bsn94m";}

Here, access_token contains a non-zero string value (mbur3ye1of5lv6pkyk65o7api9bsn94m).

To exploit an insecure deserialization vulnerability, an attacker might manipulate the serialized data to change the access_token value to 0 using the i:0; format:

O:4:"User":2:{s:8:"username";s:13:"administrator";s:12:"access_token";i:0;}

By setting the access_token value to 0, the attacker may attempt to bypass authentication or authorization checks in the application code that incorrectly assume the presence of a non-zero value for the access_token. This manipulation could potentially grant the attacker unauthorized access or elevated privileges within the application.