Slashdot Mirror

← Back to Stories (view on slashdot.org)

Attack Code Published For DNS Vulnerability

Posted by samzenpus on from the protect-ya-neck dept.

get_Rootin writes "That didn't take long. ZDNet is reporting that HD Moore has released exploit code for Dan Kaminsky's DNS cache poisioning vulnerability into the point-and-click Metasploit attack tool. From the article: 'This exploit caches a single malicious host entry into the target nameserver. By causing the target nameserver to query for random hostnames at the target domain, the attacker can spoof a response to the target server including an answer for the query, an authority server record, and an additional record for that server, causing target nameserver to insert the additional record into the cache.' Here's our previous Slashdot coverage."

14 of 205 comments (clear)

  1. Here we go... by LostCluster · · Score: 4, Interesting

    This has to be the worst time ever to be a web surfer. How long until we see the major networks broadcasting the legit IP quads of sites we want to reach?

    1. Re:Here we go... by Martin+Blank · · Score: 5, Interesting

      You may still not be safe. If someone can fire off a XSS attack through your browser, it could do enough lookups to make you vulnerable. Combine this with a periodic other run to a controlled server to grab your source port for guessing (presuming that you have not patched), and you may have a problem.

      Granted, it's unlikely that you would explicitly be targeted, and things like NoScript help defend against it, but there are still possible gaps. In fact, there are several tens of million of systems which will remain vulnerable for some time to come; I haven't seen many SOHO router firmware fixes released so far, and a lot of people point to their routers for their DNS.

      --
      You can never go home again... but I guess you can shop there.
    2. Re:Here we go... by harlows_monkeys · · Score: 1, Interesting

      There's nothing new about this

      You are massively wrong. There has never been a DNS attack anywhere remotely as dangerous and effective as this one.

      It is people making boneheaded statements like yours that make people think it is no big deal and they can put off patching.

    3. Re:Here we go... by Vectronic · · Score: 4, Interesting

      lol... you should try it, then you wouldnt think so... I just did (in Sound Forge)... cut it down to 1:08, its just noise... cutting it down to 50% is alright though (4:35)... but somewhere around 65% (5:57) is about right, sounds kinda "proper".

    4. Re:Here we go... by Lincolnshire+Poacher · · Score: 2, Interesting

      You made me laugh, but as with all humour there is a grain of truth within.

      Curiously I spent some time yesterday attempting to estimate the number of zones currently known to DNS. Perhaps there is a better approach ( one that, say, inquires against DNS ) but by using Teh Googler to search for site:.${TLD} I came up with these order-of-magnitude results:

      • .com 7,980,000,000
      • .org 1,950,000,000
      • .net 2,140,000,000
      • .info 195,000,000

      These numbers just seem insane. Can anyone advise?

  2. Re:And the "fix" isn't by cortana · · Score: 3, Interesting

    The fix is DNSSEC.

  3. Use djbdns! by Neanderthal+Ninny · · Score: 2, Interesting

    Even though it is not as popular as BIND but djbdns doesn't have this vulnerability. Remember Dan J Bernstein had the original idea in 2002 about this issue and Dan Kaminsky and Paul Vixie looked into this and found these vulnerabilities.

    1. Re:Use djbdns! by PlusFiveTroll · · Score: 2, Interesting

      6 root root 4096 2002-10-11 11:10 dnscache

      That list my oldest still running djb dnscache install, yes the kernel and glibc have been upgraded around it. The mail server it's on has handled 750k messages per day. Does rdns lookup on smtp connections from servers, from our tests almost every valid smtp mail source has a reverse dns name of some sort. Spambots virus are the largest amount of mail from unnamed IPs.

      This being said, if your running out of file descriptors you probably have one of the following issue.
      -Linux kernel 2.4, Solaris or AIX. (recent bind beta fixes most of this)
      -Messed up ulimit settings.
      -Poorly engineered dns caching network.

      Trying to run all your clients on a few 'big/fast' caching servers in general is a poor design that uses more bandwidth (to contact the centrally located dns server) and puts the entire userbase at risk if one of the caches does become poisoned. The cable company I worked with realized this years ago and distributed the dns load to each market with at least two dns servers in each city, then more per 'area' as the customer base grew. The boxes were diskless with an extremely stripped linux/glibc installs with dnscache, SSH, and SNMP support. No hard disks let these servers run more like an appliance, they were easily switched out, and rarely suffered failures. Just put the new numbers for the node in the dhcp server and over the period of a day or so as the dhcp clients renewed the load balanced out.

      As per D.J.s security suggestions, only ip addresses that belonged to their networks could resolve off the cache. This is significant as many large ISP currently allow anyone to resolve DNS off their networks. Which in the current security context no trickery or fishing is necessary to poison an ISPs cache. A hacker anywhere in the world could poison the cache at their leisure.

      They used Bind on there authoritative nameservers, since it fit in with their toolchain, but they turned off the forwarding mode so queries outside of the servers scope would not be resolved.

      It's been awhile since I worked there, but I'm sure someone from the network security department after reading the news, called a meeting on how they were going to deal with this issue. I'm sure he may have been surprised when the answer was 'We fixed that 5 years ago'. It's funny, a lot of people wrote off D. J. Bernstein, not because of what he said, but how he said it. Time has now shown he was right, and even Paul Vixie admitted that he was wrong.

  4. Re:And the "fix" isn't by _Knots · · Score: 4, Interesting

    DNSSEC is a steaming pile, though after thirteen years, many RFCs -- each of which read "This Time For Sure!" -- it may in fact be workable.

    It is _a_ fix to this problem, but there are many simpler fixes that seemingly are being discarded for reasons I don't quite understand -- perhaps more full threat models are the target problem, but securing DNS doesn't make sense if we're then going to use HTTP to the addresses resolved! On the flip side, if we were using TLS everywhere, then dicking with DNS amounts to a DoS, which is much less powerful than the arbitrary redirection attacks we have now.

    One such simpler fix is using EDNS0 to add a nonce RR (goes out in the Query, comes back in the Additional section). And while EDNS0 is subject to rollback attacks, DNSSEC depends on EDNS0. So that's not an excuse not to use it.

    --
    Anarchy$ dd if=/dev/random of=~/.signature bs=120 count=1
  5. BIND 9 named views for access control by DragonHawk · · Score: 3, Interesting

    Once someone (anyone?) releases a DNS package that allows firewall-style rules (e.g. "client on this range of IPs may only resolve subdomains of the following domains..."

    I think you might be able to do that with the "views" feature of ISC BIND v9 named, although I've never tried. I know you can define ACLs for clients and control how they see the DNS using the ACL. You should be able to define forwarding zones for the domains you want to work, and blackhole everything else. I think.

    http://www.isc.org/sw/bind/arm93/Bv9ARM.ch06.html#view_statement_grammar

    --

    dragonhawk@iname.microsoft.com
    I do not like Microsoft. Remove them from my email address.
  6. help all the SOHO router people by paulbd · · Score: 2, Interesting

    so, there are a lot of us in the following position, no doubt: we run a router (linksys, whatever) that gets DNS from our ISP. lets assume that the ISP is patched. our local machines use the router for DNS. do we need to patch the router? are its DNS request services even accessible to the external network? can it be compromised in the same way that the ISP DNS could be? i have been wondering this ever since news of this problem broke, and i have still not seen a clear answer.

  7. Re:See if you're vulnerable by afidel · · Score: 2, Interesting

    Yeah, they're probably behind a firewall with PAT since Verizon was one of the ISP's involved in the private patch effort AFAIK. The problem is the DNS client/server patches are broken most firewalls and this was not known till people started testing after the patches were publicly released. You can use OpenDNS or L3's resolvers as I know those are patched and NOT behind a PAT firewall and are publicly available.

    --
    There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
  8. Re:The Book Of Internets, Chapter Three, Verse Twe by rs79 · · Score: 2, Interesting

    If you want to support verisign forever, go with dnssec.

    --
    Need Mercedes parts ?
  9. Re:DNSSEC today by slash.duncan · · Score: 2, Interesting

    What you've apparently missed (as you mentioned .org but not this) is that the .org folks (PIR) just got ICANN board approval to deploy DNSSEC at their gTLD level. This occurred at the 32nd Annual ICANN meeting in Paris (in June, I believe). Apparently PIR has been pushing DNSSEC for some time and is pretty much ready to go, altho it'll still take some time to actually get up and running.

    Here's one informative link I found on Google. Google for dnssec .org icann for more:

    http://blog.nominet.org.uk/insight/2008/06/icann-paris-dnssec/

    --
    Duncan
    "Every nonfree program has a lord, a master,
    and if you use the program, he is your master."
    R Stallman