DNS cache poisoning attacks exploited in the wild

Summary: UPDATE: Arbor Networks have provided more details in their "30 Days of DNS Attack Activity" analysis, SANS confirmed HD Moore's statement on DNS cache poisoned AT&T DNS servers. Numerous independent sources are starting to see evidence of DNS cache poisoning attempts on their local networks, in what appears to be an attempt to take advantage of the "recent" DNS cache poisoning vulnerability :" client 143.

UPDATE: Arbor Networks have provided more details in their "30 Days of DNS Attack Activity" analysis, SANS confirmed HD Moore's statement on DNS cache poisoned AT&T DNS servers. Numerous independent sources are starting to see evidence of DNS cache poisoning attempts on their local networks, inDNS Cache Poisoning Test what appears to be an attempt to take advantage of the "recent" DNS cache poisoning vulnerability :

" client 143.215.143.11 query (cache) 'www.ebay.com/ANY/IN' denied: 31 Time(s) client 143.215.143.11 query (cache) 'www.facebook.com/ANY/IN' denied: 30 Time(s) client 143.215.143.11 query (cache) 'www.gmail.com/ANY/IN' denied: 30 Time(s) client 143.215.143.11 query (cache) 'www.google.com/ANY/IN' denied: 30 Time(s) client 143.215.143.11 query (cache) 'www.live.com/ANY/IN' denied: 30 Time(s) client 143.215.143.11 query (cache) 'www.microsoft.com/ANY/IN' denied: 30 Time(s) client 143.215.143.11 query (cache) 'www.msn.com/ANY/IN' denied: 30 Time(s) client 143.215.143.11 query (cache) 'www.myspace.com/ANY/IN' denied: 30 Time(s)"

Surprised? I'm not, since this was pretty logical given that the three publicly available exploits have been downloaded over 15,000 times in the last couple of days. What I'm actually surprised of is that it took so long to produce a working exploit, and the despite the media outbreak raising awareness on the potential for abuse, major international and local ISPs remain vulnerable. Ironically, remain vulnerable just like they've always been even though patches for a particular vulnerability were available. Insecure and misconfigured DNS servers were, and continue to be a realistic threat even in a Web 2.0 world.

Take for instance a survey of DNS security conducted back in 2004, showing that :

"We next examine which names depend on nameservers with known security flaws. Of the 166771 nameservers, 27141 have known vulnerabilities. These vulnerabilities affect 185802 names. A naive expectation might be that, with ~17% vulnerable nameservers, only 17% of the names would be affected. This is patently not the case; transitive trust relationships "poison" every path that passes through an insecure nameserver. Hence 34% of DNS names can be compromised by launching well-known, scripted attacks. "

Another DNS measurement study conducted back in 2005, showed that 84% of Internet name servers could be vulnerable to pharming attacks. Even if you're more conservative than you should be, you can easily consider that at least 50% of Internet name servers remain vulnerable three years later. Well, that seems to be the case according to last year's survey of DNS security, again conducted by Infoblox :

"Still more than 50% of Internet name servers allow recursive queries, which is consistent with 2006 results. Accepting recursive queries from arbitrary addresses allows servers to be used in DNS amplification attacks that can bring down major networks, and also leaves them vulnerable to cache poisoning attacks. The percentage of name servers that allowed us to transfer zones actually increased slightly, from 29% to 31%. While this change is probably within the survey’s margin of error, it does show that this aspect of security isn’t improving. A change in the default behavior of the BIND 9 name server (like the change to the default recursion setting introduced in BIND 9.4) might help here."

State of IP SpoofingMoreover, the MIT's IP Spoofer project originally running since 2005, continues to automatically generate graphs representing the state of DNS servers security across the globe, particularly their susceptibility to IP spoofing, the ABC of DNS security. Despite the hype over the recent vulnerability, DNS cache poisoning has been around for years, and it's not going away anytime soon.

Most importantly, malicious attackers don't need to take advantage of this flaw to successfully commit cybercrime like they do on a daily basis. What hasn't been taken care of for years, wouldn't be solved in a matter of days, that's for sure. Until then, take control of the situation, check whether or not your ISP is running DNS servers susceptible to cache poisoning, approach them in between sharing your evidence online, and consider going through the possible abuse scenarios malicious attackers can take advantage of using DNS cache poisoning.

Topic: Security

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

Talkback

54 comments
Log in or register to join the discussion
  • My W2k server and SuSE 10.2...

    server were easily patched through their respective automatic updates. The patching was so easy that anyone running a DNS server that hasn't patched already is an idiot.
    bjbrock
    • My 11.0 openSuSE automatically patched BIND last week

      nt
      D T Schmitz
      • Wrong place

        You're meant to put 'nt' in the title, so we know there's no text in the message. But, by putting 'nt' as the message, you have, in fact, contradicted yourself because there is now some text in the message.

        :)
        CreepinJesus
    • I guess if you're running an Apple server...

      http://www.theregister.co.uk/2008/07/29/apple_dns_patch_mia/

      Well I guess you're ...
      bjbrock
      • Even more dangerous if you are using an OS X client!

        [url=http://blogs.zdnet.com/security/?p=1576] OS X online update vulnerable to DNS cache poisoning [/url]

        [i]A security research outfit in Argentina has released a malcode distribution toolkit capable of launching man-in-the-middle attacks against popular products that use insecure update mechanisms.
        ...
        The first version of the toolkit ships with exploit modules for several widely deployed software, including [b]Apple?s Mac OS X and iTunes[/b], WinZip, Winamp, OpenOffice and Sun Java.[/i]

        In other words, if your ISP's DNS cache has been poisoned, "the bad guys" could redirect OS X's online update requests to their sites and they could push updates to your OS X computer without you ever being aware that these updates aren't coming from Apple. Even more worrisome is that these "updates" will run with full privileges on the system. Rootkit anyone? Apple's update mechanism is [b]flawed by design[/b]. I'd be [b]very[/b] wary of applying any updates to OS X or iTunes until Apple redesigns its update mechanism.

        Note that Windows and Linux update mechanisms are not vulnerable. :)
        NonZealot
        • Unless Apple Software Update uses hashes

          to verify packages, like MS does, in which case injected
          packages would be discarded.
          thorman@...
      • Nahhhh...

        If you're running OS X Server, you can go over to the BIND site and just compile the new version yourself. This just makes Apple look inept when it comes to supporting enterprise.
        Mach5RR
    • Why not patch?

      I have the bad feeling that these people have turned off updates because they are running antiques and/or ancient crap ware that was poorly written and won't work with anything new.

      Some of them and their clients are going to pay the price. I can even believe some IT guys just thinking this is easier which it will be until the planet lands on them.
      deowll
      • For the big servers, it's not about "updates"

        The concern for the public at large is the big recursive DNS servers. I doubt any of these has automatic updates, but some of the ISPs, etc. are dragging their feet. Corporations with their own DNS servers should be looking after themselves, but hey, it's their funeral.

        There are also patches for PCs which users should apply, but the big problem is at the ISP level and up. There are known issues with applying the patch behind a NAT which require some tinkering (e.g., NAT may de-randomize the randomized ports created by the patch), but these guys need to get on the ball.

        If your DNS server (provided by your ISP) is still showing up as vulnerable, I would suggest changing your config to point to OpenDNS or one of the other free and non-vulnerable DNS services. (These guys were already secure before Kaminsky's announcement.) It is really quite easy to do.
        seanferd
  • Is https still safe?

    I'm imagining that https connections are still safe. In other words, if I don't get a certificate warning while connecting to my bank through an https connection, I [b]am[/b] connecting to my bank's server, right?

    I'm imagining that the biggest danger with this is that "the bad guys" can redirect you to their sites and attempt drive by installs so any precaution that prevents drive by installs (Vista IE7 Protected Mode, Firefox with NoScript / AppArmor, [url=http://blogs.zdnet.com/security/?p=1579]use anything but Safari[/url]) will protect the end user from the effects of their ISP's poisoned DNS cache.

    Are there any other dangers that we can look out for?
    NonZealot
    • If the "bad guys" produce a certificate...

      generated by a company with a CA in your root store your browser may think it is OK when it's not.
      bjbrock
      • Explain!!

        Just how could they do that, without the CA's private key?
        techboy_z
        • Here's a couple of ways...

          One way would be to sweet-talk Verisign into giving you Microsoft's name on your cert, like this guy did...
          http://www.cert.org/advisories/CA-2001-04.html

          Another possibility would be to create a legitimate looking company with a real certificate for it, then repurpose it for scamming later on. Unlikely, but certainly possible.
          bmerc
          • @JCitizen below and bmerc

            Keep in mind while reading my response that I'm specifically talking about the following scenario:
            1. User enters a URL into their browser address bar or picks one from their list of bookmarks.
            2. DNS cache poisoning causes the request to be sent to a "bad guy's" site.

            [i]One way would be to sweet-talk Verisign into giving you Microsoft's name on your cert[/i]

            From what I understand of this issue, it is only partially relevant to the issue I described above. The certificate could not be used to spoof a valid https://www.microsoft.com certificate, it simply states that the certificate was issued to Microsoft. If we continue the script above,
            3. Browser warns that the certificate does not match the URL.

            Just because the name on the certificate is "Microsoft" does not mean that it can be used as a valid certificate for https://www.microsoft.com in [b]exactly[/b] the same way that an https://www.tdcanadatrust.com certificate will throw a warning if you typed in https://www.tdcanadatrust.ca (both take you to the same site). It only means that if you examined the certificate, you would believe that the signed code/document actually came from Microsoft but you would still get the warning that it wasn't valid for the URL you navigated to. I'm not minimizing the danger of the issue that you linked to but I don't believe it could be used in conjunction with the DNS cache poisoning to allow a "bad guy" to redirect you without raising a certificate warning. It is dangerous in other scenarios, just not this one.

            [i]Another possibility would be to create a legitimate looking company with a real certificate for it, then repurpose it for scamming later on.[/i]

            This has been covered below and has nothing to do with DNS cache poisoning. It relies on much more traditional forms of phishing (email a link that appears to go to https://mybank.com but instead goes to https://mybanc.com) that are easily circumvented by navigating to your bank by either typing in the URL manually or picking it from your bookmarks.
            NonZealot
          • I suspected that Kaminsky's discussion ....

            may not be related to my scenario; but I was on a recognizable address(URL) and had already entered a verifiable HTTPS session with a site that was obtained by bookmark or Google search, and I don't remember which.

            When I arrived at the site, which I trusted, I logged in and was managing my account when I received a very recognizable Microsoft warning about certificate expiration as I switched to the next page of my usual account information..

            Now this was very unusual and of course I was very cautious, but I was already logged in and since the URL information still looked correct, I blew through the warning to see if the next page was correct, and it was!

            So either this system is not reliable, or I am going crazy; take your pick, but after listening to the mp3 download on the BlackHat site; I had to wonder about the entire system; DNS included! I also don't know if the session was SSL or SSH but I will check the information much more carefully next time and make note of it!

            (edited) please also bear in mind I had not altered any information on these pages, so it would have taken a very crafty cracker to issue an SSL page that had the proper information on it. Only I would have known that, and although I am paranoid enough, I am sure the information was not previously stolen from me. It may be now, but not at that moment!

            I go to great lenghts to lock my system down, so I am really vexed about how this would come about!
            JCitizen
        • If the CA is in your root store....

          Your browser will trust certificates issued by that CA.
          bjbrock
          • Yes, but is it relevant?

            [i]Your browser will trust certificates issued by that CA.[/i]

            A certificate is tied to an address so trusting a certificate isn't what gives you the thumbs up by your browser, it is the combination of a trusted certificate matching the site you are browsing. Even if the bad guys can get a certificate that I trust, they can't get one that is linked to my bank's domain. I navigate to https://mybank.com, DNS poisoning redirects me to a bad guy's site and they use root CA granted certificate linked to mybanc.com, I will get a warning that the certificate does not match the site. At least that is my understanding.

            As a test, go to http://www.tdcanadatrust.ca. It is a valid site, as is http://www.tdcanadatrust.com (both belong to same bank). Now go to https://www.tdcanadatrust.ca and you will get a certificate warning because the certificate you are getting is only valid for https://www.tdcanadatrust.com.
            [i]www.tdcanadatrust.ca uses an invalid security certificate.

            The certificate is only valid for www.tdcanadatrust.com[/i]

            My browser fully trusts the certificate that https://www.tdcanadatrust.ca is giving me, but it doesn't match the URL so I get the warning. Since the "bad guys" can't host a certificate that will match https://www.tdcanadatrust.com, they can't use DNS cache poisoning to trick https connections. At least that is my theory but I wanted much more knowledgeable people to confirm or deny.
            NonZealot
          • A certificate is tied to a URL.

            Not an address. And if you think they can't spoof certificates you need to think again. If that certificate is issued with your banks name as the site, or even if they change one character and you aren't double checking the url in your browser address bar you are screwed.

            You are so wrong in your assumptions.
            bjbrock
          • Point by point

            [i]A certificate is tied to a URL. Not an address.[/i]

            Thanks for the clarification but yes, that is what I meant.

            [i]And if you think they can't spoof certificates you need to think again.[/i]

            Fair enough. I haven't heard of rampant problems with spoofed certificates. Can you point me to any articles that talk about how easy this is?

            [i]if they change one character and you aren't double checking the url in your browser address bar you are screwed.[/i]

            Agree 100% but then again, that has nothing to do with DNS cache poisoning which is the context of this discussion. What you are talking about is very standard phishing techniques that are neutered by [b]not[/b] clicking on links in emails that pretend to take you to your bank but actually take you elsewhere. Type the URL in yourself or choose it from your bookmarks collection and you avoid standard phishing attack vectors.

            [i]You are so wrong in your assumptions.[/i]

            I'm not trying to convince anyone of anything. If I'm wrong, I'd like to know I'm wrong! You brought up a good point with spoofed certificates and I thank you for that because I didn't think that was really possible.
            NonZealot
          • How do you think people get fooled by phishing?

            Exactly the way you are saying can't be done.
            bjbrock