OK, I was reading this article http://www.gnucitizen.org/blog/one-drop-on-a-spider-web where pdp talks about an interesting use of the "name" DOM window property to perform a stealth XSS, similar to the classic URL fragment one where the payload is stored in location.hash, but when you're limited to just /[a-z0-9\(\)]/ (no dots).

The limitation of this vector, though, is that you need to control the name of the window, either using the target attribute of the originating link or the name attribute of an iframe.

So I thought, is it possible to make an equally stealth attack with the same allowed characters constrains, but self-contained in the URL like the original eval(location.hash.substring(1))?

It took 1 minute to figure out this:

with(location)with(hash)eval(substring(1))

Can I have my place in the XSS cheat sheet? ;)

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript



Edited 1 time(s). Last edit at 06/25/2007 11:45AM by ma1.

damn this is cool! n1!

Really nice find - love the evasion techniques :)

http://www.the-mice.co.uk/switch/ Switch/Twitch
http://code.google.com/p/dotnetids .NETIDS

cool stuff!

i tried a demo of this and it worked great. i especially like the stealthy factor, how the server doesn't even see the payload. that was new to me.

http://www.gnucitizen.org/blog/playing-in-large mentions a shorter variation like...
eval(location.substr(92))
so using your trick, this would be something like:
with(location)eval(substring(92))
but when i tested that variation, it didn't work. have you tried that one? I guess I need to read up on my javascript dom structure.

thornmaker: are you sure you counted the characters before the fragment identifier conrrectly? (92)

http://www.the-mice.co.uk/switch/ Switch/Twitch
http://code.google.com/p/dotnetids .NETIDS

Awesome find, ma1. I've never personally come across a situation like that, but I will save it for future use. I'm not on my computer at the moment, but I'm a bit confused by pdp's find.
In order to have a payload execute wouldn't you need to first set the name attribute, and through a third-party page? Perhaps I've misread, or misinterpreted the information, but wouldn't you need to physically place the URL in an IFRAME on your own domain in order to first specify what would be used as a value for the "name"?


Awesome AnDrEw - That's The Sound Of Your Brain Crackin'
http://www.awesomeandrew.net/

Very nice find,ma1!!
I love this type of vectors. :)

-------------------------------
http://fr3dc3rv.blogspot.com

@Awesome Andrew:
Yes, pdp's technique requires you to set the name property from the attacker page.
To do so you need a certain control on its content, i.e. you must be able to put either an anchor with the target attribute or an iframe:

<a href='http://victim.com?injectable=";eval(name)//' target='alert(document.cookie)'>XSS</a>

or

<iframe src='http://victim.com?injectable=";eval(name)//' name='alert(document.cookie)'></iframe>

In other words, not your classic, easy "forum post link" XSS vector...

@thornmaker:
as Martin said, the "shorter" technique relies on the fact you precisely count the characters of the URL preceding the fragment: 92 is not a "magic number" :)

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript



Edited 1 time(s). Last edit at 06/25/2007 07:22PM by ma1.

right, i wasn't using "92"... I counted out the exact number, 28 in my case, and no dice. I probably have a typo somewhere... will look into it tonight.

thornmaker Wrote:
-------------------------------------------------------
> right, i wasn't using "92"... I counted out the
> exact number, 28 in my case, and no dice. I
> probably have a typo somewhere... will look into
> it tonight.

Don't mind trying. It won't work anyway because location is not a String object, hence it exposes no substring() method.

--
*hackademix.net*

There's a browser safer than Firefox... Firefox, with NoScript

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.


Awesome AnDrEw - That's The Sound Of Your Brain Crackin'
http://www.awesomeandrew.net/

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. That 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.

I've never come across a situation where information following the Octothorpe has been used for any purpose other than simply being an anchor. I'm not doubting it may be useful in certain situations, but a majority of the time the usual fragment identifier vector works quite well. I've read your blog entrys, and I would like to see your method in a worm however, pdp, as I can indeed envision some of the possibilities you have outlined. Depending on the different possibilities of a situation facilitated by a worm wouldn't you have to make the payload dynamic in nature in some cases?
To clarify that last statement what I mean is say for instance your worm has a multitude of functions to perform such as posting a thread on a messageboard, which would then use a vulnerability in and of itself to redirect to the worm's originating third-party page, which would re-initiate the worm with a new host. Depending on the number of services, and websites, one plans on infecting would you not need to implement some form of a changing payload? Again, I'm not doubting your method as I understand your point and what you've outlined I am just curious.


Awesome AnDrEw - That's The Sound Of Your Brain Crackin'
http://www.awesomeandrew.net/