I'll try to keep it short.
- In February I tried to follow the theory of learning one bug at a time and see how it works. I picked MFA bypasses or in general term, any endpoint that has an OTP validation on it. I've done a 2 weeks research that resulted in a checklist of 31 MFA vulnerabilities checklist.
- Although I didn't try all of the gathered techniques in the real world but these are some study cases of common/uncommon techniques that I've got them to work.
1- Private Hackerone
Status ( fixing )
State ( duplicate )
- Basically this was about a technique called force browsing. When MFA is enabled on the application. A request with valid credentials to the /login endpoint would redirect you to the /mfa endpoint to validate your OTP. The app assigned a temporary JWT to my account when I was redirected to the /mfa endpoint, but after some basic checks I've confirmed that the temporary JWT had access to all of the api routes which means that we are fully authenticated and there's no need to validate the OTP.
exploit : just force browse from /mfa to /account or /dashboard or any authenticated path LOL.
2- External Redacted
Status ( fixed )
State ( Accepted )
- API version degrading. Probably you've stumbled upon a rest api during your hunting journey, probably you've also noticed some versioning stuff going there like /api/v1/ etc... In my case when the MFA was enabled on the application. A request with valid credentials to the /api/v3/login api route would redirect you to the MFA validation endpoint. When I tried to hit the login route but with a lower version ( /api/v2/login ) with the hope that an older version is still up, the application responded with a 500 status code. So I gave it one last hit to an even older version /v1 ( /api/v1/login ) which resulted in being redirected directly to the dashboard without having to provide a valid OTP to the MFA endpoint.
exploit: Login with valid credentials => intercept the request using a proxy => change the api version on the login request from /v3 to /v1.
3- Tencent ( DNSPOD )
Status ( fixed )
State ( Accepted )
- This was a pure application logic error root cause. There was two subdomains the first one is www.dnspod.com and the second one is console.dnspod.com. When you signup to the dnspod you'll be prompted with a billing page to fill out your credit card information. The whole idea is that leaving the billing form empty would directly result in an MFA failure. In other words when you enable the MFA feature that is presented on the console.dnspod.com ( which is just a management panel for the dnspod account ) the MFA will only work if your billing information are filled too, otherwise you'll be able to enter the account just by providing the valid credentials.
exploit/impact : The MFA won't work for accounts with empty billing information.
4- Tencent ( Intl Cloud )
Status ( fixed )
State ( Accepted )
- This one was fun. The intl cloud is basically located in intl.cloud.tencent.com and console.intl.cloud.tencent.com is the account management panel for the intl cloud. The whole idea is that if you enable the MFA on the intl cloud it will work normally, and an effective MFA process will pop up on each login attempt. Everything was working properly and it was a dead end for me until I figured out that the DNSPOD and the Intl Cloud accounts are somehow linked. In other words if you sign up to DNSPOD there's no need to re sign up to the intl cloud as the DNSPOD credentials will also work for the Intl cloud. But what attracted me was that users are able to login to the intl cloud through the dnspod in other words by signing in to the dnspod you can just visit the intl.cloud.tencent.com and you'll be logged in to the intl cloud. Probably at this point you've already figured out an attack scenario, so basically if the MFA enabled on the intl.cloud.tencent.com every login attempt from that subdomain will be redirected to the MFA validation endpoint, but if an attacker uses the DNSPOD ( www.dnspod.com ) as a login page he'll be able to login to the intl cloud without having to provide any MFA tokens.
exploit: an attacker would use the dnspod login page instead of the intl cloud login page ( as they use the same credentials ) after a successful login attempt to the dnspod the attacker visits the intl.cloud.tencent.com subdomain and he'll be logged in without providing any MFA tokens.
Happy hunting...
