Manipulating Response: A Deep Dive into Exploitation => $650

Manipulating Response: A Deep Dive into Exploitation => $650

Hello, Hunter!

Another day, another story of a successful bounty. In this blog, I’ll be sharing my experience discovering a vulnerability through response manipulation. Let’s dive straight into the details and explore how this bug was uncovered.

Recently, I was testing an application for a private client. The app had a fairly simple structure, designed primarily for five to six specific tasks along with a report generation feature for users. Given its limited functionality, there weren’t many features to explore during testing. However, upon completing my assessment, I discovered several vulnerabilities — most of which were categorized as P3. Additionally, I identified a subdomain takeover issue, but unfortunately, it was marked as out of scope.

As bug bounty hunters, we know that duplicates, low-severity findings, and rejections are all part of the journey. These challenges serve as stepping stones, refining our skills and pushing us to dig deeper into our targets. Every experience, whether a success or a rejection, contributes to our growth. Now, let’s dive into the bounty endpoint and break down the attack scenario!

Understanding the Bug:

If you're new to response manipulation, let me break it down simply. When registering on a website, you typically receive a One-Time Password (OTP) via email. If you enter the correct OTP and capture the request in Burp Suite, the server responds with a “200 OK” status, relevant headers, and a success message. But what if you enter the wrong OTP? In that case, the response usually returns a “400 Bad Request” status with an error message.

Here’s where things get interesting—by altering the server’s response to mirror a successful OTP verification, it might be possible to bypass the entire authentication process. Now, let me walk you through how I uncovered this vulnerability on a real-world target.

Exploiting the Vulnerability:

Based on the description above, you can probably guess where I focused my fuzzing — yes, the login request!
Since the application relied on OTP verification for login, a unique code was sent to the user’s email instead of using a password. Each time a user attempted to log in, a new OTP was generated. To test its security, I launched Burp Suite, intercepted the login request, and deliberately entered an incorrect OTP to observe the application’s response. As expected!

I repeated the process once again, but this time, instead of using a newly generated OTP, I took the response from a previous successful login and replaced the error message in the current response with the success message from the valid OTP attempt.

Amazingly, despite entering an incorrect OTP, I successfully logged in by manipulating the response with the success message from a valid OTP attempt. I documented my findings and submitted a detailed report to the team. Within just 24 hours, the vulnerability was acknowledged, and I was rewarded $650 for the submission.

Summing It Up:

Thoroughly mapping the target is crucial. Repeatedly testing parameters, endpoints, and key requests enhances understanding and reveals hidden vulnerabilities. Patience pays off — the more you refine your approach, the greater the chances of a valuable discovery. If you enjoyed this content, feel free to follow for more!