2FA bypasses for may-april 2022

 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...

Weird CSRF protection bypass

 

Intro :

- I hope you're doing well guys . For being honest I'm not a fan of write ups but some kind of findings should be disclosed . Let's go this is a vulnerability that I found on one of hackerone private programs . The funny thing that It was pretty easy for identifying it but totally complex for being exploited and that's the cool part .

Technical details :

 

 - So keep an eye on the illustrative picture while I'm explaining the process let's start from up to down

- You may notice that the http method is a delete method which means that a written exploit in this case isn't going to look like the traditional CSRF exploits . In cases where the affected request is using methods such as PUT/DELETE we can use " _method " parameter ( a post request with a put or delete request inside it more technically this kind of behaviors is called method overwriting ) but it's limited to some frameworks or we can initiate an ajax ( xmlhttpreq ) with the particular http method and for sure this is applicable only to cases where the cors configuration of the vulnerable application is not validating the origin properly. Google and javascript documentations are your lovely friends so don't hesitate to take a peek on them .

- The second thing is the Content-Type header . As you expected there was no validation for the content type ( There was some restrictions but I don't think that those restrictions were implemented based on a security concern that's why it wasn't a big deal for bypassing them ) 

 - The third factor are the http header that are holding the CSRF tokens ( TB-CSRF-Token and X-XSRF-TOKEN )  There was no validation for those headers in the server side so if you remove them or remove their values nothing happens this is a vulnerable behavior but still not enough for making this scenario possible to exploit, basically that's due to the double cookie submission prevention ( I'll explain how it works in the next sections but for now take a look on the picture exactly on the highlighted csrf tokens in the cookies ) those tokens are csrf cookie double submission prevention . Briefly what happens is that they're protecting the website from CSRF exploits even if the CSRF tokens in http headers aren't getting validated.

- Now the fourth thing to check is the origin and referer headers . They weren't validated . Yep this is a good news so when we run our exploit on the victim browser the website isn't going to validate where the forged request is originating from.

- Now let's get back to the tokens in the cookies . The first thing that you should know is that the PLAY_SESSION is the session cookie. Now let's look at that cookie parameter that is called XSRF-TOKEN you can notice that it has the same value of CSRF tokens in the http headers so what is that ? this is the double submission csrf prevention as you know an attacker has no way to access the victim cookies during a CSRF attack but he has the ability to remove or manipulate the tokens that are implemented on http headers or a request body . This is the time where the double submission prevention starts to play, in the server side the backend code is going to make a small comparison between the csrf tokens submitted by http header or request body and those in the cookies so if the attacker was able to manipulate them he is not going to be able to manipulate those in the cookies and the server side comparison will fail ( and for sure the csrf attack would fail too ) . More info on csrf double submission prevention are here https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html

- Another thing that I didn't understand is that there's another csrf token tied to the session ( PLAY_SESSION ) as you can see ( I highlighted it )  why a developer is supposed to tie a csrf token to the cookie session that was pretty confusing to me. The only scenario I can imagine in this case is that the tied token is a second way to perform the double submission csrf prevention .

-  Now how we are supposed to test if the double submission prevention is properly implemented or there's a way to break on it . This is pretty simple, remove the tokens in the http headers but don't touch the tokens in the cookie then forward the request if the process succeed without any errors it means that there's no comparison in the server side and the double submission prevention is useless in this case .

- This is what happened exactly there was no validation for the tokens in the http headers in the server side and there was no comparison between the tokens in the http headers and those in the cookies which made the vulnerability possible to exploit .

Takeways :

- Don't get confused when you see a lot of CSRF tokens.

-  Most of time I get paid for vulnerabilities that are complicated and to be honest I look for them most of the time. Why ? simply because most hackers like to get paid easily but they don't like complex vulnerabilities so don't give up without trying when it looks un-exploitable .

- When I was testing this private program I found that the affected endpoints are the login and the account deletion. But the email changing endpoint was properly implemented and not affected. I mean if you're testing CSRF on a target website don't make random conclusions that if the email endpoint isn't affected the rest of endpoints too aren't affected but test each one separately .