[hcs-d] "Massive" DNS Vulnerability - Is it really that bad?

Joshua Kroll jkroll at hcs.harvard.edu
Tue Jul 8 21:06:12 EDT 2008


On Tue, Jul 08, 2008 at 08:41:38PM -0400, Greg Price wrote:
>On Tue, Jul 8, 2008 at 7:15 PM, Joshua Kroll <jkroll at hcs.harvard.edu> wrote:
>> We've known that DNS is vulnerable to spoofing for a long
>> time. Nothing has changed. There aren't even new attacks out there
>> (well, there are plenty of new DNS attacks, but they aren't this
>> heavy-handed). Wouldn't it be better to use a firewall that was clever
>> enough not to let 33,000 DNS packets through in only a few ms?
>
>It doesn't take 33000 packets in a few ms; 3000 will give you a 5% hit
>rate, which is enough to phish a lot of people, and if it has the
>birthday vulnerability you can make just 500 requests and 500
>responses for a hit rate over 80%.

Maybe. This would rely on you being able to make the requests. It's
unclear that an attacker would be able to initiate requests for a
popular website, which is likely already cached. I suppose you could
try to submit your requests at exactly the time the TTL expired, but
you'd have to sample quite a bit beforehand to get enough accuracy to
hit your window, which is about 30ms on an average query (less if (as
is likely) you don't have to go to the root).

Even with the birthday vulnerability (on the TXN ID, not the port
space, which is what this vulnerability seems to be about), it should
still be the case that getting the packets off in time is pretty
hard. Though I agree it's not that hard. Remember, though, that the
birthday vulnerability would only apply if the attacker and the name
server drew their random numbers at the same time. That's not the case
- the attacker is trying to hit a specific number for a particular
query.

Your point about the 5% is well taken, though. You can keep trying the
attack every time the TTL expires, so you really only need to try it
20 times to win the game. Or if you could automate it, you could hit
thousands of nameservers and then check to see which ones you had
poisoned. But this isn't really a new problem. And even with 32 (well,
31.999999656) bits of randomness, you still get a one-in-a-thousand
chance of winning in a scenario where you can construct a birthday
paradox (say if you're polling many nameservers) with only about 2100
packets.

We need DNSSec, for what it's worth, though that won't fix
everything. Rumor has it that DHS will oversee the signing of .gov and
.mil this summer. Also, g.root-servers.net and h.root-servers.net will
be signed under the same project.

>Plus it sounds like some implementations failed to properly
>randomize the space they had.

It's true that many attacks have been made against TXN ID
randomness. And such things have been fixed across most
implementations. Well, sort of. It's likely the case that BIND 8 & 9
work. Windows is sort of iffy, being a BIND 4 derivative, by which I
mean BIND 4 with a GUI.

Source port randomness hasn't been around for a long time, though, and
people have known that this is a problem. So if you mean that
implementations failed to properly randomize the source port, then the
better choice of words is not "failed to" but "decided not to."
Randomizing source ports is a good idea, but discovering that nobody
is doing it (and, as it seems, combining this with other bad
randomness issues) doesn't seem like earth-shattering research to me.

>I guess it's not clear how much of this is news, but when vendors
>supply fixed versions (as Ubuntu has), it's certainly worth upgrading.

Note that this only applies to Ubuntu servers running BIND 8. And
really, if you're running BIND 8, you're asking for a whole mess of
trouble. I guess what gets me is that this seems to be making a splash
of the form "nobody panic, but the shit just hit the fan." And that
doesn't seem to be the case to me.

Of course, I could be wrong.

Josh


More information about the hcs-discuss mailing list