🎨
Findings
  • Discovered Vulnerabilities
  • Finding Security Vulnerabilities in Android Applications
  • API Endpoints lead to Sensitive Information Disclosure and PII leakage of Employees
  • HTTP Dangerous Methods Enabled - P1
  • Subdomain Takeover
    • Subdomain Takeover
  • XSS
    • XSS on error page
    • Interesting XSS
  • 2FA Bypass
    • Brute-force Protection Bypass
    • Response Manipulation
  • Crazy Account Highjack
  • OAuth Misconfiguration
  • Open Redirect
    • Open Redirect >> XSS
    • Automation
Powered by GitBook
On this page

Was this helpful?

Crazy Account Highjack

Multi-step exploitation to account highjack

PreviousResponse ManipulationNextOAuth Misconfiguration

Last updated 3 years ago

Was this helpful?

I was testing for my favorite bug type: MFA bypass on this particular target but it was quite secure and I tried all test cases including brute-force protection bypass, Response manipulation, Token leakage and many more. I tried these on signup, login & reset password functionalities but no luck.

While I was testing for horizontal privilege escalation on sensitive actions on the profile page, I noticed an option of "Add Secondary Mobile Number". Adding a second mobile number also required code verification for obvious reasons.

So I thought of giving this a try. An attempt to bypass verification on adding second mobile number.

I again fired the same test cases but could not crack it. Just before I was about to give up on this endpoint, I thought of checking for token leakage a last time before moving on.

On a successful verification, I noticed that the response content contained a token: {token='random_string'} I realized if I could get the token and add it to the response of a failed verification and change the response code, I could add the victim's mobile number without verification.

But a piece is still missing: Where do I get the token? So I started checking each request previously made. I searched for the token value in burp proxy history and found the token was leaking in the request made for sending verification code.

I started a fresh request and captured the new token. Then I entered the wrong code and captured the request. Added token parameter and pasted the token value. Forwarded the request. And now I have victim's mobile number as a secondary number on my profile without verification.

I tried the same method on login, signup and forgot password, but different mechanisms were used there.

I then looked how I could escalate the impact by changing it to my primary number, but there was no such option.

I then spent a few more hours of looking for other bugs. After that I switched to the android application to find logical bugs. There I noticed that on the profile page was an option: "change primary mobile number" jackpot I could then have the victim's mobile number as my primary mobile number linked with my account.

Impact: An attacker can imitate as the victim and do malicious stuff. This makes the verification process on signup completely useless.

PS: "Victim" in the description is my own mobile number. I did not mean to imply that I used anyone else's mobile number for exploitation.

😬
🥳
🕺
✨
✨