Kaminsky's DNS hack

[fanf]

beezari posted a copy of the leaked Matasano explanation of Kaminsky's new DNS attack. I believe the explanation isn't quite right. In his interview in the WIRED Threat Level blog Kaminsky mentions that the attack relies on CNAMEs. This means that it does not depend on glue nor on additional section processing, which is what Matasano described. I believe the real explanation is...

$ md5 <~/doc/kaminsky
ef96f2d9e973a36e825793ddeff48ae5

Comments

[gerald_duck]

The problem, as I've noted before, is that nobody's going to take a copy of that md5sum and you can easily edit your posting later. :-p

(The other problem is that md5 is no longer strong enough for this kind of thing.)

[ex-robhu.livejournal.com]

Also, a blackhat probably poisoned your DNS server so you're not really viewing fanf's LJ ;-)

[simont]

ef96f2d9e973a36e825793ddeff48ae5

fanf might be able to edit his LJ post, but he can't edit my comment. And if you reply to this comment, then I won't be able to edit it either (just in case you're worried we might be colluding).

[gerald_duck]

Well, LJ annotates comments that get edited anyway.

On the other hand, if he deleted the comments, who would miss them? More useful to me is that I've now been e-mailed a copy of your reply to my comment. (-8

[gareth-rees.livejournal.com]

I tried rate-limiting my e-mail based on this MD5 but it didn't slow down any virus attacks. Am I doing it wrong?

[fanf]

This comment is still giving me grins.

[pm215]

Somebody just pointed me at this exploit code: it doesn't seem to involve CNAMES.

http://metasploit.com/dev/trac/browser/framework3/trunk/modules/auxiliary/spoof/dns/baliwicked_host.rb

[gerald_duck]

A problem we now face — and the current security through obscurity can only exacerbate it — is that everyone and their dog is trying to work out what Kaminsky's hack is.

I wonder how many other problems are going to be spotted…

[fanf]

That's based on the Matasano description. See also http://www.caughq.org/exploits/CAU-EX-2008-0002.txt

Note that in the example they are attacking a name that doesn't exist in the public DNS and which isn't in the cache before they run the attack. I believe Kaminsky's exploit is more powerful than this.

[mas90.livejournal.com]

If I were to tweak the Matasano explanation to be more interesting, I'd say in the last-but-one paragraph that Mallory doesn't reply "CXOPQ.VICTIM.COM A 6.6.6.0", she instead replies "CXOPQ.VICTIM.COM CNAME WWW.VICTIM.COM.", with an additional RR "WWW.VICTIM.COM A 6.6.6.0".

If I understand correctly, that is definitely in-bailiwick since the additional RR is for the answer to the original query (it's equivalent to the normal use of additional RRs for NS glue) and will successfully poison Alice's cache for WWW.VICTIM.COM.

I don't expect you can confirm nor deny that this is what Kaminsky is getting at if you're in possession of the canonical explanation however :-P

[fanf]

I don't have the canonical explanation. All I have in addition to the above links is a post by Florian Weimer on the namedroppers list which also mentions CNAME. (Florian has known the details for months.)

Your description of the attack agrees with mine. The interesting bit is why CNAME is necessary, and additional RRs aren't enough.

[bens_dad]

Hmm. From time to time I wonder whether SMTP and its implementations are up to the demands put on them by today's internet, but what I read about this makes me think that DNS and specifically BIND are really struggling to keep up.

In this day and age caching answers to questions you didn't ask does some patently stupid.

[fanf]

You have to cache unasked-for records in some situations, glue being the most obvious answer. You could immediately look up the authoritative NS RR set using the glue in order to make the glue unnecessary. However if you extend this to other additional data then you defeat various useful optimisations. DNSSEC is the answer :-)

[bens_dad]

> However if you extend this to other additional data then you defeat
> various useful optimisations.

If these optimisations necessarily break security they must be dropped, however useful. If "useful" means that the internet will melt without them then we need a new system and to retire DNS.

> DNSSEC is the answer :-)
I take the smiley to mean that I shouldn't go ahead and use DNSSEC on my machines (at least not yet).

[fanf]

No, the smiley just means that DNSSEC has only a tiny amount of deployment and won't be very useful until the root zone is signed.