Saturday, April 28, 2007

Creating sockets to sites which run Google Analytics javascript without Anti-DNS Pinning

This is a short post, but I thought this warranted its own post, so that the message is not lost.

One of the repercussions of this post: http://kuza55.blogspot.com/2007/04/breaking-same-origin-policy-in-upwards.html is that any site which references the document.location property (e.g. any site running Google Analytics javascript) can be referenced by any subdomain.

And top level domains do not have to have any relation to their subdomain, so a DNS setup where these resolutions occur:

attack.target.evil.com -> web server controlled by evil.com
target.evil.com -> victim web server running Google Analytics (or other document.location referencing code)

Is possible. Now, since attack.target.evil.com can communicate with target.evil.com [1] as par my last post it can easily just insert a java applet (or with Firefox, javascript which uses the Java libraries) into target.evil.com, which will be able to create sockets to the web server's IP.

Another way the DNS->IP resolution scheme of subdomains not needing to be related can be abused is by making target.evil.com resolve to the IP of a service like myspace, which has a "domain generalisation" scheme, which will set the document.domain property to the second level domain, and so will resolve to evil.com, and evil.com can then create sockets to myspace.com.

And while, at the present this is a fairly pointless attack since we can still use Anti-DNS Pinning attacks, those problems may be solved before this.

[1] Note that all these attacks will only work if the hosts accept wildcard hostnames, and so the google analytics code is returned even if the hostname is incorrect.

7 comments:

Anonymous said...

I think about it before, because I don't know it can skip document.domain check, my idea is any site set their document.domain to location.hostname, but it is not common.
There is a problem, measure the host header can defeat it.
I think this method and Anti-DNS Pinning have their own advantages and disadvantages.

kuza55 said...

A but you can just use Java sockets instead of XmlHttpRequest to connect to the IP address of the server, and so you can forge whatever you want - you just can't send cookies; but you don't have any valid cookies anyway, so even XHR calls wouldn't send cookies.

Anonymous said...

It can use Java sockets to connect to target.evil.com from attack.target.evil.com without insert any code to target.evil.com?

kuza55 said...

Oh, now you have to write to target.evil.com to create sockets there, I thought you were talking about a scenario where you could.

I must be missing something.....

Anonymous said...

I mean when the first time connecting to victim web server through target.evil.com, It can detected by the host header and refuse the connection.

kuza55 said...

Ah yes, of course, you're perfectly right, they *could* stop it, and those which don't have wildcard domains allowed, will also stop this by default, this was just an idea for if even Anti-DNS Pinning gets fixed.

Anonymous said...

Though this method has prerequisite, I still prefer this method, Anti-DNS Pinning is much more complicated to accomplish.

I wonder how to fix or prevent from Anti-DNS Pinning attack? Is there any plan or method was suggested?