By Gal Nagli

OWASP

Software frameworks sometimes allow developers to automatically bind HTTP request parameters into program code variables or objects to make using that framework easier on developers. This can sometimes cause harm.

Attackers can sometimes use this methodology to create new parameters that the developer never intended, which in turn creates or overwrites new variables or objects in program code that was not intended.

Adding to that, as per OWASP API top 10, Mass Assignment is ranked at 6th place, following its definition:

Binding client provided data (e.g., JSON) to data models, without proper properties filtering based on an allowlist, usually leads to Mass Assignment. Either guessing object’s properties, exploring other API endpoints, reading the documentation, or providing additional object properties in request payloads, allows attackers to modify object properties they are not supposed to.

To understand the attack vector better, let’s take a look at the following image:

credit

The image above demonstrates a scenario which was very similar to my own finding.

As we can see from the image, we are dealing with an API which accepts JSON objects from a client. Those are common on APIs when we want to update our account information, for example changing our phone number or email address.

We are being presented with a scheme which in most cases will be represented in a UI as text fields to fill before submitting the request by a button click, such as: address, email, first name and so on.

The user update panel often differs between normal user and administrator, as those often possess more functionality to assist the site owner. The displayed UI might look the same, but the JSON object submitted within the request might have additional sensitive parameters involved.

It’s pretty clear now how to exploit this vulnerability, as the sensitive fields are not presented to the regular user in his UI or upon his user update request.

There might be a misconfiguration in the Authorization model within the application which will accept the hidden JSON fields from the non-permissive user account and will process it as if was an administrator.

Taking it to the example above, imagine the user adds to his request the following key:value pair:

“role”:”admin”

As the server won’t enforce any authorization check, the user will become an administrator by issuing a single PUT request.

You might have wondered by now: “How can we as regular users without any permissions have guessed the hidden key:values pairs?”

There are 2 main vectors to find those, which can be divided into “Blackbox” and “Whitebox” approaches.

Blackbox Approach

As for “Blackbox” testing, we can use Burp’s Param Miner extension when we have an HTTP request which sends data within JSON format. We can use the the “Guess JSON parameters” option, which will bruteforce for common JSON params and see if it affects the server response. So by issuing the Param Miner probe, we can guess for those hidden sensitive fields.

OWASP Cheatsheet

We should ensure that the roles parameter is bound to the Administrator account. We can’t allow it to be reached by normal users to tamper with. Or, simply do not allow the low privileged user accounts to add any other params than it’s name when they want to update their profile.

Conclusion

The Initial Launch Period for this specific application assessment had 40 reports submitted within the first 8 hours of the engagement.

I was the only one who reported this specific privilege escalation issue leveraging the Mass Assignment vulnerability.

It had a CVSS score of 8.1 and my payment from Synack received an additional criticality bonus.


Report Timeline

  • April 15th 14:00 GMT – Report Submitted
  • April 16th 00:20 GMT – Report accepted and Rewarded
  • April 16th 12:44 GMT – Critical bonus awarded

Thanks for sticking out!

Some Social Links:

Posted by Charlie