

...making Linux just a little more fun!
Rick Moen [rick at linuxmafia.com]
----- Forwarded message from Rick Moen <rick@linuxmafia.com> -----
Date: Wed, 6 Aug 2008 16:52:29 -0700 From: Rick Moen <rick@linuxmafia.com> To: conspire@linuxmafia.com Subject: [conspire] Kaminsky presentation slidesDan 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
Major points:
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:
o Web hyperlinks, with or without Typhoid Marys Javascript, Flash,
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.[1]
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.
[1] 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@linuxmafia.com http://linuxmafia.com/mailman/listinfo/conspire
----- End forwarded message -----