...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: https://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 https://linuxmafia.com/mailman/listinfo/conspire
----- End forwarded message -----