Kaminsky's DNS Attack Disclosed, Then Pulled 281
An anonymous reader writes "Reverse engineering expert Halver Flake has recently mused on Dan Kaminsky's DNS vulnerability. Apparently his musings were close enough to the mark to cause one of the Matasano team, who apparently already knew of the attack, to publish the details on the Matasano blog in a post entitled 'Reliable DNS Forgery in 2008.' The blog post has since been pulled, but evidence of it exists on Google and elsewhere. It appears only a matter of time now before the full details leak."
Reader Time out contributes a link to coverage on ZDNet as well.
Re:The push for DNSSec (Score:5, Insightful)
DNSSec is still the only ultimate patch for this. Source port randomization just makes it difficult to do given currently available processing and bandwidth capacity. Instead of 16 bits of entropy to crack (DNS Transaction ID) we now have rougly 32 (DNS Transaction ID + Source port).
Given enough bandwidth, we're still vulnerable to poisoning, but it's not feasible today.
DNSSec is more future proof. No matter how much bandwidth you have, guess a full certificate is orders of magnitude harder.
Long story short (Score:1, Insightful)
Pick a few hundred ISP name servers. Craft packets with the the source address as that of your victim's name server's IP address and start sending them to the ISP name servers on your list.
Sooner or later, due to the non-randomized tracking number used by DNS requests, your false DNS replies will be accepted by one ISP nameserver. Because you set the TTL for the DNS record to be very high, the record will live in the ISP name server's cache for VERY long. Now all the ISP's customers will come to an IP address of your choosing when they type www.victim.com.
The internet is now 0wned.
What I was thinking is spraying the end users with spoofed DNS responses. Sooner or later, some would use your response to resolve the name but obviously poisoning an ISP name server is more profitable.
If this really is *the* attack then it was lame of the *researchers* to try and hide it. I am sure 1000s would've guessed it by now. The exploit is really simple with dozens of packet crafters out there
Here is hoping that the real vulnerability is a lot harder to exploit.
Re:The significance of the attack... (Score:4, Insightful)
Posted it on: http://rudd-o.com/archives/2008/07/21/the-dns-fiasco/ [rudd-o.com]
Re:The push for DNSSec (Score:5, Insightful)
BGP routes are filtered when they're exchanged between eBGP routers. If you don't filter, you're an idiot. This I agree with.
You're not talking about BGP route filtering, though; you're talking about some kind of reverse path filtering (making sure that a route to the source address exists on the interface that you received the packet from). In practice, you almost never do this on BGP routers, as RPF makes some (somewhat naive) assumptions about the symmetry of Internetwork traffic.
Most people who have some kind of RPF deployed have it on a customer-facing device, as you generally only have one route per customer (and can make assertions about traffic NOT coming via that route, AND traffic COMING via that route.)
That said, not an awful lot of people even have RPF deployed. Certainly nowhere near 100%. And it only takes one (or a handful of machines) that can forge UDP source addresses for this to be an issue.
Re:A: Because it breaks the flow of a message (Score:5, Insightful)
Frankly, we should just do away with the subject line entirely. They generally just get filled with "Re:Re:Re:Re:Unoriginal First comment" anyways. It serves no purpose in a system like slashdot's, and causes things like the above.
Re:Here's the whole post (Score:2, Insightful)
An answer may be to use the glue to perform any lookup that can use it as part of that query, but never allow the glue itself to create a cached DNS entry; i.e. to have a life outside that lookup.
Except perhaps caching would be ok, if the cached result can be re-used _only_ when repeating the very same lookup that yielded the glue, the populated additional section.
This approach segments the returned additional section from the rest of the zone (helps constrain the poison to the one subdomain)
Re:The push for DNSSec (Score:3, Insightful)
Actually, for multihomed sites it's even easier.
Getting BGP feeds from nearly every provider requires giving them your AS numbers (including those of all your downstreams and upstreams), and IP blocks- you already have the source routing information. They do this to prevent you from publishing routes for microsoft.com into some black hole someplace.
In fact, many ISPs do infact drop packets with an "invalid" source address- one that they couldn't have learned. All ISPs should do this, and immediately render most practical UDP attacks moot.
Re:The push for DNSSec (Score:2, Insightful)
*ding* You win a cookie. That's exactly what we're saying. There are more ISPs that don't filter traffic than those that do. IP filtering is expensive business at ISP traffic rates. My little Cisco 1760 handles the 5-7Mbps that goes through it rather well. Multiply that by thousands, and that's what ISP's deal with. (Note: a full rate DS3 will swamp a 2851, and that's a pretty damned expensive bit of gear. but it's cheaper than a DS3 PCI(-X/e) card.)
Re:The push for DNSSec (Score:2, Insightful)