Wednesday, September 24, 2008

Dynamic XSS Payloads in the face of NoScript

While participating in the CSAW CTF on the weekend before last with s0ban, sirdarckcat and maluc (which we won btw, with 16375 points; RPISEC who placed second had 13575 points, go us ;), I had an interesting thought; one of our attacks was a persistent xss attack that loaded it's payload from off-site so that we could gain some level of persistent control, however I realised that this attack would fail completely in the face of NoScript even if our xss succeeded since the person would not have our malicious domain whitelisted.

So, in light of that, I was thinking of how we could load our payload from off-site, without the remote site running JavaScript. Of course, I am assuming you have already bypassed NoScript's XSS Filters (e.g. because the attack was persistent), but this information is particularly useful for persistent attacks when you may want to change the payload.

After thinking about this for a while, I realised that we've already solved the problem a while ago when we were talking about using TinyURL for data storage way back in 2006: http://kuza55.blogspot.com/2006/12/using-tinyurl-for-storage-includes-poc.html.

Of course TinyURL would be of no use to us here as we are interested in being able to change our payload, however all it would require to be useful is (possibly some kind of synchronisation so that we execute in the order we want, rather than the order we get data back from our evil web server and) changing the URL to point to a domain you control.

Nothing really ground-breaking, but something interesting nonetheless.

3 comments:

Anonymous said...

What about loading the dynamic content through an injected script tag that makes the payload available via global javascript variable? It could be loaded using an open proxy on a trusted domain...granted you won't have 100% coverage, but chances are good that many people have the trusted domain whitelisted.

kuza55 said...

Abusing an open proxy would work of course, but most sites don't have those, and using this method would not require anything other than the xss-ed domain to be trusted, so IMO it is simply a safer bet.

Gunwant Singh said...

cool stuff!