My jounery of getting scammed by external bounty programs

Hello there, Few days ago I've reported vulnerabilities to an external program called optiCutter:

The flaws that I've found were:

- Full response Server Side request forgery on www.screenshotmachine.com
- Full account takeover via a CSRF on www.opticutter.com

- Full account takeover via a CSRF on www.screenshotmachine.com
- CSRF in editing the API key for www.screenshotmachine.com which allowed me to add my API key to premium accounts and use they're premium API access using my API key.
- A site wide CSRF on test.opticutter.com www.opticutter.com and screenshotmachine.com including its subdomains which resulted in bugs with various severity from account takeovers to editing and adding new projects.

The company response:

Basically they said that CSRFs are not an issue as the user has to be logged in and they offered 20€ as a payment:



And when they were asked about CVSS this was their answer:



Anyways I refused to take the 20€ and stopped testing as it wasn't worth it, usually when I am hunting on an external program I would provide a detailed report for non technical readers including a Video poc and the PoC code to make my bugs easy to reproduce no matter what background the reader has.

In fact I could have kept reporting issues for free if they nicely asked. But the way they tried to lower the severity even tho it wasn't low it was pretty much a red flag to stop putting hours in and moving to the next target.



CSRF PoC:

As I mentioned before the whole web apps including subdomains were vulnerable, so I'll provide one poc but the same exploit can be applied to every single endpoint on the target:

Scenario: No csrf token was set in place, the requests content type is form url encoded which can be sent in cross site requests, there was no same site attribute to prevent sending the cookies in a cross site request.

poc:

SSRF PoC:

www.screenshotmachine.com has a screenshot feature that you can feed it a url and it would respond with a screenshot to you, apparently to prevent SSRFs they blacklisted 127.0.0.1 127.1 and IPv6 versions of localhost but somehow they totally forgot that 0 and 0.0.0.0 are valid localhost IPs, Basically this was very straight forward bug you can control the URL schema the host and the port fields of the URL

This was the vulnerable request

By feeding http://0:80 to the url parameter you'll get a successful response with the screenshot URL path in it, If you request that path you'll be presented with the screenshot.

As I mentioned before the URL schema is also controllable so your imagination is the limit when it comes to exploiting this behavior.


Takeaways:
- It can be hard to hunt on bug bounty platforms such as Hackerone Bc etc ... considering the amount of competition and how your bugs severity gets lowered in some cases, but shit happens, I came to a point where I started to appreciate how safe it is to do bug bounty on a platform.
- If you're willing to put the time in an external program, ask for recommendations from other bug hunters, in my case I didn't and I literally kept finding bugs at every step I do, I wasn't expecting a 4 digits reward, as I knew it's a small business but I also didn't expect to get scammed either.

If by any chance you're a client of optiCutter I hope that by now you came to realize that your information and data is worth 20€ to them.

Have nice day everyone...

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 .