Easy Bug: How I Uncovered and Re-Exploited a Resolved Vulnerability from a Disclosed Report

السلام عليكم

Assalamualaikum, everyone, I am Omar El-Qady, also known as Barbarossa.

Overview Of the Write-up:
While reviewing a disclosed report, I found that the vulnerability allowed an attacker to bypass the required verification step during the email change process. After learning about the initial flaw and its resolution, I attempted to understand the fix in detail and discovered a way to bypass it. This write-up outlines the vulnerability flow before and after the fix and describes how the issue can still be exploited despite the attempted solution

Initial Vulnerability (Before Fix)

The original vulnerability allowed unauthorized email changes due to a lack of verification steps in the email change process. Typically, when a user attempted to change their email, they would be redirected to a password-protected page before proceeding with any changes. However, the flaw in this workflow allowed an attacker to bypass this security check entirely by exploiting the return parameter within the /verification-pc endpoint.

In this flow, the /verification-pc endpoint included a return parameter, which took a URL-encoded value pointing to the email change page. For example:

By decoding the return parameter value, Attacker discovered that it pointed directly to the email change URL. Suspecting that the application might not be enforcing the password check correctly, Attacker navigated directly to the decoded email change URL without entering a password. The application allowed him to access the email change page and modify the email address without the usual password verification step.

How the Developer Attempted to Fix the Vulnerability:

After reading the disclosed vulnerability report, I decided to investigate further. I noticed that the vulnerability had been fixed, and I wanted to understand how the developers had addressed it. To do so, I visited the application and attempted to analyze the fix in real-time.

Upon examining the flow, I saw that the developers had implemented an additional security measure to prevent unauthorized email changes. The fix involved adding an API request to the /user/api/verificationToken endpoint. This request was responsible for triggering the sending of a verification email to the user, which was intended to ensure that the user’s current email address had to be verified before any changes could be made.

The fix seemed straightforward, but I wanted to dig deeper to fully understand how it worked. I reviewed the request body and flow associated with the fix, and here’s what I found:

Steps of the Developer’s Fix:

How I Bypassed the Fix:

Conclusion:
The key takeaway from this experience is that reading disclosed vulnerability reports can help identify potential bypasses in security fixes. In this case, by analyzing the disclosed report and understanding how the fix was implemented, I was able to find a way to bypass the new verification mechanism and still change the email address without proper validation.

Thank you for reading. Feel free to connect with me on linked-in or Twitter.