Mass Assignment Attacks
Last updated
Last updated
Mass Assignment vulnerabilities are present when an attacker is able to overwrite object properties that they should not be able to.
A few things need to be in play for this to happen. An API must have requests that accept user input, these requests must be able to alter values not available to the user, and the API must be missing security controls that would otherwise prevent the user input from altering data objects. The classic example of a mass assignment is when an attacker is able to add parameters to the user registration process that escalate their account from a basic user to an administrator. The user registration request may contain key-values for username, email address, and password. An attacker could intercept this request and add parameters like "isadmin": "true". If the data object has a corresponding value and the API provider does not sanitize the attacker's input then there is a chance that the attacker could register their own admin account.
One of the ways that you can discover mass assignment vulnerabilities by finding interesting parameters in API documentation and then adding those parameters to requests. Look for parameters involved in user account properties, critical functions, and administrative actions.
Additionally, make sure to use the API as it was designed so that you can study the parameters that are used by the API provider. Doing this will help you understand the names and spelling conventions of the parameters that your target uses. If you find parameters used in some requests, you may be able to leverage those in your mass assignment attacks in other requests.
You can also test for mass assignment blind by fuzzing parameter values within requests. Mass assignment attacks like this will be necessary when your target API does not have documentation available. Essentially, you will need to capture requests that accept user input and use tools to brute force potential parameters. I recommend starting out your search for mass assignment vulnerabilities by testing your target's account registration process if there is one. Account registration is normally one of the first components of an API that accept user input. Once registration has been tested then you will need to target other requests that accept user input. In the next few minutes, we will analyze our crAPI collection to see what other requests make for interesting targets.
The challenge with mass assignment attacks is that there is very little consistency in the parameters used between API providers. That being said, if the API provider has some method for, say, designating accounts as administrators, they may also have some convention for creating or updating variables to make a user an administrator. Fuzzing can speed up your search for mass assignment vulnerabilities, but unless you understand your target’s variables, this technique can be a shot in the dark. Let's target crAPI for mass assignment vulnerabilities.
Let's intercept the account registration request for crAPI.
While using a browser, submit data for creating a new account. Enter your email and password into the form. Set FoxyProxy to proxy traffic to Burp Suite.
Submit the form to create an account and make sure the request was intercepted with Burp Suite.
Send the intercepted request to Repeater. Before submitting any attacks, send a successful request to have a baseline understanding of how the API responds to an expected request.
Next, test the registration process for mass assignment. The simplest form of this attack is to upgrade an account to an administrator role by adding a variable that the API provider likely uses to identify admins. If you have access to admin documentation then there is a good chance that the parameters will be included in the registration requests. You can then use the discovered parameters to see if the API has any security controls preventing you from escalating a user account to an admin account.
If you do not have admin documentation, then you can do a simple test by including other key-values to the JSON POST body, such as:
Any of these may cause the API to respond in a unique way indicating success or failure.
Once you attempt to a mass assignment attack on your target, you will need to analyze how the API responds. In the case of crAPI, there is no unique response when additional parameters are added to the request. There are no indications that the user account was changed in any way.
Another way to test more options would be to send this over to Intruder and place attack positions around the new key and value that you want to test. In our case, this would be isadmin and true. Set the attack type to cluster bomb and add payloads for positions 1 and 2. Run this and review the results for anything unique.
In the case of crAPI, the registration process does not respond in any way that indicates it is vulnerable to mass assignment. There are several tools out there that can fuzz for mass assignment vulnerabilities, but since we are using Burp Suite it is worth checking out Param Miner.
Make sure you have Param Miner installed as an extension to Burp Suite CE.
Right-click on a request that you would like to mine for parameters. Select Extensions > Param Miner > Guess params > Guess JSON parameter. Feel free to experiment with the other options!
Set the Param Miner options that you would like and click OK when you are done. Check out the unofficial documentation for an additional explanation of the options (https://github.com/nikitastupin/param-miner-doc).
Navigate back to Extender-Extensions and select Param Miner. Next, select the Output tab and wait for results to populate this area.
If any new parameters are detected, insert them back into the original request and fuzz for results.
