Cross-Origin Jackpot: $1,500 for a CORS Misconfiguration

A Hacker's Blog | ~root@clover:

The Low Down [TL;DR]:

Hello all and welcome back to another AHB post! Understandably, there hasn’t been a blog post since October 1st.. a whole month 😅.. This partially being due to burnout and majorly associated with laziness. I haven’t been lazy in all sectors of my technical hobbies but writing these blog posts has been a soft spot for sure.

I have been working on creating a web application that eases my recon methodology when it comes to manual recon. I plan on implementing automation into this web application as well but for now I am creating essentially a central hub for my recon workflow and results. I am working on this in a local environment but plan on releasing it in the future when I feel it is worthy of doing so.

In the month of October, I was able to secure a $1,500 bounty due to pretty sick CORS misconfiguration that allowed me to generate an attack chain that led to Account Take Over (ATO)! This was the only bug that I submitted in October and it was triaged as a ‘High’ vulnerability! Since I currently only do Bug Bounty part-time while working as a System Administrator full-time, I am okay with making an extra $1,500 for one bug with only putting in around 10 hours of hacking this month and the rest of my spare time into developing. I am still chasing down the goal of 500 all time reputation on HackerOne and I am so close!.. I am happy with my all time signal score as well as my impact!

The Vulnerability

During manual inspection of one of the core assets of my target, I stumbled upon a user-accessible page that held valuable pieces of sensitive information: session IDs, unique user IDs, full names, and email addresses. This data was displayed directly on the page once users logged in, presumably for their reference. To explore any potential risks, I tried loading this page within an iframe, hoping to manipulate it from my own domain, but quickly realized this path wouldn’t yield much. The page’s display in an iframe didn’t allow me to interact with the data in any impactful way, so it seemed like I’d hit a dead end. But that’s when things got interesting.

While poking around, I noticed that this same sensitive information was being fetched through a network request to a specific API endpoint. It wasn’t a typical endpoint, but one designed to deliver this PII-laden data as a response when accessed in a browser session. Upon accessing this API endpoint directly, I noticed a CORS misconfiguration in which this endpoint could be accessed via an attackercontrolled.com domain and the response assigned “Access-Control-Allow-Credentials: true” and “Access-Control-Allow-Origin: https://attackercontrolled.com” which meant a hacker using ‘attackercontrolled.com’ could interact and see the response when requested from their domain or “Cross Origin”.

Burpsuite Repeater tab showing CORS misconfig.
all information has been redacted and endpoints have been modified.

The endpoint would allow requests from any external origin—as long as the request was sent from a browser with an active session on the target site. Essentially, this allowed me to bypass the site's internal access restrictions if a user was logged in, turning my own domain into a vehicle for extracting this sensitive data.

To take advantage of this misconfiguration, I crafted a JavaScript payload hosted on a page I controlled. When a user, already logged into the target site, visited my page, my script made a cross-origin GET request to this vulnerable API endpoint. Since the user’s browser carried their active session credentials, the endpoint responded with the same sensitive data as if the user had accessed it directly. My script then scraped the response, capturing the session ID, user ID, first and last name, and email address—essentially all the data needed for account compromise—and logged it to a .txt file on my server as a proof of concept.

Escalating Impact to One Click ATO

I knew that if the only proof of concept I had was a link on my website that I had to convince users to click to steal their information, the severity/impact of this report wouldn’t hold as High so I needed to think of a way to increase impact if I wanted to make it worth the report. Thankfully, this program (like mostly all other programs), doesn’t accept Open Redirect vulnerabilities as valid bugs unless further impact can be proven. With this in mind, I returned to my notepad of gadgets for this target and pulled out an Open Redirect on a login page of their main domain.

This was a clever Open Redirect as I had figured out a way to bypass their whitelisted redirect domains to be able to redirect users to any arbitrary domain after they log in. This was perfect as I needed the user to be logged in upon hitting my website that hosted the malicious JavaScript. The reason being, the browser had to have an active session cookie for the endpoint to display the PII. This would essentially allow me to steal the information from the CORS misconfiguration with “one click”! This open redirect gadget was what sealed the attack chain for One Click Account Take Over via CORS misconfiguration. 😁 

Final Thoughts

My final thoughts for this post would be to always trust your gut when you feel that you should. Upon my initial discovery of this page displaying information, I felt like something weird was up but couldn’t find anything else right away to confirm my suspicions. After sleeping on it for a few days and asking around (but not getting much for answers) I took another look at it from a different perspective and ended up popping the bug! I came back to this page because my gut feeling told me there was something there, and it’s been right every time with this program.

I also think another very important take away from this write-up is to ensure you’re finding and back-pocketing gadgets during your recon for your targets. I think that if I wouldn’t have had this Open Redirect gadget this reports severity would’ve been reduced to a Medium as the user interaction goes up in the CVSS calculator when you have to convince them to visit your site. With this being said, having the ability to go back in your notes and grab and use a gadget to create a chain for something else you found is a great feeling and super clutch.

Last but not least, look for the unusual/uncommon things in web applications. In most modern day applications, you don’t normally find CORS misconfigurations.. at least I don’t 😅. In-fact, this was my first ever CORS misconfiguration bug bounty report, I believe this is an important learning lesson as this goes to show you can find things you don’t typically look for when you change up your perspective. If sticking to the norm isn’t helping you succeed, maybe try to break out of the box and try something different that you don’t believe will work right away. Always work until you see results/progress and the progress/results doesn’t have to be huge but it should be enough to reflect value in your time spent. ~ this goes for everything in life <3

Want to follow my bug bounty adventures? Catch me on Twitter @actuallyclover!

Resources: