One Drop on A Spider Web

Mon, 25 Jun 2007 14:56:36 GMT
by pdp

On 6th February 2007, I've published an article titled Playing in Large, which discusses various ways of injecting large JavaScript payloads into tiny XSS holes. The technique that I used as an example is quite simple. In general, all attackers need to do is to place their malicious payload behind the fragment identifier (# sign) and evaluate it within the attacked application context. This can be achieved by using something like this: eval(location.hash.substr(1)).

This works really well when you are restricted in terms of the vulnerable field length. It was found that we can squeeze XSS payloads into 50 to 60 characters in size. Keep in mind that this is only when we use script elements (<script/>), which is by far the longest way of doing it. In some case, we can inject a couple of MBs of JavaScript inside a vulnerable application by composing a XSS string that is around 25 to 30 characters long.

Another interesting point to outline is that the fragment identifier technique is quite stealth. Every information that is behind the hash (#) sign is not sent to the server. The fragment identifier is only used on the client. This means that this technique is suitable for circumventing firewalls, intrusion detection and intrusion prevention systems.

It is recommended to check the Playing in Large article, if you are not familiar with this technique.

In this post, I will show you a technique that I have developed in the last half an hour, which is as stealth compared to what we have discussed before, but a lot smaller in terms of length of characters needed and does not require special characters such as:

  • dots .
  • square brackets []
  • spaces
  • other meta characters that are usually used inside JavaScript

The character set that is required is composed of lower case letters and the round brackets (). In order to explain how the technique works, I am going to lay out a hypothetical scenario which is as follows:

https://acme.com/vuln.php3?<code>"></script><script>alert(1)</script><!--`</code></pre>

It is clear that the example above is vulnerable to XSS. However, although we can alert the character 1 on the screen, we are not able to do anything else, mainly because the site converts special characters into underscores (`_`). This means that the payload: `"></script><script>alert(<code>document.cookie`)</script><!--</code> is converted to `"></script><script>alert(<code>document_cookie`)</script><!--</code>, which fails mainly because `document_cookie` does not exists. If we try to inject more complicated JavaScript, we pretty much end with the same problem. What's even worse, single quotes and double quotes are also sanitized.

One thing is for sure, we might be able to inject remote script files by using various browser quirks such as `<script src=domain/script`. However, these type of payload is unstable and require to host a file in a server in rather strange way. Remember, most meta characters are not allowed, including dots (`.`) and columns (`:`).

I was toying around this problem for a bit when I realized that the best way to bypass this restriction is to reuse something that is part of the DOM already. I needed something that fits into the following vector:

https://acme.com/vuln.php3?**"></script><script>eval(something)</script><!--**

... where something is a variable part of the DOM global space and can be controlled from outside. There are plenty of such kind of variables but not that many of them are suitable for the job. For example we can inject stuff into the referrer and try to evaluate that. It is possible but very complicated since we need to find a way of spoofing this information.

After digging into DOM I found a global namespace variable, which seamed that could work.

`name` is a global namespace variable that defines the name of the current window. Most of the time, `name` contains nothing but a blank string. However, once we call a page within an iframe or an object with the appropriate attributes, the `name` value is changed to reflect that. In order to see how `name` looks like when opened from a browser window and an iframe try the following:
  • create a blank html page with the following content: <script>alert(name)</script>

  • open the page within your browser - you should see a blank alert box

  • create a blank html page with the following content: <iframe name="test" src="path_to_the_first_page.htm"></iframe>

  • open the page within your browser - you should see an alert box with the message test

    All this proves that we can manipulate the value of the global namespace variable `name`. So how this applies to XSS?

    If you haven't realized yet, we can use this technique to circumvent filters in a very clever and quite sneaky way. Let's get back to our hypothetical scenario with the XSS vulnerability in acme.com which cannot be exploited easily. By using the technique I discussed above, we can bypass the restriction and here it is how:

If you take the code displayed above and place it inside an innocent HTML page, you will be able to XSS anyone who visits it and is on the acme.com domain, although acme does a good job of sanitizing some of the meta characters.

Some of the sceptical XSSers may not see the point of using this technique for a number of reasons. The first reason is based on the fact that there are other ways to exploit acme.com. This is true, but the example here was provided as a case study only. Very often we can alert(1) but nothing else, because the string needs to be short and can only contain standard characters. This is exactly when this technique is most suitable, because the character set is standard and eval(name) is a lot like alert(1).

Keep in mind that this attack leaves a very small footprint on the attacked system. The data that is contained in the name variable is never submitted to the server. It is worth mentioning that HTML/XML attributes are usually allowed to contain quite a lot of data which allows attackers to include entire XSS frameworks within the boundaries of name.

To summarize, the technique presented here allows you to inject JavaScript in places where the supported character set is usually not enough. The attack footprint is very small and the payload can exceed MBs of data. This makes this technique very stealth and extremely hard to detect. The technique is a combination of reflected/dom based XSS and works everywhere where attackers can simple inject `alert(1)`.

This technique was published in order to raise the security awareness in regards to XSS (Cross-site Scripting) attacks. There are more then one way of doing things, which we usually overlook.

Archived Comments

christ1anchrist1an
Very good writeup, I was doing quite a lot of research on this because such a situation was present on YouTube (//www.youtube.com/advertise) a few days ago.
pdppdp
what is interesting about this technique that is a combination of reflected XSS with a little help from the DOM.
pagvacpagvac
This is VERY powerful. We're saying that if we can run
<script>eval(name)</script>
as our XSS payload, then we can run JavaScript without any restrictions whatsoever. So when testing for XSS, if we get a blank alert box when injecting
<script>eval(name)</script>
then we know we can run absolutely anything by visiting a third-party page that embeds our magic iframe.
Giorgio MaoneGiorgio Maone
If yours is new, I guess I can patent the following:
with(location)with(hash)eval(substring(1))
Much easier to post everywhere, because it's self-contained and you don't need to control the window name. Cheers -- There's a brower safer than Firefox... it's Firefox, with NoScript - http://noscript.net
pdppdp
Giorgio, no one is patenting anything, but your trick is cooler I must admit. Nice stuff... I love it. However, mine is still smaller... :) but heck I love self-contained stuff so you win. :)
Giorgio MaoneGiorgio Maone
pdp, I was just kidding - Cenzic is enough about patents. Of course I wouldn't have figured out mine if I didn't read your [a-z\(\)] challenge, so many thanks for inspiration ;) -- There’s a brower safer than Firefox… it’s Firefox, with NoScript - http://noscript.net
pdppdp
Giorgio, I've totally ignored the with statement. To be honest with you, I am not using it that often. In fact, I cannot remember the last time I've made any use of it apart from the time when I tried to create a sandbox within JavaScript which didn't work, so I had to use full blown iframes to imitate similar characteristics. Anyway, great stuff. RSnake should include this one into his cheat sheet.
pagvacpagvac
Giorgio, That's a killer snippet. Thanks a lot for that.
pdppdp
Here you can find a snippet from a resent discussion on Sla.ckers.org about the techniques that were presented in this post
Awesome AnDrEw Wrote:
But then in essence I would see the technique pdp has found as relatively useless unless it was able to be done through some type of service within the site. What I mean by that is I would think it'd only be useful if say I had the ability to post an IFRAME within a messageboard on the site that I am targetting, but then again it still is of little value. If you can get a user to navigate to a third-party page then you've already won, because you can use your own payloads without cross-site scripting as a prerequisite unless you absolutely need to use the frame to target the site.
Use the right tool for the right job... although I find ma1 technique rather cool, it may not work in some cases. For example, changes in the fragment identifier wont result in page refresh which is what you might want to achieve in some cases. Also, there are ways to make the fragment identifier to go away via a series of redirections, which is something that happens quite often. Another bad thing about the fragment identifier technique is that although everything is inside the URL, it looks too suspicious. Very often, attackers will use a 3rd party website which upon user arrival does the actual exploitation. Not to mention the fact that in some cases the # hash is used as communication mechanism between frames which are served from different origins. Any use of the fragment identifier will break the communication. You don't want to do that if you want to be stealth. Here is an example. Let's say that you have a worm that exploits the user on several domains. For sure you can use the fragment identifier technique and compose URLs which are included inside a hidden iframe. However, you need to do all the manual work for nothing, when you can simply create the iframe, assign the name or the target with your payload and rotate the src value with the URLs you want to exploit. XSSED.com has tones of vectors that simply alert(1). All we need to do in order to make them work is /alert\((1|'XSS'|"XSS")\)/eval(name)/i and start rotating them inside an iframe. The chances of this technique to work are higher mainly because we do not add that much more characters into the payload. We don't have to do any characters counting and we don't have to think whether there is something before our code that makes uses of the information after the # hash. believe me, more and more applications make use of the hash today. To sum up... do not be ignorant. use the right tools for the right job. as you can see, there are real applications of the technique I described.
AcidusAcidus
I'm not sure if you all know it or not, but the contents of window.name are persisted across domains for the lifetime of the browsing context. This means window.name can be used to as a global session storage system. For example, site1.com writes a value into window.name. Any other websites that are visited in that browsing context (i.e. that browser tab or single browsing window) can read or write this value. In fact, I've got some cool demos where I track individual users across domains without web bugs/3rd part image server using JavaScript and window.name. In fact, we touch on this in the upcoming Ajax security book in our attacking offline Ajax apps chapter. I even wrote a source code compatible implementation for Firefox's sessionStorage object for ther other browsers.
pdppdp
Acidus, I didn't know that. Actually this is very funny. I cannot see to what extend window.name can be used for malicious purposes although it is sort of interesting since it is almost like some kind of global dashboard where everyone can leave a message. So, we can implement some sort of a system where sites leave information about the user inside window.name and other sites can reuse that information in a clever way.
asciiascii
i would like to patent (built on the maone's one)
KishorKishor
What about frame breaking code on acme?
pdppdp
Kishor, what do u mean?
asciiascii
i would like to patent (built on the maone's one)
<img src=http://w onError=with(document)with(e)eval(unescape(innerHTML))
please tell me when the registration process is finished : ) http://www.ush.it/2007/06/27/xss-cheat-sheet-two-stage-payloads/
pdppdp
ascii, I am opening a patent bureau. Please send your submissions to contact at gnucitizen.org or contact the GNUCITIZEN group at group at gnucitizen.org. thanks.
KishorKishor
This code inside the page which is vulnerable:
if (top.location != location)
  top.location.href = document.location.href ;
KishorKishor
As per Acidus's comments Here is what I tried out, 1.html:
window.name = unescape("alert('XSS!');");
and 2.html:
breakframe();
eval(window.name);
2.html still alerts XSS! So it means we can use window.name even if frame breaking code is present. So another 'with' may be necessary for window'.'
Giorgio MaoneGiorgio Maone
SirDarckCat and I are having fun with PHPIDS at http://groups.google.de/group/php-ids/browse_thread/thread/f689a9c8cc934867 Incidentally, he just added some extra spice to hash (fragment) payload attacks:
eval(unescape(location))
This works if you break the hash with a %0A (newline) before your payload, because:
"http:" gets parsed as a label "//host:port/path...#..." is ignored until newline (C++ style comment)
So simple, so nice :) -- There’s a brower safer than Firefox… it’s Firefox, with NoScript - http://noscript.net
pdppdp
Neato!