Tuesday, July 10, 2007

DNS pinning and web proxies

DNS-based attacks against browsers have been known about for years. These attacks have received increased attention recently, following the discovery of defects within browser-based DNS pinning defences.

So far, discussion has focused on browser issues. However, the same attacks can also be performed against web proxies. Browser-based DNS pinning does not apply when a web proxy is being used, because the DNS look-ups occur on the proxy, not the browser. Hence, even if DNS-based attacks are completely addressed within browsers, the problem is not going to go away altogether.

The most significant opportunities for DNS-based attacks are against web users on internal corporate networks, as a means of gaining unauthorised access to sensitive information and web applications on internal intranets. Given that a large proportion of these users access the Internet via a proxy server, attacks against web proxies may represent at least as significant a threat as those against browsers.

I've written a short paper which explains the problem, examines possible software-based solutions, and describes the defences that organisations and individuals can use to prevent attacks against them. In summary:
  • DNS-based attacks affect web proxies as well as browsers.

  • Today's proxies are vulnerable.

  • The problem is not straightforward to fix in software.

  • You can protect your own infrastructure against these attacks.


kuza55 said...

Thanks for the paper, it was quite interesting, especially the solutions section. Though I do think you left out a few things in a cuple of solutions.

In "Solution 4: Perform DNS resolution in the browser" you did mention that it would add security issues like not being able to block content, but you didn't mention that this would completely break some sites which require a Host header to be sent.

And for "Solution 6: Leverage the browser to implement a per-session DNS cache", you don't really outline any way to deal with the first connection form any given browser, where no cookie is sent, so it seems to me that something like that could easily be attacked.

I personally think most of the damage of Anti-DNS Pinning can be stopped by not allow DNS entries which previously resolved to external IP addresses to resolve to internal (i.e. non-routable) IP addresses, like the LocalRodeo Firefox extension does. sure we can still defeat IP checks, but those aren't all that common these days.

PortSwigger said...

@kuza55, Thanks for your feedback.

Re #4, sure the Host header would still be sent, just like it is when browsers aren't using a proxy and so do their own DNS resolution. What changes in this solution is the URL in first line of the request to the proxy, which would contain the IP address not the domain name.

Re #6, there is no problem. As I said, if the cookie isn't received, the proxy performs a lookup in the normal way and uses the resolved address. Because this is the first resolution of that domain name for the present browser session, there is no threat at this stage from DNS swapping.

Re your suggestion, anything relying on the RFC1918 addresses won't be an all-purpose solution, because not everyone uses them. But I agree - it is a "hack" that could potentially address a large part of the problem.


kuza55 said...

Sorry I took so long to reply, I haven't had access to the internet for the last couple of days.

Ok, the problem I see with #4 and allowing the client to send host headers is this:

You're allowing the user to tell you where a site is. If your proxy then trust this information (which could be sent by an attacker, through Anti-DNS Pinning in Flash or Java/LiveConnect - or possibly other methods - which could poison the cache)

And in #6 if we stop the cookie getting sent, then we're back to square one where the cache is doing the resolution independently of the user, and its vulnerable to Anti-DNS Pinning, right?

I can't quite remember how I was thinking of stopping the user sending the cookie though, so I can't quite recall what the threat model here was, sorry.......

And I'm not sure where RFC1918 addresses would not fix the problem, since all internal addresses are RFC1918 addresses, right?

PortSwigger said...


I've seen lots of organisations that use non-RFC1918 addresses on their internal networks. But even if they are being used, your fix may not stop an attack. For example, most DSL routers run a web interface on their internal NIC, for administering the device. In most cases, if you are on the internal network, and request the admin interface using the external IP address, you can still access it. Access is controlled on the basis of which network interface your request arrives on, not which IP address you used.

In my solution #4, the Host header functions in precisely the same way that it does in today's browsers. The proxy does not use the Host header to route your request - it does so on the basis of the URL in the first line of the request. So an attack modifying the Host header won't make any difference re DNS pinning. That attack might do other things - like poisoning the cache in invisible proxies, for example - but if so then those attacks exist anyway, and do not result from any feature of solution #4. Anyway, solution #4 doesn't work for the reasons I gave in the paper.