In short,
Airbnb hosts an annual CTF competition inviting engineers across the tech industry by company to participate and play. Atlassian was cordially invited, ofc. And I’m immensely proud of my team for coming in 3rd out of all Atlassian teams, and 14th overall. Shoutout to the security folks at Tiktok for coming out on top.
Big team love for ✨Vibe Hackers ✨
On one of the “easier” web app challenges, I accidentally discovered a Host Header SSRF vulnerability in the ctfd platform hosting the CTF challenges. And got the flag. I mean it’s called capture the flag right?
With permission, this is a writeup surmising the hack, and sharing a hilariously ticklish story of a ridiculous Wednesday afternoon. Enjoy!
Tools Used:
- Burp Suite
- As Atlassian Security Engineers, we get business access to the pro license
Challenge Hacked: The Search
From the challenge + hint we can infer that the vulnerability is something in the frontend: think xss, csrf, etc. And from the website, you’re greeted with a gigantic text box which further confirms the theory. Even though it’s an injection issue, we can infer from the last comment that it won’t be a SQL injection because it’s a Frontend Vulnerability. And we can also likely rule out Stored XSS as a potential vuln because that would require the application to store the data.
Step 1: Understand the Application
The UI is pretty minimal and includes a gigantic text box. Given the hint “Front End,' XSS sounds like the correct vulnerability.
Not pictured is a page to view the answer, and a button to click that would “check your answer”.
Step 2: Play with the Application
Writing a <h1> element to the DOM
In no short List form, here the things I tried:
- random XSS Injections:
<script>Random js in here</script> - document.write (modifying DOM elements) which worked partially because the CSP policy only prevented any JS from running
- writing script tagged elements into the DOM
- writing document elements that would run XSS on error
<img src=1 onerror='javascript:alert(1)>
- checking random hidden endpoints
- checking /robots.txt
- checking .git
- Using the Target Tab on Burp suite and trying to map site for hidden endpoints
And then I checked my scan results, opened the first item, and noticed that the Burp request modified the Host header..
Step 3: My Unintended Solution
At the start of the challenge, I had started a scan in BurpSuite in an effort to be resourceful. Little did I know it would reveal a back door.
The /check endpoint is vulnerable to a HTTP Host Header Attack.
Read More here
https://portswigger.net/web-security/host-header
Replacing Host Header with Collaborator value == Ta-da
How to get the flag:
- Find a /check request in intercept proxy history and send it to Repeater
- Go to collaborator and click “Copy to clipboard” which copies the url server (thanks BurpSuite Pro)
- Replace Host header with the copied value as seen in photo
- Hit send
- Go to Collaborator tab and click “Poll now” button
- You should see a bunch of new requests pop up (if they weren’t there already), 1 of them is a HTTP request - open it
- Under the “Request to Collaborator” tab, you can see the request sent to collaborator from the vulnerable server with the flag set as a cookie header: flag
Hack Explained
From the hint, and the flag, it’s pretty obvious that this was not the intended solution. I realized this hours before presentation. Whoops.
The technical explanation is that the CTFd’s server doesn’t validate the Host header URL in the backend. So when the server makes an additional request to get the answer in it’s checking functionality, the backend server will default trust the Host header url and send the request with the flag in the header to the host header url. Effectively leaking the solution. Given a user controlled url like our server url from collaborator, we are able to steal the request by controlling where the request is send through the server.
This scenario showcases a Host Header Injection vulnerability that led to a Server-Side Request Forgery (SSRF) on the CTFd platform, which in turn allowed me to leak the flag.
Read more to understand each vulnerability at the links below:
So the Demo…
The demo confirmed that my solution was indeed a hack
Everyone else completed the challenge with the intended Solution strategy: host a dependency at the CSP allowed dependency server to inject the XSS to leak the cookie. But it was nice of everyone to trauma bond over finding the right XSS script to get the flag. And to recommend we get bonus points.
It also turns out that CTFd was at the Demo and they started investigating the situation soon after. Here is their email response to some of my questions:
Thank you for submitting this and participating in the event. Some of us are in the closing call as well and we are investigating what you were discussing.
While this isn't the intended solution, since you got the flag it's still sufficient so good job!
Likely it's best classified as an bug stemming from an architectural decision. Essentially our load balancers for challenges operate at the TCP level but HTTP challenges like the one you're talking about have specific intricacies that aren't factored in by the load balancer.
In addition since the challenges themselves have to be written to be vulnerable they need to do things that might not normally be done in a regular application.
I will keep this conversation in our tracker for a follow up when we fix it.
— CTFd
Fini
With that being said, I will leave you with this quote from a famous philanthropist that inspired my solution:
“I will always choose a lazy person to do a difficult job because a lazy person will find an easy way to do it.”
— Bill Gates
