Solution For The Google CTF 2018 Hacking Contest

If you are an advanced hacker, one look will tell you that it is rather simple.  It is just a loophole on the client side. By analyzing the file catchat.js you will see that the “<” in the DOM is sanitized using the esc function to prevent cross-site scripting loopholes

You will find a display() function which is there to display values in chat by using the function insertAdjacentHTML().  It is a JavaScript function for extending HTML like InnerHTML(). It is one of the root cause of DOM-based XSS problems if it accepts user input in the form of HTML tags, so there is a chance of it being a loophole here.

Now we will have to take a look where the esc() function was used during output by display() and start from there.

You can see that the only place that hasen’t been sanitized is at ${you}. However, a hacker can’t control that value there which means that the code was written securely and sanitizing the value from user output prevents DOM-based XSS. Is it over?

Not really.  If you have good eyes and take a deeper look you will find a line that is more interesting than the rest:

Give it about 20 seconds, think about how you can hack it.

..

..

..

..

Ready?

Here the data.name value was pulled from local storage in the browser.  If you read closely you will know that it was given at random when you enter the chat room, and we can change that on our own through /name, which means it is a value that a hacker can control, indeed. However, this value is sanitized so we can’t use  “<” or “>”, if we type something such as:

The value is converted by esc() and it will turn into:

But what is interesting in this context, is that even if we can’t enter JavaScript commands directly, we are still able to enter CSS commands.

The question is how. How can a hacker put CSS into a hack?

There is a technique in CSS that can be used to steal information on DOM in the form of a side-channel attack. Lets say the password on the webpage is 1234 and if we attack it by using XSS we would be able to see the password and grab it. But CSS isn’t able to read the value and pull it directly. It may pull the information by using other factors that we got from other indirect ways. This is called side-channel attack (for example using a high frequency microphone to listen to the sound of the CPU to steal the password instead of directly take the password out of memory).

In CSS, we can use a selector to jump to the HTML tag with various attributes. Plus, if the selector we use points to any tag, we can do something with it.

For example:

If a selector finds a tag with an id name, then the CSS code that we specify in { } will work. In this case, change the background image to catbg.jpg from localhost:1234.

Oh, wait! How is changing a background picture to a cat dangerous?

It is dangerous if the hacker can control the CSS that is put into the victim’s web browser. If the CSS looks like this:

For example: you want to use the selector to find the input tag with the attribute name passwd, then check that the values are starting with a, b, c, d …. The value of the selector is the value you want to steal. A simple example is the credit card number input field on online shopping websites.

Once we figure out the beginning letter of the value, go ahead and put in the background picture that we pulled from the URL so that it will send the value that was found. In this instance the password is s3cr3t so the first letter is the letter s.

The CSS selector that checked whether or not the first letter is a, b, c.. will not show a match until it gets down to the letter s. But when it does, it will pull the URL containing the letter s. In the picture above, it will set the background picture from the URL path  /s of the hacker’s web server. As a result, a hacker will know that the first letter in the victim’s passwd field is s. By utilizing this concept, a hacker can write a script that will pull the sensitive data on the victim’s web browser and will be able to obtain the credit card number or password piece by piece. In our case, using we will match the next letters, sa,sb,sc,… and so on. In the end you will be able to pull all the digits from the form within just a few seconds.

If we understand the technique of stealing information using CSS then we can go back to analyzing the code once again.

We can inject the CSS code through the name with the /name command. The CSS name will not use “<” or “>” at all. For example, data.name is like this:

Once the DOM evaluated it, you will get the value

A simplified CSS looks like this:

On to the next problem. Look carefully at the server.js code.  The values are not just protected with esc()but there is also hardening with a Content-Security-Policy (CSP).

In this case, the problem is that we are not able to use the CSS technique to steal informations with a side-channel attack and send it directly to the hacker’s server. The URL in the background picture uses a CSP directive value which is:
default-src 'self'

This means that the value of the src attribute, including the URL in the CSS, must be from the same origin (self). ).  So, sending it directly to the hacker’s server is impossible.

Even if we can’t steal from the website directly via an attacker’s website, we are still able to do it in another way. It is merely a side-channel attack that uses another side-channel attack on top of it. The chat application has part of a Web API that is used when sending and receiving messages, those are /send and /receive and will allow a simple CSRF hack

Simply put, CSRF will make the targeted site user do something. In this scenario, we are going to design the attack in the following way:

We use a CSS selector to point the bait to the value we want. They will be checked individually, if it is a letter such as “a”, we will do CSRF to send the letter back to us into our chatbox!

Actually, the term CSRF isn’t completely correct in our case. CSRF is shortened from Cross-Site Request Forgery. The targeted request would be sent to the hacker’s website upon entering. So, the word cross-site means different website but in our case it is within the same website. We would need to call it Same-site request forgery or maybe just think about it being like XSS.

The server-side code itself has a protection against CSRF by checking whether the referer came from the same host or not. If the check is done correctly it is a good way of protecting against cross-site requests (in this case the check was done incorrectly, but you will have to guess how). Because of auto-GET/POST/AJAX, the browser would certainly send the referrer unless a loophole is found in the browser. But not in this case as it is same-site.

With this CSS method we can construct a CSRF payload as a HTTP GET request:
background-image:url(/send?name=admin&msg=a);

Once the injected CSS is executed in the context of the browser of the target (administrator) the request will be sent automatically. It would make the administrator send the letter “a”, if the CSS Selector matches. But wait, wouldn’t it run into CSP? The answer is: no, it won’t, as the origin is within the same website which makes default-src ‘self’ not able to prevent the sending of the request.

Now, we can use /report to have the administrator come into our chatroom for 10 seconds. Once we got the administrator in the room, we can do a CSS injection by changing our name to malicious CSS code and then entering the word dog to our chatroom so we will get banned. Then the application uses the display() function to display the CSS from our name in the DOM and this CSS will appear on the administrator’s screen and let the hacker control CSS on the opened screen of the administrator. The next question is, what is it that we want to steal from the administrator? Once we read the code, we will find that the administrator has a /secretcommand.

This contest is called capture the flag, our goal is to hack and steal the flag. You can see in above client-side JS that we have a chance to pull the flag from a cookie and it will be appearing in the chat room as HTML, if we can get the value one by one with CSS selector.

The person that has the flag in the cookie is the administrator and this code will make the flag appear only in the chat window that only the administrator can see.

<span data-secret = "Suppose the flag is located here"> ***** </ span>
But the problem is, that in the beginning the website won’t show this span and it would only show once there is an update with the flag value by using /secret <input new value> , which means even if we can steal from that span tag, we would get a value that changed. (Precisely, we need the original “flag” value in span but the span only shows when the value is changed, it is a deadlock.) It won’t be the original value that was in the cookie!

But if we look at the code of the server-side JS once more, we will find another loophole:

See? The regex is used to pull the value after /secret, which is the new value of the flag, into arg[1] and then used to replace the cookie’s value of the original flag that we wanted and then the client-side JS will show the new value.

At my first glance, I thought there might be a vulnerability called HTTP response splitting, but I already tried and it didn’t work because the modules in Node.JS provided good protection. However, with a little bit of creativity we can make the administrator set the value of this cookie flag by not overwriting the original value and also use client-side JS to pull the original value back into the chatroom by not having to do a CRLF injection. We will do a CSRF by CSS injection as above to make the administrator send the /secret message to give the flag a new secret value. Here’s how it’s done…
1; domain = xxx.web.ctfcompetition.com
To call this cookie injection wouldn’t be wrong.  Once it is used and return into HTTP response we would get:
Set-Cookie: flag=1; domain=xxx.web.ctfcompetition.com; Path = /; Max-Age = 3153600

As a result, the cookie flag on the chat page is set to cookie flag = 1 by the administrator. But it will be in an unknown sub-domain xxx instead of doing it in the actual website which results in the value of the flag of the cookie to remain the original for cat-chat.web.ctfcompetition.com and doesn’t get overwritten.

After that, with the help from the client-side JS we pull the value of the cookie to display on the webpage. It pulls the original value because when you pull the cookie(‘flag’) by document.cookie you would get the value from the same origin and not the one in the sub-domain that we faked with CSRF.

Recap of the outlined hacking techniques:

1. Bypass XSS sanitization by using CSS injection
2. Bypass CSP by using src (of CSS’s background image) from the same website
3. Bypass Anti-CSRF by using same-site request instead
4. Bypass Cookie Overwritten by cookie cross-domain injection (I made up the name, don’t know if it exists or not)

Done with the theory. Let’s look at the actual tasks before we get lost.

The first step is to open up the chat room, then copy the URL to another browser. (or use incognito mode, it will be fine as long as it has a different local storage context)

Use it with the browser on the right. It’s easy just copy the output and then paste.

Then switch to the browser on the left and type “/report” so the administrator will enter the room.

Then switch to the browser on the right and type anything that has the word “dog”.  That will make the administrator ban the user in the browser to the right.

Once the user is banned, the display() function will pull the name that has that malicious CSS injected and broadcast it to everyone in the chatroom (to tell that the user got banned). The administrator will see it as well. To summarize, what the CSS payload will do is this:

1. Start with cookie cross-domain injection so that span[data-secret] appears in the chat room of administrator’s web browser, plus the flag value retrieved from the original cookie.
2. Do a side-channel attack with CSS by checking one selector at a time, starting from the first one.
3. Once you know what the first letter is, do a CSRF via CSS injection and have the administrator /send the one that was found back into the chatroom with background:url(). (The people that will see the CSS injection includes everyone in the chatroom but the only one that will give out the value is the administrator as nobody else has the cookie flag, and even if a span pops up it will be a blank value that won’t match.)

Once you get the first letter, repeat everything for the next letter by using a simple regex. Add prefix to the flag, let say the flag is “abc” then we will find the first letter with ^= . Once you find it then enter ^=a, if you find b then put ^=ab etc., until the last letter and at the end you get abc.

Keep doing it until you get all the letters, then we can chain everything together. All these techniques combined will let us steal information (the flag) on the web browser that the administrator has opened on the screen.