|)ruid and HD Moore release part 2 of DNS exploit

|)ruid and HD Moore release part 2 of DNS exploit

Summary: [Updated 07/24/2008: Gallery images of diffs of code revisions has been included and will be updated as things change, see here.]Earlier today, noted researchers |)ruid and HD Moore released exploit code for the Metasploit tool for attacking the DNS flaw that was originally reported by Dan Kaminsky.

SHARE:
12

[Updated 07/24/2008: Gallery images of diffs of code revisions has been included and will be updated as things change, see here.]

Earlier today, noted researchers |)ruid and HD Moore released exploit code for the Metasploit tool for attacking the DNS flaw that was originally reported by Dan Kaminsky. The release was only part of the bigger picture of the exploit; however, and the second piece of exploit code has been released on the Computer Academic Underground blog and on Full-Disclosure. There is a subtle but important difference in the two pieces of exploit code, which is only readily apparent from reading the comments in the source code. Part 1 of the exploit, released earlier today, is commented as below:

This exploit attacks a fairly ubiquitous flaw in DNS implementations which Dan Kaminsky found and disclosed ~Jul 2008. This exploit caches a single malicious host entry into the target nameserver by sending random sub-domain queries to the target DNS server coupled with spoofed replies to those queries from the authoritative nameservers for the domain which contain a malicious host entry for the hostname to be poisoned in the authority and additional records sections. Eventually, a guessed ID will match and the spoofed packet will get accepted, and due to the additional hostname entry being within bailiwick constraints of the original request the malicious host entry will get cached.

Part 2 of the exploit, released just moments ago, is commented as follows:

This exploit attacks a fairly ubiquitous flaw in DNS implementations which Dan Kaminsky found and disclosed ~Jul 2008. This exploit replaces the target domains nameserver entries in a vulnerable DNS cache server. This attack works by sending random hostname queries to the target DNS server coupled with spoofed replies to those queries from the authoritative nameservers for that domain. Eventually, a guessed ID will match, the spoofed packet will get accepted, and the nameserver entries for the target domain will be replaced by the server specified in the NEWDNS option of this exploit.

So let's analyze this a bit, see if we can figure out what's different. Good friend and noted researcher, Billy Rios, assisted me with some code review, and we tried to find as much as we could about this new twist on events. We found several things of note. The most obvious, the exploit just got worse. Now the code will use spoofed replies to hijack the name server entries for a target domain, allowing control over an entire domain, whereas the original hijacked an individual host. For example, before, we could hijack www.myaddress.com, now we can hijack all of myaddress.com.

Further, within the credits portion of the code, |)ruid adds credit to a new researcher for "helping with the NS injection" confirming the idea that this is now about attacking nameserver entries, and not just address records. The credits are listed below:

Credits ======= Dan Kaminsky is credited with originally discovering this vulnerability. Cedric Blancher <sid (@) rstack.org> figured out the NS injection method and was cool enough to email us and share!

Rios and I suspect that Cedric probably made use of the following from RFC 1035:

NS authoritative name server, code 2. Specifies a host name (which must have an A record associated with it), where DNS information can be found about the domain name to which the NS record is attached. NS records are the basic infrastructure on which DNS is built; they stitch together distributed zone files into a directed graph that can be efficiently searched.

Next, Rios clued me into a very interesting observation... as he said, "it went from rev 5585 5591 that's 6 different changes in a few hours... it's still being tuned." Which means it's going to get faster. Dan originally stated he could pull this off in a matter of seconds. With able programmers refining the existing code, it's only a matter of time before this exploit becomes lightning quick.

Work to make the exploit quicker may be confirmed by noting that there has been changes to the rand code for the xidbase.

So things are getting worse. If you have not patched by now... well, you're on your way to being pwned, so I'd get to it ASAP.

-Nate

Topics: Networking, Browser, Servers

Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.

Talkback

12 comments
Log in or register to join the discussion
  • So, Linux's BIND the first to be exploited...

    So, Linux's BIND the first to be exploited...
    Nice work!
    qmlscycrajg
    • Are you sure it's only Linux?

      Bind runs on many OS. And other resolvers are affected by this, including for example Cisco.

      I didn't check myself. Maybe the NS in the RR part of the trick is not the problem everywhere.

      Alecco
      alecco
      • I think he meant first one is Linux BIND

        I think that he meant the first exploit of this DNS vulnerability is on Linux BIND. BIND can be run on Windows and other OSes so Linux just happens to be Dan first test target and no only target.
        Here is CVE from CERT about the known vulnerable systems:
        http://www.kb.cert.org/vuls/id/800113
        This DNS exploit is really scary so patching ASAP is really imperative.
        phatkat
  • Cool

    Nate, nice post and analysis!

    Wasn't the replacing the ns.victim.com cache entry part of the Halvar Flake speculation? I thought first part of the exploit was to have a not fully working PoC on purpose :)

    Still, now it's ~32 bits of combinations to guess, so according to Birthday Attacks it would take 77k packets to reach 50% probability and something about 150k to get a closer to 100% chance. DNS needs to get sorted to use TCP for server to server, or use IPSec AH (much better.)

    Some friends are upset all this will help evil Verisign to push DNSSec and keep expanding their monopoly on certificates.

    Alecco
    alecco
    • Yes

      I think you are correct on the Halvar comment. Thanks, it was a long night, but worth the analysis.

      -Nate
      nmcfeters
  • On NS record replacement for other domains

    Wouldn't *any* nameserver be possible to replace?

    I thought spoofing the .com answer saying VICTIM.COM is served by ns.somethingelse.com and adding RR saying ns.somethingelse.com is at 6.6.6.0 would replace the cached entry of the nameserver and take over ALL domains served by it.

    Wish I had my old network of stuff to play with this :-/

    Alecco
    alecco
  • I think this is all terribly irresponsible...

    This issue could have national security ramifications. There's NO excuse for this being released into the wild.
    BitTwiddler
    • I beg to differ

      It would be security through obscurity. Do you think there are no organizations out there that can figure out this on their own? Who knows if this was already used? This exploit is highly derivative and reading Kaminsky's article on how he discovered it I'm amazed nobody else did before (engineers at CDN providers for example.)

      DNS is still quite insecure even with the random port mitigation. Moving to TCP would add a little bit more but still not perfect and it would be prone to man-in-the-middle attakcs. DNS needs some sort of authentication (IPSec AH, SSL connections, or DNSSec.)

      http://en.wikipedia.org/wiki/Security_through_obscurity

      In computer security, ignorance ISN'T bliss.

      Alecco
      alecco
      • On the ethics

        This has already been discussed a lot, and I'll say we'll get to no answers soon. I'd expect to see several panels on this at upcoming conferences.

        -Nate
        nmcfeters
      • Your correct Alecco

        Burying your head in the sand doesn't solve the problem. Dan Kaminsky sent his information to the developers so they can create a fix and they release a patch so you can install it to prevent this issue from affecting your system. However I thought that Dan Kaminsky and friends were supposed to wait a little longer to allow people to install the patch on their systems before releasing the exploit so who spilled the beans early is the issue and not necessarily Dan's problem. Who did it I don't know but they should allow a fair amount of time before releasing this information.
        Dan Kaminsky is a responsible security researcher who didn't exploit his find for evil gain but did the responsible thing by reporting it to the developers so they can create the fix for all to use.
        The bad guys are the one who will find the vulnerabilities and exploit on us for their gain before the developers find a patch to stop this problem and this the true problem.
        phatkat
  • RE: |)ruid and HD Moore release part 2 of DNS exploit

    Isn't the really scary part of this the fact that the "fix" only makes it takes 64,000 times as long to succeed.

    If the original attack can be mounted in "seconds" ...say 60 of them..randomization will make a successful attack take 44 days...to spoof citifinancial.com for example ...to all users of a major isp...might be worth the effort.
    (of course, ISP would need to be blind...lol)
    DonD01
  • RE: |)ruid and HD Moore release part 2 of DNS exploit

    thanks..
    hd-download