Mass assignment and learning new things

Hi everyone, For this second article on BugBountyHunter we're going to talk about a vulnerability and how I did to learn more about it.

Indeed, among the questions I am most often asked is "but how do you learn a new vulnerability, find resources, etc..."

This is a difficult question to answer because there are many different learning methods and each one is suitable for a different type of person. Among the standard "techniques" we can find :

• Theoretical learning: Listen videos, read articles and retain
• Learning by writing: Theoretical learning + note taking or Pure note taking (text) or diagram
• Learning by doing: By doing challenges, labs, ...

Although I read a lot of blogs posts articles etc.... I can't retain everything by reading it once and I don't feel like reading the same thing 10 times in X amount of time.

I tried note taking with the creation of my own "WebSecurityWiki" with diagrams etc... It helped me a lot at the beginning but I realized that it could become complicated to manage and organize to find directly the necessary information.

Example of a diagram that is part of my wiki on the Open Redirect vulnerability:

I am still creating a new approach to note taking but it is still in the experimental phase, with a tagging system.

And for learning by doing it's a bit the same, at the beginning I did a lot of CTF, challenges, I spent time on Pentesterlab & WebSecurityAcademy and they are really amazing resources but I didn't feel like it was the most effective in my case.

What I've found most effective for me is to create my own labs, understand how it works and try to exploit it in different ways. And today we're going to see that with and example for the Mass Assignment vulnerability.

The fact that I wanted to work on this vulnerability came to me after an article by Nagli : Mass Assignment exploitation in the wild - Escalating privileges in style.

I already knew about the vulnerability but I had never found one, why? did I really understand the vulnerability? did I really understand how to exploit it?

Before going into detail, for the most daring, if you are a member of bugbountyhunter, a lab is available, you can try to exploit it before reading the rest of the article. You are not a member yet ? what are you waiting for to become one ? :D

So I start looking for documentation on the subject, first of all in a general way, so I just search for "mass assignment" and I find a lot of "general" resources, including the Cheat Sheet from OWASP Mass Assignment Cheat Sheet (very important because there are special cases, remediations etc....), topics presenting the vulnerability, explanations for some languages and a lot of topics indicating that it is a vulnerability in the APIs. By the way, it is in the top 10 OWASP APIs.

API6:2019 Mass Assignment : 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 objects 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.

Then I try to look for more technical topics related to what I want to do in the end. So I look for "mass assignment bugbounty" and there I find a lot of technical blog posts and writeups.

So, without going into the details of the vulnerability, we quickly understand that it mainly affects the APIs and that to exploit the vulnerability we add a field that is not present such as is_admin: 1 which will still be used by the server and will pass you admin.

Let's get to the heart of the matter, the creation of the lab, as I'm a bit lazy, I didn't invent anything and I started from an existing base. I was looking for something simple to build on and after some research I found this Github Gist.

A simple Sinatra application (a Ruby framework) with some features. In my case I added :

• A function to register
• I modified a bit what is displayed once connected
• A function to update your information

It is this last function that will interest us, I created it by remembering an information update system that I had seen in a tutorial (basically, I don't remember the video very well and maybe the author of the video had included a vulnerability himself without realizing it).

So here is the code in question:

For those who don't understand the code, it's a POST method on the URL /update that takes as parameters values transmitted by a form and basically, if it's a password then we update it with the hash function and if it's a username we check if it's already existing, otherwise we update the user's information with the transmitted parameters if the parameter exists.

So the most skeptical or those who know web development (especially Rails) could tell me "But wait Jomar, you're talking nonsense, your code is not realistic, moreover nobody uses Sinatra, in Rails there is a security mechanism that makes that we must explicitly declare the parameters that a user can modify".

This is where we enter the heart of the application, it's a bit ugly and it's not an API (it was deliberate to show that it doesn't only happen in APIs) but in reality I have two forms that allow to update different user information but that use the same update function for that.

On the other hand I grant you, it would certainly be more realistic in an API, I'm not a developer but I suppose that in an API we have more tendencies to reuse at the maximum the same functions to lighten the application, to gain in performance, simplicity, maintainability etc... but it thus involves errors or security problems.

Let's go back to our application, we create a user and we connect. Nothing special, just a basic page with our two forms:

We then try to exploit the vulnerability, we can replace the submitted parameter by a non-existent parameter to see what happens:

An error 500, interesting, we just have to find a valid parameter, we can either do bruteforce, guessing or try to understand the application.

On our home page, among the information we find the "Username" but also a "role" field:

By using the field and setting it to Admin, the application accepts the request and we have the admin privilege to see the password hash:

One could always tell me "Yes but it's not realistic, here we are trying to update specific things, no interest to do that".

This lab is simple, but let's imagine a more complex case with role management, the administrator could then have a specific form to change the role of a user that would always use the same /update function with the role parameter.

An even more complex case would typically be in e-commerce with shop and user management.

• A global admin sets admin a user for a shop, he can then manage his users but if the set uses the same function for example he could become admin of another shop or a standard user could raise his privileges. (Real case already met)

If you are interested in this vulnerability, I also recommend the article and more precisely the section "Detecting mass assignments" of Dannewitz

Conclusion

In this article I present you a learning technique that works for me, this does not mean that you have to do the same thing, on the contrary, it's up to you to experiment with different things and see what suits you best!

The lab is quite simple here for the article but you can build more complete / complex examples quite easily for a lot of subjects (notably XSS & SQLi). When I create my own labs and run them I tend to hold back because at the end of the day I spent time on it and when I come across an application I ask myself "how would I have done it here to manage this"

If you are looking for quick writeups I recommend :

• https://www.bugbountyhunter.com/disclosed/
• https://www.bugbountyhunting.com/

We obviously want to go straight to the writeups and try to reproduce, this is not a good idea in my opinion. It is important to take the time to understand things and to have a solid base of knowledge rather than going headlong and sending paylaods that don't make sense in all inputs.

References

• Nagli - Mass Assignment exploitation in the wild - Escalating privileges in style.
• Dannewitz - Detecting and exploiting mass assignments
• Flaticon for the used icon
• Tomdalling for the based code I've used.