Account Pre-Takeover Bug Bounty

What is account Pre-takeover?

Account Pre-takeover is the malicious action of taking over / controlling a victims account and at times before the account even exists. This type of vulnerability can enable an attacker to take control of the victim’s account, potentially allowing them to view sensitive information, perform unauthorized actions, or even steal the account. It is handled as critical or high mostly because if you have the POC to one victim , the attack can be carried out on large scale by utilising the weak session management or weak access control flaws . This attack also carries along a chain of up to 5 bugs!! But how is that possible? Follow along the writeup keenly.

Thee Eclipse

Path to the chained bugs

So before I came to the vulnerable url ,I was hunting on a target let us say: redacted.com and for hours have been through their technologies and I just could not find anything yet well apart from a WordPress 5 that apparently has even public exploits and known bugs but the program could not pay for any of those as they are out of scope.

Well for WordPress bug hunting it is simplified by : https://wpscan.com/ but again scanning the available plugins you can use wpscan tool on linux for command line or else there is a less efficient: https://www.wpthemedetector.com/ so those can come in handy while hunting on wordpress targets.Custom installations are the easiest to go after as they use weak php encryptions, access control and mostly never employ wp-nonce and proper integrations to wp-database. Anyway this post is not for WordPress Bug bounty so we go on…

After searching around for hours and intercepting multiple requests I came to a realization that the site served content from a remote server and apparently the server had a website hosted with own url but all href redirected to redacted.com.

So I went to the remote server url by IP access after resolving the url to IP(NMAP and most linux tools and online dns resolvers can do that).Now the url had something like( I HAVE MODIFIED THE URL PATH AND THIS WAS NOT THE EXACT ONE): redacted.com/secret-account/&account-id=30 and this got interesting but was just an archived url on the Internet Archives and again trying to access it prompted me to login meaning unauthenticated user can not access the account id so I had ot login with my test account and well, changed my url to : /secret-account/&account-id=30 and guess what, I could now see user 30’s account profile but I did not have my own account ID yet so I had to look for it and obviously for new accounts they have higher no. for IDs so I started aggressive Burp Suite Intercept and I checked every url that passed through my proxy and finally I landed on my account ID : 7320 and from that I knew they had probably that many user accounts so I decided to elevate that to critical by taking over all the accounts.

I chose to elevate / exploit the web application from the signup and login to accounts dashboards and account settings.

Step 1

We first need a target. Our todays target is redacted.com .

So we first create an account at redacted.com and the attacker account is a@a.com. The victim account is v@v.com

We first sign up as a@a.com and the basic sign up will be a post request to the server e.g :

POST /sign-up HTTP/2
Host: redacted.com
Cookie: cookies=yes;some random cookie here
User-Agent: Mozilla/5.0 
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://redacted.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 993
Origin: https://redacted.com
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Te: trailers

FirstName=attacker&LastName=attacker&EmailAddress=a@a.com&password=1234&preference=mail-me&anything else needed for signup

Now notice the details passed in the sign up request, mostly will have more PII(Personally Identifiable Information) or prompt you to add more at “ACCOUNT SETTINGS”

Step 2

Now after creating account just login and check around the dashboard and this bug lies obviously at modify account section where you are allowed to edit account details.

The edit account option is an area to take keenly because if there is sections with unallowed edit (perhaps the email/account id), the backend may not properly validate that and you can use that as an attack endpoint / entry .In this case account-id and email editing are not allowed on the front end but the server does not check that properly. Common issue in Microsoft/Windows servers.

Now request account edit and intercept the request .The request may be something like: (Be extra sensitive with the request and notice any front end sections that were disabled if the request handles their parameters as inputs)

POST /account-update HTTP/2
Host: redacted.com
Cookie: cookies=yes;some random cookie here
User-Agent: Mozilla/5.0 
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://redacted.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 993
Origin: https://redacted.com
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: same-origin
Sec-Fetch-User: ?1
Te: trailers

FirstName=attacker&LastName=attacker&EmailAddress=a@a.com&account-id=30&anything else on account settings

The request sends our account-id and email as inputs to the server!! This is now interesting!!

Remember our attacker account is: a@a.com and now since we can update the email, we set it to v@v.com and submit the request and we finally get a 200 OK response .

This is fun

Now refresh your account dashboard and now your new email is v@v.com !!

Now a key factor to note: Servers that do not allow sections of the account to be edited will loopback to the original settings if changed and if won’t fallback to original, the previous account gets deleted and the new email must have its password reset after/upon “session destroy”

From a different perspective, change the account details and now change the account-id from 30 to maybe 50 and only make the request on browser. If the new page after reload is user 50’s account dashboard, THAT’S A BUG already!!

The request body parameters will be something like:(But from burpsuite repeater, right click and make the request on browser)

FirstName=attacker&LastName=attacker&EmailAddress=a@a.com&account-id=50&anything else on account settings

Step 3

Without logging out of your account:

Open new tab/browser, try signing up as v@v.com and the server responds that “account is already created, login ” or “Please login, an account v@v.com already exists” .

Remember v@v.com did not sign up at all but goes ahead to reset their password as they do not know the existing password.

Then now v@v.com logs in and whenever the attackers session changes the account details, the victims account changes.

If as attacker I change my name from HEY to Hacked, the victims account changes its name to Hacked and as well all victim updates gets visible to attackers interface/session.

Then now as attacker I can freely go back to my original email by resending the account update request and using my original email or perhaps stay as victim and await new PII and data to be added by victim and I use that for malicious activities.

Did you notice several bugs there?

1. Improper session management

When victim used the reset password because their account was supposedly already existing , the attackers session was not destroyed despite being the one bearing the victims email

2. Improper access control

The server allowed for account editing from different sessions where attacker can change victims account details and move to his original account

3. Email verification bypass

If the sign up uses an email verification prompt by sending a link to new accounts email, when attacker changes his email to victims email , the email verification prompt is not there and victim never verifies their email.

4. IDOR

The attacker can opt to use the account-id value to change to all user accounts on the platform and is it is successful, that’s IDOR

Remember from the Introduction our account profile IDs would be referenced by anyone and they would see our profile data?

Now apart from account manipulation, we now can access all user accounts on the Platform and that is how I had several megabytes of user data(Just for POC) and could manipulate all those accounts.

The typical request body parameter will be:

FirstName=attacker&LastName=attacker&EmailAddress=a@a.com&account-id=30&anything else on account settings

Now you can exploit the account-id parameter using IDOR but only if it is vulnerable or after verifying the Improper Access control after following all the steps below.

5. Ability to delete old accounts and sign up afresh

If the server does not loopback to attackers original email on logout having changed their email to victims email: The old account is non-existent and the email can be used to sign up afresh and even lead to the email verification bypass as well

>>The 30 mins POC video will be attached here upon program permission