Another ATO, will I get paid this time?

Hi, I am writing once again. Keeping it simple as always, now let’s get started.

I was hunting on a program that shall remain nameless, it had a limited web scope but a wide application scope like Android, iOS, Linux, and Windows executables. Everyone overlooked the Web-App scope as it was only limited to the main domain and a subdomain. I found a vulnerability that everyone missed.

Account Takeover? What is that?

Account takeover attacks are attempts to gain access to unauthorized accounts, allowing the attacker to steal data, deliver malware, or use the account’s legitimate access and permissions for other malicious purposes.

That’s right! My account isn’t enough, I want yours too. Typically account takeovers are classified as HIGH severity vulnerabilities and usually arise due to a broken/weak authentication, sensitive data exposure, or Injection vulnerabilities.

So what did I find?

While hunting on account.secret.com, I noticed the login flow of the web application had a few options like OAuth Sign, Email, or Phone number sign-in. The OAuth and Email login were pretty secure but then I started testing the Phone number.

Let’s understand the Signup process of the web application.

The user decides to sign up either using OAuth, Email, or Phone number.Regardless of what they choose, an Activation code is sent to their respective choice of authentication.Once the form of medium is activated, they can log into their account and start using the services.

After signing up using my Phone number, I received a code on my number and I verified my phone number. I log into my account and it is pretty much the same as any other form of sign-in. Then what was vulnerable? Stop beating around the bush, seriously!

readers rn

Yes, the ultimate mine of bugs. I started testing the forgot password functionality using email and phone numbers. While resetting my password using my phone number I noticed something funny. A user enters their phone number but instead of getting a verification code on their phone number, they receive a password reset link.

POST /ajax/forgetPassword HTTP/2
Host: account.secret.com
Cookie: cookies
User-Agent: browser
Accept: application/json, text/plain,*/*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Content-Type: application/json; charset=utf-8
Content-Length: 1847
Origin: https://account.secret.com

{
“qid”:”91********", “recaptcha_token”: “token”
}

What’s funny?

The response contained the very secret password token, which last time I checked helped me reset my password.

funny response

So I quickly figured out what a password reset link looked like and started making test accounts using phone numbers. Once I had them verified I tried to reset their password using my newly found method, and it worked. I had successfully taken over all of my test accounts.

https://account.secret.com/resetpassword/E2QeapXMcVc5bR77Kc7fwvzzUhehrK5V7TnFzAGd

I made a very lengthy and informative video PoC and after a week or so, I received a reply from the company.

money money money

A random number of $620 for an account takeover? Well for some users, the 2-factor authentication was turned on. So after a successful password reset, the attacker needed a 6-digit code to log into their account. Nevertheless, the password did get changed and if not all, some users were still affected by the exploit.

Thanks for reading my write-up!