An Account Takeover Vulnerability Due to Response Manipulation.

4 min readNov 3, 2020

- No doesn’t necessarily mean no.! Responses can always be manipulated

Hey Everyone,

I hope everyone is healthy and staying safe amidst this COVID-19 pandemic.

On the brighter side, the pandemic gave me enough time at my disposal that I spent mostly on upskilling myself and of course finding bugs! The Last month had been pretty exciting for me as I discovered multiple Account Takeover vulnerabilities on a single private program hosted on Bugcrowd and was able to closely work with the program to get things fixed and back in place, In this write up I’ll be talking about one of the account takeover vulnerabilities which I came across during that time.

Before we start I would like you to go through my previous write up which was also an account takeover vulnerability discovered on the same program:

A Brief about the login feature implemented in the application.

To authenticate a user, the application backend sents a 4 digit code to the registered email id, and only after entering that code the application verifies the legitimacy of the user and ensures that only an authorized user with a valid code can get access to the user’s account. Looks pretty decent right.!

Attack Scenario

So when we navigate to https://www.redacted.com/login a login form appears where on entering a valid email as mentioned above a 4 digit authentication code is sent to that email address.

So the first thing that came to my mind was to enter the victim’s email and start brute-forcing the code, but the application had a strict rate-limiting mechanism in place and it returned HTTP 429 Too Many Requests HTTP response code after 10 wrong attempts, and even after trying multiple settings introducing time delays etc. also the authentication code was not leaked in the response so I was devoid of any success. :(

But failure is not on option.!

The next thing that came to my mind was let’s first have a look at the positive login flow of the application, So I entered an email-id of one of my test accounts and intercepted the positive login flow by proxying it through Burpsuit after clicking on login.

As expected an authentication code was sent to the mentioned email

On entering the right authentication code I was able to log in to that account as expected so I captured that request and dropped it off in the Repeater tab for further investigation.

So now looking at what happens after entering the wrong authentication code, the application returns a 401 Unauthorized error code as expected.

After many attempts to bypass the login feature, one thing that grabbed my attention was the error response in the response body stating {"code":"invalid_credentials"}

What if I manipulate the response itself and replace it with the one I captured previously in a successful attempt, So I tried manipulating the response by entering any random 4 digit code and capturing the response for that login attempt on Burpsuite

Do Intercept > Response to this request on Burp-suite

The original response after entering an invalid authentication code was

HTTP/1.1 401 Unauthorized
Date: Sun, 1 Nov 2020 19:35:13 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 30
Connection: close
ETag: W/"1e-4IvZjnYOB9GRQRUDsbcN8+Z6xoE"
Set-Cookie: language=en; Domain=.redacted.com; Path=/
X-Frame-Options: SAMEORIGIN
X-LEMONADE-REQUEST-ID: 230315a5-6e48-43d3-b35b-c30804daf771
X-Powered-By: Express
set-cookie: region=us; Domain=.redacted.com; Path=/
CF-Cache-Status: DYNAMIC
cf-request-id: 0442d1c5050000de6ee2ba0200000001
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Server: cloudflare
CF-RAY: 5bb18581aecfde6e-BOM{"code":"invalid_credentials"}

Making some changes to the Response code HTTP/1.1 200 OKand the response body {"verify":"true"} to resemble a successful attempt.

The response becomes :

HTTP/1.1 200 OK
Date: Sun, 1 Nov 2020 19:35:13 GMT
Content-Type: application/json; charset=utf-8
Content-Length: 30
Connection: close
ETag: W/"1e-4IvZjnYOB9GRQRUDsbcN8+Z6xoE"
Set-Cookie: language=en; Domain=.redacted.com; Path=/
X-Frame-Options: SAMEORIGIN
X-LEMONADE-REQUEST-ID: 230315a5-6e48-43d3-b35b-c30804daf771
X-Powered-By: Express
set-cookie: region=us; Domain=.redacted.com; Path=/
CF-Cache-Status: DYNAMIC
cf-request-id: 0442d1c5050000de6ee2ba0200000001
Expect-CT: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
Server: cloudflare
CF-RAY: 5bb18581aecfde6e-BOM{"verify":"true"}

And guess what? Yeah, you guessed it right.! It worked

Changing the HTTP code from HTTP/1.1 401 UnauthorizedTo HTTP/1.1 200 OKand the response value from {"code":"invalid_credentials"}to {"verify":"true"} Bypasses the authentication feature implemented as the application and gets us to log in to any User/Admin's account on that application.

This was happening because there was a client-side javascript that triggered a subsequent request based on the response received which would set new session cookies as an authenticated user.

I Reported this immediately on Bugcrowd and as the team was aware of my previous account takeover vulnerabilities this was Triaged and Fixed within 4 hours.

The Fix implemented was:
The entire login flow was revamped and the client-side JavaScript validation was removed and the application was not accepting any user value to the response and manipulating the response gave us an error message.

I’ll be publishing more and more write-ups in the upcoming days so stay tuned.!

Hope you guys enjoyed it! Do share it across :)

For any queries buzz me up on Twitter: https://twitter.com/avanish46

Until next time Cheers & Stay safe !! :)

Originally published at https://medium.com on November 3, 2020.

An Account Takeover Vulnerability Due to Response Manipulation.

- No doesn’t necessarily mean no.! Responses can always be manipulated

Written by all streaming