Tux

...making Linux just a little more fun!

[conspire] Kaminsky presentation slides

Rick Moen [rick at linuxmafia.com]


Wed, 6 Aug 2008 16:57:58 -0700

----- Forwarded message from Rick Moen <[email protected]> -----

Date: Wed, 6 Aug 2008 16:52:29 -0700
From: Rick Moen <[email protected]>
To: [email protected]
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

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 [email protected] http://linuxmafia.com/mailman/listinfo/conspire

----- End forwarded message -----


Top    Back