Cracking the Code: Unveiling the Forgotten Password Flaw leads to ATO

Introduction

In the domain of cybersecurity, uncovering vulnerabilities is a critical aspect of maintaining digital security. Recently, a significant flaw was identified within the “Forgot Password” feature in one of my private bug bounty program, specifically centered around its password reset functionality. This vulnerability, residing in the process of handling reset requests, exposed sensitive information by including new passwords in API response payloads. This breach in standard security practices posed a severe risk, allowing attackers to potentially reset any user’s password and gain unauthorized access to their accounts. This blog post delves into the technical details of this vulnerability, its implications, and the lessons learned from its discovery.

Discovery

The application, hosted at a specific IP address (redacted for security), initially appeared to be a standard API endpoint. However, upon further examination, it became evident that an API endpoint documentation was publicly accessible without any form of authentication, accessible at https://[redacted]/help. It was noted that unauthenticated testing was within the scope, allowing only registration and password flow to be tested. Given this limitation, I focused on testing the registration and password flow implementation.

Although there were several registration endpoints available, I chose https://api.redacted.com/api/Account/RegisterMobileUser. Unfortunately, the parameters were not specified in the documentation; only the URLs were provided without details on the underlying endpoints.

My initial attempt with email, password, and confirm password resulted in a 500 status code, indicating missing parameters. Despite trying various parameters, I was unable to identify the correct ones.

Subsequently, I decided to utilize the parameter discovery tool ARJUN to streamline the process.

arjun -u https://api.redacted.com/api/Account/RegisterMobileUser        
    _
   /_| _ '
  (  |/ /(//) v2.2.2
      _/      

[*] Probing the target for stability
[*] Analysing HTTP response for anomalies
[*] Analysing HTTP response for potential parameter names
[*] Logicforcing the URL endpoint
[✓] parameter detected: Email, based on: http code
[✓] parameter detected: PartcipantID, based on: http code
[+] Parameters found: Email, PartcipantID

Now that I know I only need two of these parameters to register a user within this endpoint, I discovered that the ParticipantID parameter only accepts UUID and it can accept any random UUID as long as the format is valid. It took some time to identify this, but now we can proceed to register an account on this endpoint.

Now, I wanted to test the forgotpassword endpoint to observe its behavior.

POST /api/Account/ForgotPassword HTTP/1.1
Host: api.redacted.com
Cookie: ai_user=L5IPC|2023-12-29T17:50:48.953Z; __cf_bm=ykXVW9Avul6UVVa4C2cfx5ji82CiZCDrzxf99Rzh3o8-1705875179-1-AaCsbAiDQHDGRQPDPd6eQrhqDNtRd8YQ6e2Rrwl9RhB57ypbmBovFGZ5usk31eS/J7aXOndsQ5qmufveWRb3o40=
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:121.0) Gecko/20100101 Firefox/121.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate, br
Upgrade-Insecure-Requests: 1
Sec-Fetch-Dest: document
Sec-Fetch-Mode: navigate
Sec-Fetch-Site: none
Sec-Fetch-User: ?1
Te: trailers
Connection: close
Content-Type: application/json
Content-Length: 37

{
"Email":"synackresearch+xxxxx@pm.me",
}

Surprisingly, I observed a strange random token in the response, which was unexpected. Typically, when requesting a password reset, you would either receive a successful password reset message or an error. However, in this case, it was a random value.

Upon further investigation, I checked my inbox and found that this random token was actually a password that had been exposed via the Forgot Password feature.

Now, this confirms the vulnerability, as using this method, I could reset any user account simply by knowing the victim’s email address.

To confirm the successful account takeover, let’s test these credentials. A 200 response code indicates a valid login, while an invalid login results in a 401 error code.

Addressing the Vulnerability

I promptly submitted my report to Synack, and they validated it within the next 1-2 hours. I’m pleased to say that it was accepted, and I received payment happily.

• The client has successfully resolved the issue, and now, when requesting a password reset via the forgot password feature, It will display as follows.

Lessons Learned

• Testing registration and forgot password functionalities is crucial as they are often entry points for attackers.
• If you encounter unusual behavior, such as a 500 Status Code during registration, it’s essential to delve deeper into the issue.
• Utilize tools like parameter discovery tools to uncover hidden parameters. In this case, identifying the ParticipantID was pivotal in discovering the vulnerability. Therefore, fuzzing and hidden parameter discovery play a crucial role in security testing.

I hope you guys enjoyed reading my blog.

Cheers!!