Most of the time when I want to find vulnerabilities in web applications I always like to poke around the authentication parts of the web application (as they are very interesting attack vectors). So, I always capture the POST requests with Burp Suite’s proxy and begin fuzzing the form parameters.

It wasn’t until I forwarded the request did I realize some interesting parameters within the POST body;

Burp Suite Professional

Exploitation - POST Parameters:

_csrf-frontend , Signup[first_name] , Signup[last_name] , Signup[username] , Signup[email] , Signup[password_hash] , Signup[password_repeat] , Signup[role_id] , Signup[auth_key] , Signup[password_reset_token] , Signup[user_id] , Signup[academic_year] , Signup[status] , Signup[created_at] , Signup[updated_at] , Signup[entry_id]

Looking closely at the mentioned parameters, I discovered an interesting parameter, Signup[role_id]. So, I thought if Signup[role_id] parameter takes the actual ‘role id’ then I could leverage my privileges into Super Admin’s privileges.

From the request above, Signup[role_id] takes an ID - a value that depicts the category/user-level of a web application user.

So, I decided to edit the Signup[role_id] value (replacing the existed value with 1) and repeated the POST request.

Super Admin Dashboard

In a matter of seconds I was presented with a Super Administrator’s dashboard. Whew! ;P

These flaw was properly reported and immediately fixed.

What’s the lesson behind these article?

Going straight to the point.

What I was exploiting throughout the article is a vulnerability known as Insecure Direct Object Reference A.K.A IDOR. Most developers overlook this vulnerability especially because they trust the user side. But with the epic growth of the Cybersecurity realm and emergence of sophisticated cybersecurity attacks, developers aren’t advised to trust the user side anyway.

IDOR could cause loss of confidential data, modification of data and sometimes leads to privilege escalation attacks. For example, a malicious hacker could insert arbitrary prices on products to be bought on an e-commerce site and eventually purchase the products at very lower prices.

It is recommended to use less obvious values that won’t be easy to enumerate as a reference. For example a random string value instead of incrementing values (be integers/strings).

Further reading:

  1. Testing for Insecure Direct Object References”
  2. Insecure Direct Object Reference Vulnerability”
  3. IDOR PDF

Thanks, made by ❤️

bl4ckbo7 - PWN | Eat | Sleep | Repeat.

Like this post? Share on: TwitterFacebookEmail


Keep Reading


Published

Category

Hacking

Tags

Stay in Touch

Get Monthly Updates