One-click DOS via Response Manipulation

Hello Guys, My name is Akhil. Today I will tell you about some kind of Redirection Loop issue that I came across in one of the private program which will definitely DOS the server because, in 1–2 minutes 700–800+ HTTP requests were automatically made to the server. Even I don’t dare to send that many no.of requests for small targets while brute forcing.

Actually if it a genuine redirection loop, then browser will through an error after few redirects like the one as shown below.

Here in this case instead of 3XX redirection same set of GET and POST requests were repeatedly sent to the server. So, browser didn’t flagged it as a redirection loop because it is actually not a redirection loop.

Actually, I came across this issue while testing to Bypass 2FA.

Let’s get started ::

Target has a 2FA feature. I’ve enabled it and started to Bypass it.

Initially after entering email and password, a POST request is sent to server. I’ve captured the response for that request. The response looks like as shown in the below screenshot.

as you can see the response, 303 redirection is initiated to the endpoint /index.php/login/twofa where it will ask the user to enter 4 digit 2FA code sent to the email/Authenticator.

Now, I thought to check where the user will be redirected incase he/she not enabled 2FA. So, I logged into my account and tried to disable 2FA.But, Surprisingly I got an error like -

“Once you enable 2FA it is not possible to disable it”

So, I created another test account. This time I didn’t enabled 2FA. Now, I tried to login using email and password. As expected a POST request is initiated. I have captured the response for that request. The response looks like the one as shown in the below screenshot

As you can see in the response [without enabling 2FA] redirection is made to the path /app/profile/details

This time the path to which it redirects the user is different from the case with 2FA enabled.

I logged into the account with 2FA enabled > captured the response for the POST request used for authenticating the user and

changed the redirection location from

https://redacted.com/index.php/login/twofa

to

https://redacted.com/app/profile/details and passed the request to the browser.

I switched to my browser to check if any magic happened. But, as expected nothing happened.

Then I switched back to my Burpsuite and observed that tons of GET and POST requests are being made to redacted.com continuously.

You can see it in the below screenshot

Until I close that particular Tab in the browser, attack continued. So, if I keep that particular browser Tab open for few minutes it impacts the server which leads to DOS.

As per the logic implemented, user with 2FA enabled should first enter the 2FA code and then he/she will be redirected to the Profile of that user. Here, we skipped 2FA verification phase and jumped directly to the final request.

So, the server is continuously trying to logout the user from the session which was not created.

Hope you guys enjoyed it!

Let me know if you have any doubts in comment section below or

Twitter::​ https://twitter.com/a_k_h_i_l__K

Linkedin:: https://www.linkedin.com/in/akhil-kommineni/

See you soon. Until next time