Mass assignment is a computer vulnerability where an active record pattern in a web application is abused to modify data items that the user should not normally be allowed to access such as password, granted permissions, or administrator status.
Many web application frameworks offer an active record and object-relational mapping features, where external data in serialization formats is automatically converted on input into internal objects and, in turn, into database record fields. If the framework's interface for that conversion is too permissive and the application designer doesn't mark specific fields as immutable, it is possible to overwrite fields that were never intended to be modified from outside (e.g. admin permissions flag).
This attack is mostly really hard to recognize and identify since we can't tell by simply looking at an application that it might be utilizing an ORM framework.
Mostly for each popular programming language there is an ORM available
Programming language
ORM framework
Now, the summerization above just scratches the surface for all the different ORM that are out there in the wild.
This type of attack is also possible if the application is using an ODM (Object Document Mapping), the difference being ODM is used with NoSQL databases. A very popular ODM for nodeJs is mongoose, which is used for a MongoDB database.
In order to determine the stack that is running on the webserver we first need to do active reconnaissance on the webserver and application.
The fingerprinting is out of scope for this excersise but more information about the topic is found here:
By inspecting the source code of the target application we find that it utlizes an ODM framework to write queries to the database.
Please take note of the following code in the UserRoutes.js . This line of code will prove critical for exploiting the parameter binding attack.
Exploitation
Now, let's examine the target application and determine the objective.
Let's log in with one of the credentials the application is suggesting.
If we logout and go back to the home page we see an option to register a new user.
Let's register a new user and check the request on Burp.
As we saw in this line of code:
The application is creating a new User using the OBM UserModel with req.body instead of using Object destructuring to extract only the username and password. Maybe if we add another parameter in the request this parameter will also pass to our new User.
Now if we login.
Bingo! We have now created a new user with Admin privileges.
Additional sources
Please refer to the OWASP cheat sheet for a full complete description about parameter binding attacks.
app.post("/create", upload.none(), async (req, res) => {
const user = new UserModel(req.body); // HERE IS THE PROBLEM
try {
await user.save();
res.render("index.ejs", { msg: "User created successfully" });
} catch (error) {
res.status(500).send(error);
}
});
Mass assignment is a computer vulnerability where an active record pattern in a web application is abused to modify data items that the user should not normally be allowed to access such as password, granted permissions, or administrator status.
Please take note of the following code in the User.java . This line of code will prove critical for exploiting the parameter binding attack.
To fully understand the attack we need to examine the properties "User" model, which looks like this:
Exploitation
Now, let's examine the target application and determine the objective.
Let's register a new user
Log in as the new user
Let's register a new user and intercept the request on Burp.
As we saw in this line of code:
Maybe if we add another parameter in the request this parameter will also pass to our new User.
Now if we login.
Bingo! We have now created a new user with Admin privileges.
Additional sources
Please refer to the OWASP cheat sheet for a full complete description about parameter binding attacks.
@PostMapping("/create")
public String createUser(User user, Model model) { // here is the issue
authModel.createUser(user);
model.addAttribute("content", "Your user has been created");
return "index";
}
Mass assignment is a computer vulnerability where an active record pattern in a web application is abused to modify data items that the user should not normally be allowed to access such as password, granted permissions, or administrator status.
Many web application frameworks offer an active record and object-relational mapping features, where external data in serialization formats is automatically converted on input into internal objects and, in turn, into database record fields. If the framework's interface for that conversion is too permissive and the application designer doesn't mark specific fields as immutable, it is possible to overwrite fields that were never intended to be modified from outside (e.g. admin permissions flag).
In 2012 mass assignment on Ruby on Rails allowed bypassing of mapping restrictions and resulted in proof of concept injection of unauthorized SSH public keys into user accounts at GitHub.
This attack is mostly really hard to recognize and identify since we can't tell by simply looking at an application that it might be utilizing an ORM framework.
Mostly for each popular programming language there is an ORM available
Programming language
ORM framework
Now, the summerization above just scratches the surface for all the different ORM that are out there in the wild. For this example we will be exploiting a Ruby stack with the standard out of the box ActiveRecord ORM.
In order to determine the stack that is running on the webserver we first need to do active reconnaissance on the webserver and application.
The fingerprinting is out of scope for this excersise but more information about the topic is found here:
By inspecting the source code of the target application we find that it utlizes an ORM framework to write queries to the database.
Please take note of the following line of code in the example shown above. This line of code will prove critical for exploiting the parameter binding attack.
To fully understand the attack we need to examine the properties "user" model, which looks like this:
Step2
Now, let's examine the target application and determine the objective.
First we find a table with some details about active users on the target application
When we click a user to update his settings we find that the application does not intend us to update "privileged" the property
So, let's recap this important part of the introduction
If the framework's interface for that conversion is too permissive and the application designer doesn't mark specific fields as immutable, it is possible to overwrite fields that were never intended to be modified from outside (e.g. admin permissions flag).
Let's re-examine the following methods:
The permit method returns a copy of the parameters object, returning only the permitted keys and values. When creating a new ActiveRecord model, only the permitted attributes are passed into the model.
But, the example above shows no permitted attributes specified. Rather, it just allows for all attributes to be passed to the model. This means that when we add additional parameters to the request that are known in the model. We can abuse the automatic parameter binding behaviour to update the "is_authorized" property.
A good example would be something like the following:
Exploitation
Step1
The exploitation phase is rather simpel with all the information we gathered about the information. However, as said - exploiting this vulnerability in a blackbox environment can be rather tricky and would ask for a lot of fuzzing and educated guessing in the target application.
Now, let's set up our intercepting proxy and intercept a update request. The first screenshot shows the request as is without any tampering.
By simply adding the is_authorized property to the request it is passed to the model and processed on the server-side.
Thus updating the "Guest" user his authorized status.
Additional sources
Please refer to the OWASP cheat sheet for a full complete description about parameter binding attacks.
class PagesController < ApplicationController
def home
@user = User.all
end
def show
@user = User.find(params[:id])
end
def edit
@user = User.find(params[:id])
end
def update
@user = User.find(params[:id])
@user.update(user_params)
redirect_to root_path
end
private
def user_params
params.require(:user).permit!
end
end
params.require(:user).permit!
class CreateUsers < ActiveRecord::Migration[5.2]
def change
create_table :users do |t|
t.string :username
t.string :title
t.boolean :is_admin
t.timestamps
end
end
end
def update
@user = User.find(params[:id])
@user.update(user_params)
redirect_to root_path
end
private
def user_params
params.require(:user).permit!
end
