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, in 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."
Moreover, 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.
Kick off your day with ZDNet's daily email newsletter. It's the freshest tech news and opinion, served hot. Get it.
Talkback
My W2k server and SuSE 10.2...
My 11.0 openSuSE automatically patched BIND last week
Wrong place
:)
I guess if you're running an Apple server...
Well I guess you're ...
Even more dangerous if you are using an OS X client!
[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. :)
Unless Apple Software Update uses hashes
packages would be discarded.
Nahhhh...
Why not patch?
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.
For the big servers, it's not about "updates"
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.
Is https still safe?
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?
If the "bad guys" produce a certificate...
Explain!!
Here's a couple of ways...
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.
@JCitizen below and bmerc
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.
I suspected that Kaminsky's discussion ....
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!
If the CA is in your root store....
Yes, but is it relevant?
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.
A certificate is tied to a URL.
You are so wrong in your assumptions.
Point by point
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.
How do you think people get fooled by phishing?