[TAG] (forw) [conspire] Kaminsky presentation slides
rick at linuxmafia.com
Thu Aug 7 03:57:58 MSD 2008
----- Forwarded message from Rick Moen <rick at linuxmafia.com> -----
Date: Wed, 6 Aug 2008 16:52:29 -0700
From: Rick Moen <rick at linuxmafia.com>
To: TAG <tag at lists.linuxgazette.net>
To: conspire at linuxmafia.com
Subject: [conspire] Kaminsky presentation slides
Dan Kaminsky gave his "Black Ops 2008" talk (continuing a series he's
been giving for years at LISA conferences and elsewhere) about two hours
ago at Black Hat, Caesar's Palace, Las Vegas. No downloadable audio
file (one very nice thing about LISA conferences) yet, but Kaminsky has
committed PowerPoint: http://www.doxpara.com/DMK_BO2K8.ppt
0. Bad guy induces a nameserver to issue queries for 1.foo.com,
2.foo.com,... and floods it with forged responses delegating the
query to claimed nameserver (or CNAME alias) "www.foo.com", and
trying to race that info back before the genuine response does.
Any response that succeeds and gets cached also carries the
(unrequested) "ADDITIONAL INFORMATION" datum that the forward-lookup
IP of www.foo.com is $EVIL_IP. That unrequested info then gets
cached for a _long_ time-to-live (TTL). Voila! Cache poisoning.
Notice that the forged, malign data is in-bailiwick for foo.com.
1. There are a huge number of ways to induce "safe" machines behind
firewalls to ask about hostnames of an attacker's choosing:
Java, etc. (though an attack can use those Typhoid Marys to
induce severe mischief by inducing reverse-DNS lookups).
o Practically any part of an attempted SMTP mail delivery.
o Logfiles that do reverse-DNS lookup (e.g., Web servers).
o "Web bugs" in documents.
o IDS paranoia that makes _them_ do reverse-DNS lookups.
(Kaminsky talks at length about ways to make this scale, practical,
and more revealing of details of company-internal networks.)
2. Making sure UDP source ports are random is a stopgap, as DNS's
protocol design leaves it pretty unreliable. (Duh.)
3. DNS clients (resolver libs) are a little vulnerable _if_ you
can flood them with fake responses -- but at least don't cache.
4. Web (etc.) SSL certs don't necesssarily paper over the problem,
because of dependency on DNS. (For example: Did you make your
browser trust my Thawte cert for example.com? Cool!
That means it'll typically also accept my cert for paypal.com
that has the same signature. Or, hey, if I can convincingly forge
paypal.com's DNS, I can register a Thawte certificate for paypal.com
myself, because I can make the confirmation mails come to me.
Ditto, almost everyone's "I forgot my password" link trusts DNS
to some extent.)
5. Risks also affect some internal networks, for several reasons including
active internal code and routing that rely on DNS. (Duh.)
6. NAT is a sore point.
Choice quotation from the first slide:
"-- I found a really bad bug a while ago.
o You might have heard of it...."
As usual for a Kaminsky talk, he's also done quite a great deal to trace
out possible ramifications. Recommended.
 All the more reason to lock the resolver library to communicate only
with the host's own nameserver on localhost. Short of that, anything
you do to eliminate packet spoofing on your local LAN will help.
conspire mailing list
conspire at linuxmafia.com
----- End forwarded message -----
More information about the TAG