BOOK THIS SPACE FOR AD
ARTICLE ADHey there! It’s cyberpro151 back with another writeup about a unique technique of bypassing Two Factor Authentication that I uncovered in a recent pentest. So let’s get started.
A few days ago while doing penetration testing of a client of our company, I came across the site’s URL which was like following:
https://redacted.com/login
Its interface was like following:
Now as it was a grey box pentest, I was provided with the credentials of the site.
Here, after entering the credentials, I intercepted the request and it looked something like following:
POST /api/authentication/login-2fa HTTP/1.1Host: redacted.com
Content-Length: 100
Sec-Ch-Ua: "Not)A;Brand";v="99", "Brave";v="127", "Chromium";v="127"
Sec-Ch-Ua-Mobile: ?0
Authorization:
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36
Content-Type: application/json
Accept: application/json, text/plain, */*
Utcoffset: -420
Sec-Ch-Ua-Platform: "Windows"
Sec-Gpc: 1
Origin: https://redacted.com
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://redacted.com/login
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Priority: u=1, i
Connection: close
{
"email":"admin@redacted.com",
"password":"PASSWORD",
"loginFrom":"ADMIN",
"deviceId":"8709184523"
}
Now after forwarding this request, I was redirected to a page like following:
Now I simply entered the OTP and logged in to the site but this 2 Factor Authentication’s implementation caught my attention so I tried to test this functionality. For that, I logged out of my account and agan visited https://redacted.com/login
The login page appeared again where I entered my credentials and intercepted the same login request which was like following:
POST /api/authentication/login-2fa HTTP/1.1Host: redacted.com
Content-Length: 100
Sec-Ch-Ua: "Not)A;Brand";v="99", "Brave";v="127", "Chromium";v="127"
Sec-Ch-Ua-Mobile: ?0
Authorization:
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36
Content-Type: application/json
Accept: application/json, text/plain, */*
Utcoffset: -420
Sec-Ch-Ua-Platform: "Windows"
Sec-Gpc: 1
Origin: https://redacted.com
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://redacted.com/login
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Priority: u=1, i
Connection: close
{
"email":"admin@redacted.com",
"password":"PASSWORD",
"loginFrom":"ADMIN",
"deviceId":"8709184523"
}
This time when I forwarded the request, rather than going to the page where I had to enter my OTP, I was directly logged in to the site. Hmm! Seems weird.
Let’s break it down what’s happening here.
Intially after seeing this scenario, what came in my mind was that when we login to the site for the first time in a browser, it uses deviceId to keep track of the user. Let’s say after logging in, if a user enters the right OTP when logging in for the first time, the application assumes that this deviceId is of legitimate user due to which when user logs through same browser for the second time, the browser confirms that the deviceId is of legitimate user and rather than prompting the user to the page where user needs to enter OTP, the user is directly logged in to the account. Fair enough! Let’s see what could go wrong here.
I opened my second browser and again visited the login page at https://redacted.com/login
Now after entering the credentials, the request looked something like following:
POST /api/authentication/login-2fa HTTP/1.1Host: redacted.com
Content-Length: 100
Sec-Ch-Ua: "Not)A;Brand";v="99", "Brave";v="127", "Chromium";v="127"
Sec-Ch-Ua-Mobile: ?0
Authorization:
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/127.0.0.0 Safari/537.36
Content-Type: application/json
Accept: application/json, text/plain, */*
Utcoffset: -420
Sec-Ch-Ua-Platform: "Windows"
Sec-Gpc: 1
Origin: https://redacted.com
Sec-Fetch-Site: same-origin
Sec-Fetch-Mode: cors
Sec-Fetch-Dest: empty
Referer: https://redacted.com/login
Accept-Encoding: gzip, deflate
Accept-Language: en-US,en;q=0.9
Priority: u=1, i
Connection: close
{
"email":"admin@redacted.com",
"password":"PASSWORD",
"loginFrom":"ADMIN",
"deviceId":"3502118317"
}
Here when I forwarded the request I was prompted to the page where I need to enter the OTP. This thing was because the deviceId in this second browser was different from the first one.
I again visited https://redacted.com/login , entered my credentials, captured the request using BurpSuite and in this request, I replace the value of deviceId parameter with victim’s deviceId parameter which was already verified as legitimate user and bingo! I was logged in confirming that my assumption is right.
So what’s the attack scenario? In order to bypass 2 Factor Authentication, attacker just needs to know the deviceId of victim and rather than getting displayed a page where he needs to enter OTP after logging in, the user will automatically be logged in without any need to enter OTP.
Tip: Don’t hesitate of testing your target based on any assumption that is made in your mind. You never know which assumption can get you a cool bug. :D
So this is it for today. Let me know if you liked my writeup and make sure to give some claps if you did.
Also do follow me on Twitter. My handle on twitter is cyberpro151
Also connect with me on LinkedIn if you want by clicking here
Take care and Bubyee! ❤