Using Application Functionality to Exploit Insecure Deserialization

1 month ago 26
BOOK THIS SPACE FOR AD
ARTICLE AD

If you want to be the first to see these articles, consider subscribing to the Cybersec Cafe on Substack for free. I post content there first, and here second.

My goal is to deliver you value in various cybersecurity topics and to become your ultimate destination for expanding your cybersecurity expertise as a cybersecurity professional.

Insecure deserialization is a vulnerability that occurs when an application deserializes converts data from a serialized format (JSON, XML, etc.) back to it’s original form without proper validation or integrity checks. It can be exploited by attackers in a way that leads to remote code execution, data tampering, or other malicious actions.

Want to follow along with the lab yourself? You can check it out on PortSwigger’s website here for free.

The first step of our methodology will be to get an understanding of the application and its functionality.

We can see that this is a standard Blog environment that has the functionality to comment on each post.

For this lab, we are given 2 sets of credentials to log in with:

The Main accountThe Backup account

Let’s start by logging in with our Backup account.

We can see there is quite a bit of functionality available to us here.

Update emailUpload avatar photoDelete the account

In order to fully capture the functionality of this lab environment, we need to submit each of the requests to capture within our Burp Suite instance.

We should complete them in a logical order so that we can capture the other requests before deleting the account, but if you delete the account before doing so, there is the Main account to fall back on.

Taking a look at our SiteMap, we can see it’s lit up like a christmas tree!

There’s quite a lot of issues that Burp as auto-identified.

Sicne we captured all of the account actions, we have 2 requests that should initially stick out:

The Delete file since it’s performing a delete actionThe File upload since we are dealing with a file.

Let’s send them both over to the repeater for testing.

To kick off the manual testing, let’s start with the delete account endpoint and see if we can make sense of the serialized object:

If you highlight the seession cookie in Burp, the Inspector will be able to automatically decode it for you.

We can see that this cookie has information about the user, but let’s take a look at the upload avatar endpoint before we draw any conclusions.

Again, we can highlight the cookie and see something interesting stands out right away: The avatar_link.

Let’s take a look at these objects side-by-side for reference.

It looks like both tokens have exactly the same format.

If we think about the functionality we have available to us and the objects in each function, our attack vector is starting to become quite obvious, right?

Let’s grab the avatar object in the request and edit the contents to reflect the file we want to take action on:

Remember to edit the length right before the object to reflect the new length of the file we are referencing. It should look like this:

s:11:”avatar_link”;s:23:”/home/carlos/morale.txt”

With 23 being the length of /home/carlos/morale.txt .

Now, given that we have an endpoint that has the functionality to delete, if we change POST /my-account/avatar to be POST /my-account/delete we should be able to delete the file:

Lab solved — file deleted!

We can see just how dangerous Insecure Deserialization in an application can be. Failing to sanitize input when passing to a dangerous method can have severe consequences, like in our instance, deleting a file on the filesystem. This shows that deserialization of user input should be avoided in an application unless rendered absolutely essential. Deserizalition can have sever impact because it can be any entry point to an entirely new attack surface and lead to things such as privilege escalation, file access, and even Denial of Service attacks.

Remember: The Cybersec Café gets articles first. Subscribe for free here.

Interested in getting into Cybersecurity? I have a course called the Security Sip. The curriculum is designed to help you build skills progressively over 12 sections, 85 modules, and 155 exercises. With rapidly evolving threats and technologies widening the skill gap, it’s time to secure your future in cybersecurity. Available Now!

Oh, and if you want even more content and updates, hop over to Ryan G. Cox on Twitter/X or my Website. Can’t wait to keep sharing and learning together!

Read Entire Article