3 min read

[1->2->3] or [2->3]: Bypassing Authentication Barriers

[1->2->3] or [2->3]: Bypassing Authentication Barriers

Hey Hackers!!

I am Inderjeet aka encodedguy, today I will explain how to bypass the authentication barriers or verification checks for sensitive features.

Sensitive Features

Many applications have this button that says "Delete your data", "Download your data", "Pay Now", etc. The sensitive feature that handles very sensitive data like user data, payments data, or business-sensitive data has an authentication barrier with some kind of verification like entering your password or a 2FA mechanism.

Why does this auth barrier exist? To verify that the owner of the app is clicking on the sensitive button. Not, some random user or someone who has the app or website opened is clicking on this. A remote attacker who has access to the PC/mobile can also initiate such sensitive actions if there is no authentication barrier.

The Flow

There is a button for deleting your account that says "Delete Account". The user clicks on this button. Just after clicking, an authentication prompt appears where you will have to enter your password to verify your identity. Correct password and the next request goes on otherwise you can't go further.

The Flow

This is how the flow looks like for such sensitive features. Entering the correct password will initiate the next request for deleting account. The final result is deletion of account.

The Attack

You are the hacker!! You are capturing each and every request that is flowing through your network. Specifically talking about HTTP(S) traffic, using a software like Burpsuite or OWASP Zap Proxy.

You see these 2 requests in your HTTP history:

  1. a secondary request for identity verification
  2. a primary request for deleting account.
The Attack: Sending primary request directly

As an attacker, you replay the request that is for deleting the account. If you are using software like Burpsuite, take the secondary request (deleting account) into Repeater and send the request. If the response is similar to what it looks like when the user goes through "The Flow". Congratulations!! You just discovered a bug.

Why is it happening?

It is very simple to figure out directly by analyzing the primary request.

If the primary request is not taking any parameter from the response of the secondary request, then there is no validation in the primary request whether the user has gone through this auth check or not.

Generally, the secondary request throws some challenge secret or authsecret. This secret is sent with the request body of the primary request. This secret tells the primary request that the verification process has already happened.

Impact

  • An attacker on the same network can do a MITM attack to replay the primary request.
  • A remote attacker who has already accessed the mobile phone or PC. He/She can click on sensitive features like "Transfer Money", bypass auth verification, and achieve their motto.
  • A friend, family member or any third user who has access to the vulnerable app, can also bypass the auth verification and hit the sensitive button.

Don't forget to DM me on my Twitter if you have also come across a similar bug. Well, that's all for today. I will write more on hacking next week now.

💡
I also gave a talk on "Playing with Access Controls" in OWASP Patna recently. If you'd like to hear, here's the link: https://youtu.be/KBWF8V69nok
Twitter: https://twitter.com/3nc0d3dGuY
Inderjeet Singh
Happy Hacking!!