Steve
I'm a PC, so shut up
Consultant
join:2001-03-10
Yorba Linda, CA
| reply to jansson_mark
Re: Anti-DNS pinning & DNS-rebinding attacks!
I had never heard of this before, but it's fascinating. I'll try to present an executive summary.
DNS Rebinding attacks
In the old days, browsers were susceptible to DNS rebinding attacks, which the paper notes have been known for a decade.
The idea is that you visit my website, which might be www.badguy.com, and your browser's first order of business is to look up the name in DNS to get the IP address. The DNS server for badguy.com — which I also control — hands out that IP address with a very short lifetime (the "TTL").
At this point your browser fetches whatever content is on my website, which in my case is malicious Javascript. But then my DNS server does something tricky: it changes the address of www.badguy.com that it hands out to this client.
When the Javascript code tries to reconnect to www.badguy.com, it again fetches the name from DNS (the old one having expired from cache), and this time it gets that new internal address. But since the browser thinks it's already cleared this hostname (same origin), it allows it.
If it's an internal address, this is rooting around for private resources, such as a company's internal confidential website, or if it's an external IP address, it could be an external address of a public webserver where the Javascript will attempt click fraud.
It's even possible to serve up a CNAME up record as the second address, so something like hr.corp.example.com and have the browser's own resolver look up the actual IP. But this is still treated as if it were the same origin as the original hostname.
This is DNS rebinding - the name is re-bound to shifting IPs over the course of a transaction.
DNS Pinning
Because this has been known for some time, browsers counteract this by using DNS pinning - this is a kind of internal cache that keeps name-to-IP lookups around longer even if the DNS record's TTL is very low: once it connects to a site by that IP, it's going to use it for a long while.
This explains, among other things, why when you change the IP address of your website in DNS, your browser requires a restart even if you flush DNS in all the resolving nameservers involved: the browser caches DNS data and does not honor TTLs.
DNS Pinning Weaknesses
All modern browsers support DNS pinning, though some of them can be fooled.
•IE6 and IE7 pin for 30 minutes, but if the hostname resolves to multiple IP addresses, it's possible for a clever attacker to force the "other" IP address to be used before the pinning time expires.•Firefox pins for 1-2 minutes (and the Javascript code and predict exactly when the pinning expires by looking at the system clock), and it can further be fooled to rolling over to a new IP more quickly than that.•Safari 2 pins bindings for one second, and I don't quite understand how that helps anything.•Opera appears to pin for around 12 minutes, but it can be tricked to rebinding sooner But this is just covering ways of fooling single-entity pinning: sometimes there is more than one party at the party.
Multi-pin vulnerabilities
The plugins such as Flash and Java also maintain pinning databases, but they are separate databases. This means that the web browser might bind www.badguy.com to one IP, while Flash binds to another. This leaves open all kinds of avenues of shenanigans.
One example is hijacking Flash to send spam via port 25/tcp, often using the enterprise's own mailserver to send it - Flash and Java can both be fooled this way.
These sometimes do require some elaborate orchestrations to make work, and some work only sporadically (some are hit or miss), but for things like click fraud they can be far cheaper than renting a botnet - the paper suggests one or two orders of magnitude cheaper.
Wow.
What this is not
This is not compromised DNS servers — the zones in question are all "legit" in the sense that they are authoritative for the domains being hosted. It does not involve DNS poisoning that we see here now and then, and in all cases the nameservers are operating within spec.
This is also not phishing, because it's not presenting one website as another. All this bad stuff goes on mostly in the background, and the user is mainly not aware of it.
How to fix this
... involves actually reading the paper. I've just tried to touch on the high points that survey the area. The PDF is good, and though it's technical, it's done at a useful reading level.
Steve
--
Stephen J. Friedl | Unix Wizard | Microsoft Security MVP | Tustin, California USA | my web site |
