Skip to content

Latest commit

 

History

History
122 lines (83 loc) · 5.17 KB

5. Overview & Bypass of Account Takeover and Privilege Escalation.md

File metadata and controls

122 lines (83 loc) · 5.17 KB

🔰 Overview & Bypass of Account Takeover and Privilege Escalation

Account Takeover | Privilege Escalation | Bypass of ATO + PE

Account Takeover : ATO

Privilege Escalation : PE

Application Works :

- Organization-1 ➔ Boss-A [Owner level action - (create/read/write/delete employee projects + data) + (account_modify/delete employee)] ➜ added employee via link ➜ employee 1, employee 2, ..., employee n
- Organization-2 ➔ Boss-B [Owner level action - (create/read/write/delete employee projects + data) + (account_modify/delete employee)] ➜ added employee via link ➜ employee 1, employee 2, ..., employee n
.
.
.
- Organization-n ➔ Boss-n [Owner level action - (create/read/write/delete employee projects + data) + (account_modify/delete employee)] ➜ added employee via link ➜ employee 1, employee 2, ..., employee n

Vulnerable Application Flow :

Before Fixes - ATO flow look like this:

- Organization-1 ➔ Boss-A (Attacker) ➜ added Boss-B/n (Victim) of Organization-2/n  via link *Privilege Escalation*✔️ + *Privilege based Action*✔️ ➜ auto added all Employees of Boss-B/n *Information Disclosure*✔️ = *ATO*✔️

In above, (assume: Boss as an Admin, Employee as an User)

  • Boss-A added Boss-B into his Organization. (which was not allowed feature) - [i.e. Privilege Escalation].

  • Boss-A allows to take Privilege based Action on Boss-B. (if, there is no such feature/s provided for 'Boss to Boss' level interaction, then how will a Boss take an action on another Boss?)

  • Because now, Boss-B is an Employee of Boss-A.

  • So, the features provided for an employee, will now also apply to Boss-B.

  • One major feature is Projects based, Boss-A handles it's own and employees projects. (project permissions : create/read/write/delete). and now, Boss-A is able to handle Boss-B projects.

  • Second major feature of this category of employee is “set a new password”.

  • Which cause this PE based action leads to ATO.

Bypass - Account Takeover + Privilege Escalation

After Fixes - Application flow look like this:

- Organization-1 ➔ Boss-A (Attacker) ➜ added Boss-B/n (Victim) of Organization-2/n  via link *Privilege Escalation*✔️ - *restriction on Privilege based Action*⚠️ ➜ Boss-B/n *Information Disclosure*✔️ = *NO ATO*⚠️

In above, (assume: Boss as an Admin, Employee as an User)

  • Based on the application or maybe it will be an upcoming feature, the company left this PE as it is.
  • [I found a blog on this particular topic, that in the future maybe they will implement boss to boss(/co-boss) communication/facilities between two/multiple organizations…! So they might have implemented it in a test environment first.]
  • After patched (project based feature completely removed) and developer implemented restriction on privileged based action. this means -> NO PE, NO ATO. [actually, NO PE based ACTION, NO ATO]
  • [The Boss-B is still an Employee but the feature provided for it, is now hidden/restricted].
  • Now the situation is, even though it is PE but now it’s a part of a company feature. Therefore need to find one major or/and chain based PE Actions.

Note/Tip (as per the behavior) :

Adding a high-privileged person into the low-privileged person list using Privilege Escalation.

But then, no permission to take Privilege based Action. It's like a Half Bite.

If possible, then have to lookout for Full Bite for more impact.

  • The Employee has 3 categories in the Organization with all their different features and their handling processes, but one common and important feature was related to password.

  • If employee is in,

    • 1st cat: Boss has the authority to set a new password for the employee. (employee can’t create it)
    • 2nd cat: Boss has the authority to create auto/system generated passwords. (boss and employee can’t set it)
    • 3rd cat: Boss has no authority. (employee have their own personal password)

  • In the first ATO, Boss-B used to fall in the first category (by default).

  • But now that area is restricted.

  • (Boss-B has his own personal password, and now he fell into the employee cat. – 1st is restricted, 3rd will not helpful)

  • So, the Boss-A is having the 2nd cat. option and then he can login to the Boss-B account.

  • What about the Boss-B email address? hey, information disclosure is also in this process.

Bypassed ATO flow, look like this:

- Organization-1 ➔ Boss-A (Attacker) ➜ added Boss-B/n (Victim) of Organization-2/n  via link *Privilege Escalation*✔️ ➜ Create a 2nd cat. Employees Section ➜ move Boss-B/n to the 2nd cat.✔️ ➜ Create system generated password for Boss-B/n *Privilege based Action*✔️ ➜ Fetch personal details via *mis-configured API*✔️ ➜ grab Email Address of Boss-B/n *Information Disclosure*✔️ = *ATO*✔️

Timeline:

Somewhere in 2019 : ATO + PE

  • Report Submitted

  • Triaged as P1

  • Bounty Received $

  • Resolved

Somewhere in 2020 : Bypass ATO + PE

  • Bypass Resolved

  • Report Submitted

  • Triaged as P1

  • Bounty Received $


Happy Hunting…!!! 🔱


Next Post 🔰 :