I've been playing around with DNS pinning over the past few weeks; mainly on how the presence of proxies affects the story, which Rsnake and Portswigger beat me to (nice work guys), but also on various other bits.

Something that's caught my attention, especially following David Ross' comments on how IE does not actively implement DNS Pinning, is that the Firefox's DNS Pinning behaviour (if it does it at all) is rather interesting:

It seems that all you have to do to make Firefox rebind is wait a minute or two. The normal explanation of how the attack needs to work is as follows:

1. Client is fooled to request a page from attacker, client's resolver looks up attacker and is told that attacker is at yyy.yyy.yyy.yyy.
2. Client requests a page from attacker (at yyy.yyy.yyy.yyy) and is returned a page containing a script which tells client to come back later
3. Once this is served, attacker changes its DNS so the RR for attacker now points to zzz.zzz.zzz.zzz. Attacker also firewalls off its webserver.
4. When client comes back to refresh the page (or whatever the script told it to do) it discovers the server is down and rebinds DNS
5. Client then connects to what it thinks is attacker but which is actually the machine at zzz.zzz.zzz.zzz
6. The script served to client by attacker can now read content from zzz.zzz.zzz.zzz and pass it on however the attacker wishes

It seems that with the Firefox behaviour, attacker no longer needs to carry out the firewalling step; it simply needs to serve a script which is told to wait for something between 80 seconds and 2 minutes. The amount of time seems to change; I suspect the browser has a resolver cache which is cleared periodically but I've not really looked to find out whether this is the case.

This has some interesting implications:

• If you don't need to firewall off the webserver, it's much easier to make use of more than a single host; many targets of this type of attack will sit NATed behind a firewall, and even selective firewalling would block other potentially useful client machines
• The original 'Princeton' attack on applets (and presumably various browser plugins) can perhaps still be made to work without relying on a proxy just by timing things right.

I'm sure the rabbit hole goes much deeper than this. Let's see what happens.

Update: In my tests I'm sending responses to the original request to attacker with Connection: close; maybe this is affecting the behaviour?

Update 2: Having tested my theory on applet attacks; I think this is not possible.

Responses[2]

Posted by Mark Goodwin on 19 July 2007 19:27:00 BST #