How I bypassed 2-Factor Authentication in a bug bounty program


Hello readers, This post is about one of my recent finding in a private bug bounty program on hackerone. For the sake of privacy, let’s call the site as bountyplease.com According to Bountyplease.com scope, they are more interested in Authentication related issues. So I decided to test their 2-Factor Authentication mechanism.
As normal 2-Factor Authentication flow the process works in the following steps.

1. User login to account by providing valid email and password 2. A valid OTP send to users register number 3. User fill OTP 4. Login successful

But in case if any user lose their phone or SIM card the process works in the following steps.

1. User login to account by providing valid email and password 2. User select other options 3. User provide backup codes 4. Login successful



In both above described cases there is also a code flow as following.

1. User login to account by providing valid email and password 2. At this stage bountyplease.com display a page to submit 2FA code send to phone along with a link to go user account in top right corner of website as shown in below image.

3. If user click on go to user account link menu without entering 2FA code, then bountyplease.com redirect you to same 2FA enter page.
From the above scenarios we can notice that bountyplease.com maintaining two different sessions.

1. When user provide valid email and password but not 2FA code. 2. When user provide valid email, password and 2FA code.

After understanding all the code flows I quickly moved to backup code generation part. So at the account setting page the following sample API request is used to get backup codes.

Request
POST /api/totp_auth HTTP/1.1
Host: secure.bountyplease.com User-Agent: <redacted> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate Referer: <redacted> Cookie: <redacted> Connection: close Upgrade-Insecure-Requests: 1 Content-Type: application/x-www-form-urlencoded Content-Length: 104 {"action":"backup_codes","clusterNum":"000","accountId":"test123","email":"test123@gmail.com"}
Response
HTTP/1.1 200 OK
Date: <redacted> Server: Apache-Coyote/1.1 Strict-Transport-Security: max-age=15768000 X-Frame-Options: SAMEORIGIN x-content-type-options: nosniff x-xss-protection: 1; mode=block x-frame-options: SAMEORIGIN Cache-Control: max-age=0, no-cache, no-store Content-Type: application/json;charset=UTF-8 Content-Length: 328 Connection: close { "backupCodes": [ "K5J5dCD767", "ETYGw5JJTG", "6CfJADML9J", "D2ETo8623M", "M664EpEB3S", "99R227lH9L", "SELKZ8TPAH", "L8WGF6A38X", "WRNK7H2HG8", "9ZPF2YTJTE" ], "email": "test123@gmail.com", "hash": null, "key": null, "qrUrl": null, "reason": "", "succeeded": true }

So the above API request fired in 2nd case of session scenario (defined above) since we are logged in to account. Now what if we fire the same API request using 1st session scenario i.e. when user provide valid email and password but not 2FA code. So I quickly logged out and logged in again with valid email and password. As expected bountyplease.com redirected me to 2FA page. This time I provided the wrong OTP code and captured the request and made following two changes in request -

1. Replace the original Destination to POST /api/totp_auth HTTP/1.1 2. Replace the original parameters to {"action":"backup_codes","clusterNum":"000","accountId":"test123","email":"test123@gmail.com"}

And in response I got all the backup codes. Now attacker can put these backup code at 2FA place and get into victim’s account.
So this is how I was able to bypass 2FA of the bountyplease.com I reported this issue to them and they fixed the issue in a short span of time.


Thanks for reading.




Comments

  1. But I have a confusion that is How by replacing the 2FA with the backup code, use to get authenticate into the victim's account? As there is no OTP, Only email, key etc etc.

    ReplyDelete
  2. is not understanding well, will be nice a video PoC

    ReplyDelete
  3. Nice find brother....can we say it as session puzzling attack ?

    ReplyDelete
  4. Sweet does that mean you would have been able to do other user action as well using the first session? Since you are able to make post request to get codes.

    ReplyDelete
  5. This comment has been removed by a blog administrator.

    ReplyDelete
  6. This comment has been removed by a blog administrator.

    ReplyDelete
  7. This comment has been removed by a blog administrator.

    ReplyDelete

Post a Comment

Popular posts from this blog

Story of a JSON XSS