[Account Take Over] through reset password token leaked in response, 2500 € Reward

8 months ago 57

BOOK THIS SPACE FOR AD

ARTICLE AD

No routine, that’s what I appreciate in bug bounty. You could start your hunt, and within just five minutes, stumble upon a critical flaw, like spending 10 hours without finding anything ;) It’s this unpredictability that keeps the thrill alive.

Well, for me that day it was the first option. I had an Account TakeOver without any user interaction in a Public Bug Bounty Program. Classified as P1 and rewarded with 2500€.

In this new publication, I will explain how I managed to reset the password of any users within the application in order to gain access to their account. And how I exploited it step by step.

Note : Vulnerabilities are assessed and then categorized between P1 (most severe) to P5 (least severe) which determines how much an organization should reward the researcher who reported it.

An account takeover (ATO) occurs when unauthorized individuals gain access to a user’s account without their permission.

An account takeover is the end result, because there are several ways to achieve an ATO.

Credential Stuffing: This occurs when an attacker uses lists of stolen usernames and passwords obtained from previous data breaches to attempt to gain unauthorized access to other accounts on different websites. Bug bounty hunters can also discover these vulnerabilities aby identifying websites that don’t properly implement protections against automated login attempts.Session Hijacking: In this scenario, an attacker steals an active session token (e.g., session ID or JWT) from a user and uses it to impersonate that user without needing their username or password.Cross-Site Scripting (XSS): XSS vulnerabilities allow attackers to inject malicious scripts into web pages viewed by other users. In the context of account takeover, XSS can be used to steal session cookies or redirect users to phishing pages where their login credentials are captured.Cross-Site Request Forgery (CSRF): CSRF attacks trick authenticated users into unknowingly executing malicious actions on a website they’re logged into. For example, an attacker could create a crafted link that, when clicked by a logged-in user, sends a request to change the user’s email address without their consent.Broken Authentication: This category includes various vulnerabilities related to the authentication process, such as weak password policies, insecure password storage, predictable session tokens, or improper handling of account recovery mechanisms.

I came across an application that seemed interesting to me because it had numerous features, but also several user profiles to manage, from administrator to standard user.

Generally, in my hunting method, I start by creating an account but I don’t use it. I prefer to test all the unauthenticated functionalities to really understand the application’s workflow, and deduce from that which type of vulnerability I will focus on.

I found a first account takeover via the login functionality because no captcha or rate limit was in place. So I was able to brute-force the user’s password using a wordlist. It was accepted and classified as P4.

Then, I proceeded by testing the password reset functionality.

My goal was to check if the ‘first name’ or ‘last name’ fields of the user were reflected in the email in order to attempt an HTML email injection attack. Unfortunately for me, this was not the case.

But that’s where it begins.

By analyzing the request and response of this password reset functionality with Burp Proxy

PUT /api/v1/people/forgot_password

I noticed that the reset password token of my user, as well as the PII and the password hash, are disclosed in the response.

At that moment, I thought I must be logged in as the user or the session isn’t terminated properly. Therefore, the impact of the vulnerability will be much less severe as it’s my own data.

So I opened a browser in private browsing mode, and then I attempted to reset my password again. And to my surprise, I received the same response.

{

“activation_code”:”3ce8aeb4461ae0e45eb73a4649babc6529d096da”,

”reset_password_code”:”fb39dfe8cb9200305b34a693c7867fb8",

”id”:4592665,

”first_name”:”\u003cu\u003ehello\u003c/u\u003e”,

”last_name”:”\u003cu\u003ehello\u003c/u\u003e”,

”account”:true,”email”:”email@redacted.com”,

”crypted_password”:{“raw_pw”:”$2a$REDACTED”

}

Now the questions that i have in my mind are :

Can I escalate to an account takeover ?Is it possible to decrypt the password hash ?Is the password reset token valid ?

We already have the ability to enumerate all user’s PII. So the severity of the vulnerability is already critical P1.

But, if it’s possible to use the user’s hash password or the reset password token, we’ll have an even higher severity in Account Take Over.

Concerning the password decryption, I wasn’t able to accomplish it with my tools.

However I have thus analyzed the reset password link received by email, and it does indeed correspond to that in the HTTP response.

So yes the reset password token disclosed in the response is valid.

[1] An attacker sends a request to the API endpoint “/api/v1/people/forgot_password” requesting the reset password of the victim’s account.

[2] The Attacker paste the reset password token and the victim’s ID (extracted from the response) in the password reset link :

https://www.redacted.com/reset_password?code="REPLACE_WITH_RESET_PASSWORD_CODE"&id=REPLACE_WITH_ID_PARAMETER

[3] The attacker can now open the link in his browser, and reset the victim’s password.

[4] The Attacker gain access to the account (Account Take Over), without any action from the victim.

The impacts of an account takeover vulnerability can be significant:

Unauthorized Access to Personal Information: Attackers can access sensitive data stored in the user’s account, compromising their privacy and security.Fraudulent Use of the Account: Attackers may misuse the compromised account for malicious purposes, such as sending spam, accessing paid services at the account owner’s expense, or engaging in criminal activities like financial fraud.Loss of User Trust: Users may lose trust in the online service if their accounts are compromised, leading to reduced usage, negative impact on the company’s reputation, and potential loss of customers.Risk of Attack Propagation: If the attacker gains access to an account with elevated privileges (e.g., an admin account), they can use it to access other internal systems or services, extending the impact of the attack.Compliance Violations: Companies may be subject to fines and legal consequences for failing to protect users’ personal information in accordance with regulations like GDPR or CCPA.

And as expected, it was accepted, even though I was still afraid of the duplicate, which is rather rare for this type of vulnerability.

The IT team promptly addressed the report and resolved the issue within a matter of hours.