[conspire] Kaminsky presentation slides

[Rick Moen]

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

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.