Tonight, we have bad news and worse news. The bad news is that the node is yet again the scene of imminent collapse of the Internet as we know it. The worse news is that the fix that could have fixed it ... is still not deployed. The no-news is that we warned about years ago. It's still not done.
Dan Kaminsky, a hacker of some infamy and humour, gave a son-of-black-hat talk on DNS Rebinding. What this means is that when you go to a site that has a malicious applet or Flash or something, then your node becomes controlled (that's your PC, desktop, laptop, etc) for attacks on other nodes.
Now, I don't fully understand the deal ... and details were difficult to follow ... but it is something to do with weird things with DNS that allow a malicious site to download bad code into your applet/flash/javascript weakened browser. Then, that code literally takes over and turns your node -- your PC -- into an internal attack-dog under someone else's whistle. Dan uses the example of the printer down the hall, but in finance circles this is the internal derivatives accounting system down the hall, already smoking from too much recent attention.
Yes, Firefox and IE are both victims.
The DNS details were scary and voluminous but rest on a basically sound claim: DNS isn't secure, and that we know. It is possible to hand the requestor all sorts of interesting information, and that interesting information can then be used to trick through firewalls, IDS, etc, and compromise the machine, because it is "authoritive" and it comes from the right machine, your machine, your soon-to-be-owned machine.
Curiously, the object of Dan's project is much more grandiose than that. He's looking to do a bunch of weird measurements on TCP, using this DNS rebinding to bootstrap in and take over the TCP connection. Yeah, MITM, if you spotted the clue.
(I'll repeat that, Dan claims to be doing MITMs on TCP!)
To summarise the raw claims (again, given my limited understanding):
Fixes: No easy fixes, just temporary patches. DNS is operating as normal, it never was secure anyway, and the modes and tricks used are essential for a whole lot of stuff. Likewise, Flash, etc, which seem to have no more security than windows did in 2002, isn't going to be fixed fully, any time soon. (Dan mentioned he is waiting on Adobe to fix something before full disclosure, but that runs out as someone else is about to publish the same results.)
Here's the old worse news: Dan stated, as near as I can recall it:
"TLS solves the problem completely, but TLS does not scale to the net, because it does not indicate the host name. This puts more of an indictment on the standards process and on TLS than anything else, we've had TLS for years now, and we still can't share virtual hosts on TLS."
Yes, it's our old friend TLS/SNI (ServerNameIndication), a leprechaun-like extension that converts TLS from a marginal marketing differentiator at ISPs into a generally deployable solution.
SNI is available in Firefox, 2.0 and later. Thanks to Mozilla, they did actually started a project on this called SSL v2 MUST DIE because of its ability to help in phishing (same logic, same fix, same sad sorry story). It is fixed in IE7, but only in Vista, so that's short thanks to Microsoft. Opera's got it, and they might have been the first.
Yet...
TLS/SNI is not available in Apache's httpd nor in Microsoft's IIS.
Indeed, I tried last year to contact the httpd team and plead for it. Nothing, it's as if they don't exist. Mozilla were even prepared to pay these guys to fly & fix, but we couldn't find anyone to talk to. Worse, they have had the code for yonks. The code builds, at least the gnutls version. The code works:
I got proof that Microsoft's team exists, and that they also have no plans to secure the Internet this year.
Shame, the very shame! Apache's httpd team and Microsoft's IIS team are now going to watch 3 years of pain and suffering, for the want of little fix that is so old that nobody can recall when it was added to the standard.
(OK, that's the last I heard. There might be updates in the shame. You understand that it isn't my day job to get you to save the net. It is however your day job, Microsoft team, and night job, Apache team, and you can point out current progress in the comments or on your blog or in the very code, itself. Please, we beg you. Save our net.)
Addendum: a rebinding patch! and some more from the department of snails.
Posted by iang at August 16, 2007 06:59 PM | TrackBackMaybe I'm missing something, but I think the theory behind DNS rebinding attacks is actually pretty easy to explain; see the paper "Protecting Browsers from DNS Rebinding Attacks" by Jackson et.al., it's quite understandable. (It's the second Google result for "DNS rebinding"). The authors propose a defense which doesn't require SSL/TLS but rather involves the use of DNS records to allow servers (i.e., the ones to be defended) to specify which hostnames are valid for their IP addresses, as described in section 5.4 of the paper referenced. This requires action by the owners of IP addresses and some extra code in the browser to implement checks of the relevant DNS records, but no change in Apache or IIS, and no need to switch to TLS for all traffic.
However independent of the DNS rebinding issue I do agree it's a shame that SNI support hasn't been added to the industry-leading web servers.
The best non-patchy solution to this problem is secure property titles (Google that phrase) to names.
Posted by: nick at August 19, 2007 06:57 PMThe problem isn't so much SNI but TLS extensions. I haven't seen a recent survey done, but one done when the RFC was still at the draft stage indicated that whoever turns these on by default is in for a world of pain from user complaints over sites breaking. If it took 15 years for SSLv2 to die, imagine how long it'll take before vendors will risk enabling TLS-ext in their browsers.
Posted by: Peter Gutmann at August 21, 2007 07:03 AM"The authors propose a defense which doesn't require SSL/TLS but rather involves the use of DNS records to allow servers (i.e., the ones to be defended) to specify which hostnames are valid for their IP addresses,"
I do not understand how this will work with caches, Akami, and other legitimate re-directs.
The system we are working on keeps your history, and shares history with your friends. There are also some thind party providers. Locally, the truncated IP address, the hash of the cert, and the domain name are stored. When there are changes in these, then the system indicates to the user that there is a MITM or pharming. So a change in IP address will not cause an immediate alarm, but repeatedly getting the same IP address will. Well, this is the part we are working on so its not in the working code. So this allows companies and people to protect themselves.
thanks,
Jean
Frank, Jean's response more or less matches what I recall of the Kaminsky talk. In theory there are lots of possible patches, but (in the opinion of DK) they suffer from sufficient deviations from current practice that they likely won't work.
Posted by: Iang at August 23, 2007 05:08 PM