Slashdot Mirror
DNS Cache Poisoning Spreads Malware
Gamma_UCF writes "As of April 4, 2005 the SANS Internet Storm Center has raised their alert level to Yellow following a rash of active DNS poisonings. The infected DNS servers are re-directing users from popular sites such as Google or American Express to malware infecting advertising sites. According to the ISC presentation on the attack, it is believed to be linked to known spammers and malware distributors. The full presentation of information up until this point can be found here."
Anyone who has been on irc for over 8 years remembers when DNS cache poisoning first started showing up (about 97.)
/dline ipmask :reason."
This is a quote from the "IRC Operators Guide" written in 8/97:
"DNS spoofing is a relatively new hit these days on IRC. You'll generally find spoofs one of two ways - you're watching the connections (usermode +c) and an unusual hostmask appears, or a user reports one. The first thing to do is to get the user's IP address (/stats L nick), and check to see if the DNS lookup matches the IP address. If it doesn't, you know you have a spoof. With this information, you can KILL the spoof, and when it reconnects, see where the real host is and issue a K-line (which won't stop them from spoofing again, but will prevent them from signing on *without* spoofing). Some servers have the capability of D-lines, which allow you to ban by ip mask. A D-line will prevent the client from connecting at all, regardless of whether they try DNS spoofing or not. If the server supports the DLINE command, you can do
It has been a well known problem since way back then and it has still not be dealt with in any real way.
It's the malware on the sites that the infected DNS servers redirect to.
--Mike Boos
We have. This has been a known problem since early 1997. It is well documented in the IRC community (admins and coders.)
Documents like this one from 1997: http://www.cs.rpi.edu/~kennyz/doc/unix/dns.spoof
It's where you have an insecure server and someone manages to modify your zone file externally. It really shouldn't be possible any more... all dns servers ship secure by default, and any admin that makes such a configuration change should be fired on the spot.
As a rather well known expert in the field of cybersecurity, I offer the following solutions (sans my standard $450/hr rate) -
Turn the lifetime of all DNS records to 0. This way they will not be cached, hence no poisoning issues
Upgrade everyone to BIND 9.0 - including Windows - and turn on crypto. This will add security so malicious users can connect and poison the DNS cyber buffer!
Implementing these 2 will solve 90% of problems. Free advice from a top security consultant at Foundstone. (you'd know my name)
usually its done by flooding a dns server with carefully crafted false replys based on known previous requests from the server.
or by taking advantage of servers that listen to extra information that they really shouldn't listen to in a reply.
with both methods the aim is to trick the dns server into cacheing your false response for its clients.
Has anybody tried to redirect windowsupdate.microsoft.com? That could potentially install malware at massive privilege levels and therefore impossible to remove. And it's done automatically.
Automatic updates that are not signed and verified will not install.
And besides, there are plenty of cross-platform attack you could do with this.
Want a copy of a user's eBay cookie? (Ok maybe eBay doesn't save passwords this way but you get the point, lots of sites do. It's like phishing, but the computer believes it's genuine, not just the user).
# cat
Damn, my RAM is full of llamas.
I believe that all Windows Update patches are digitally signed, so this spoof might be harder to pull of than it would initially seem
Well, yes, but I meant the malware on the sites redirected to. Obvoiusly, you can't avoid the DNS cache poisoning, so this would be annoyingly effective for phishing.
There's an old saying that says pretty much whatever you want it to.
they are. Hopefully someone will take the GP down a notch or 2 from "5-insightful" and up your retort a few notches from "1"
Its not just windowsupdate.microsoft.com that is prived - it's a little more sophisticated than that.
I'm not even a MS apologist...haven't used a MS product in many years (except when I'm forced to for work-related reasons)
There are probably other ways, but it isn't hard.
The bottom line, DNS is an untrustworthy system.
The separation between DNS Server and DNS Cache is very clever. This is a point that even BIND must take care.
This is a DNS server issue, not a client issue.
Suppose you visit citibank.com often. citibank.com is at 192.168.0.1 (It's an example). If the dns server you normally query has been poisened, it could potentially give you 10.0.0.1 (that's an example too). 10.0.0.1 could be a quick 0 day citibank look alike setup in korea with the sole purpose of grabbing your username,password,acct number, etc.
The real citibank.com would never know that this happened, and there is a real chance the person who ran your dns server wouldn't know either.
There are no 10 minute preventative measures one could do to protect themselves on this one, outside of using a known good dns resolver. Even then, you have to know the the dns server the resolver uses is good...
Opera (or Firefox) isn't immune to phishing attacks. How would you know you're giving your banking info to a phony site that looks exactly like your own bank's login screen? Especially if the domain name is correct?
I assume SSL would catch some of this, but not all.
DNS poisoning is creepy, since it's browser/OS agnostic.
Laugh while you can, monkey-boy.
The "no" part is that virtually nobody does this. All the protection in the world is useless if you don't use it. Further, the protections that do exist (such as those I mentioned) get redesigned a little too often, making wide-scale rollouts a real problem.
Routers are another key part of the infrastructure where there is plenty in place that COULD prevent poisoning, but where actual use in the "Real World" is limited. If DNS ever does improve, then scammers may well simply shift to poisoning router tables to achieve the same results.
The resources spent on producing quality and security are phenominal. The resources spent on actually putting these into practice can barely be detected with the best tunneling electron microscopes.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
Start by clicking the "HERE" in the article and, oh, wow, there's a whole report on how it happens!
- AMW
The article is about DNS Cache poisoning, not DNS spoofing. In DNS cache poisoning you're effectively telling the victim's DNS server to query your (fake) server for all of a class of requests (ie *.com), instead of the one it should be querying. DNS spoofing only tries to fool reverse lookups.
DJB has talked about it at least as far back as November 2001.
libresolv problems,talking about poissoning
Je ne parle pas francais.
Damn, if only I had checked the "turn on security" box!!
From MSFT (http://support.microsoft.com/kb/241352/EN-US/)
How very wrong you are.
Win2k DNS automatically turns on "secure cache against pollution" in SP3+. Read about it at http://support.microsoft.com/kb/316786/EN-US/. Specifically, you're looking for this quote:
Win2k DNS servers with this feature turned on are STILL vulnerable. I know because my DNS servers are configured this way and I began to suffer from the DNS poisoning on Thursday of last week. It took me until Friday to get a real handle on what was happening. Slashdot ignored my submission of this story back then. They were too busy jerking around with April Fool's stories.
Wrote about this today in his blog:
http://blogs.washingtonpost.com/securityfix/
He provides some background and comments from companies effected by the attacks. And he offers some opposing views from SANS and Symantec Corp. on whether this is a serious concern or not.
Yes, djbdns is immune to cache poisoning (and pretty much any other attack that doesn't depend on any fundamental weakness of DNS itself).
It is also immune to buffer overflows and runs as a non-root user locked in a chroot. It also is EXTREMELY lightweight, has a much easier/automatable config format than BIND (in fact we wrote a front-end for BIND that uses the tinydns line-oriented format), and has predictable documented memory usage.
It has been this way for years.
Anybody who uses BIND or Windows DNS has only themselves to blame for problems like this!
Feel free to be smug.
Basically it comes down to this - the attack was used to hijack searches for pay-per-click engines. It was done in the most obvious way and got a lot of attention. If they had been smarter, they would only have redirected defunct sites instead of cnn.com and the rest of the .com TLD.
Now that the cat is out of the bag, people are watching for the traffic, so a second, more malicious attack probably won't see nearly as much success. So there's no reason to panic - it's a 4-year-old vulnerability as it is, and fixed by a simple registry edit. Most people will be unaffected by it.
-Joe
Joe Stewart, GCIH
Senior Security Researcher
LURHQ http://www.lurhq.com/
Are there really people who read at +something? About the first thing I did when I arrived here was starting to read at -1. It was pretty obvious that the funniest shit happens there.
Quoting the article:
That might be news to the people who run imdb.com - it's the internet MOVIE database, not MUSIC database :).
Actually, BIND 9 is a complete rewrite of BIND and does not have the security issues that BIND 8 and 4 have. Basically, recent versions of BIND 8 and BIND 9 do create random DNS query IDs, which makes this kind of attack far more difficult (it would have been nice if DNS was designed with variable length query IDs back in 1983, but the Internet was a different place back then).
I really wish DJB advocates would realize that BIND 9 is not BIND 8 and below.
To DJB's credit, he has written The best article on DNS cache poisoning I have seen.
When I directed my friends to locate Spybot Search And Destroy via Google, they got redirected to a software site that claimed to be Spybot Search and Destroy - but the software would not CLEAN infected systems unless you paid. What you end up installing, of course, just installs MORE spyware.
So when you point freinds to Spybot Search and Destroy, you've got to give them the actual download link.
These are my friends, See how they glisten. See this one shine, how he smiles in the light.
You moron, this affects all browsers regardless.
Were talking about DOMAIN NAME SERVERS, the ones that resolve IP addresses and tell your browser where to go.
This has been a big problem lately, so much so that my ISP decided they had to lie to me about it two months ago when I pressed them on this issue.
First, contrary to what some people think, to access a site with HTTPS which has a certificate, you do NOT contact the CA over the internet. This is because your browser already has the public key of that CA installed. The signature of the certificate you are shown by the real or fake site is verified/rejected not by looking something else up on the internet, but by performing cryptographic tests against that installed public key of the CA. This is not only an efficient process, it is much more secure (for the spoofing reasons you suggest).
That's if you're talking about SSL stuff. If you are talking about the digital signature of the file(s) from windows update, you're using a very similar approach. I don't know the details of Windows Update, but I'll bet there is a local public key or set of keys from MS that are used to check the signature...nothing to download or look up over the internet.
If I explained that rather poorly, I apologize. I just wanted to express that, contrary to what most people think, you do NOT use connections to the CA to verify a certificate.
If you become a victom of a DNS poisoning attack or if you want to avoid that in the first place, you can use a DNS server other than that of your ISP. For example, below are the names of Microsoft DNS servers (that can be expected to work reliably and be relatively safe):
DNS1.CP.MSFT.NET 207.46.138.20
DNS2.CP.MSFT.NET 207.46.138.21
DNS3.CP.MSFT.NET 207.46.138.126
DNS4.CP.MSFT.NET 207.46.245.230
DNS5.CP.MSFT.NET 64.4.25.30
DNS7.CP.MSFT.NET 207.46.138.14
The IP-addresses may change when Microsoft changes their DNS Architecture.
Future Wiki -- If you don't think about the future, you cannot have one.
Earlier versions of BIND use sequential sequence numbers in each request; nowadays pseudo-random numbers are used. What we're really after here is the next sequence number, or at least an idea of what it might be. In the case of sequential numbers, you have a rather small range of next sequence numbers. If your pseudo-RNG isn't cryptographically secure, it's possible to guess the next number in the sequence (for which you might want to make a few legitimate requests to your target server to observe the sequence).
That seems fairly reasonable. I don't think you're really protected from poisoning, unless "poisoning" only applies to certain kinds of DNS spoofing. Specifically, first note the exceptions to the djbdns security guarantee:
Specifically, his forgery page points out that a spoofing attack based on the birthday paradox can still work... although probably tens of millions of packets are required. This page, which I think I got off slashdot before, uses the TCP sequence-number guessing tools to try to attack it. It's probably not quite as secure as djb estimates, but probably still in the millions. They don't seem to have actually run numbers for the randomized-port plus randomized-id, so it's unclear whether they actually attacked that thoroughly.
So there's no reason to panic - it's a 4-year-old vulnerability as it is, and fixed by a simple registry edit. Most people will be unaffected by it.
Ah, but here's the rub: It's not fixed by a simple registry edit. Win2k SP3 and SP4 are "secure" by default. I'm running Win2k SP3 and SP4, and I was bitten by this. The MS articles I initially found about cache poisoning didn't mention that SP3 and SP4 are secured by default, so I went and inserted the registry setting and restarted my DNS servers. The next day, the poisoning was back. That was when I discovered that SP3 and SP4 are secured by default, and that was when I realized that this problem is more serious than most people realize.
I tried to publicize what I'd learned on Friday. I submitted the story to Slashdot, where it was rejected because it wasn't an April Fool's prank. I submitted it to Russ Cooper's NTBugTraq, where it disappeared into the ether. Imagine my consternation when Russ Cooper was quoted in today's Washington Post security blog saying that nobody was seeing it. I wrote to Russ immediately after seeing that quote and assured him that I was seeing it and I had posted to his list, but the post had not been approved by him.
I'm pissed off because very few people are taking this seriously and well-meaning people such as yourself are dismissing it as a minor vulnerability that's easily remedied with a registry edit. This attack is not remedied by inserting a registry entry and restarting the server--it affects servers that are supposed to be immune.
You probably would have been better off sending your findings to handlers@sans.org - you're the first person I've heard say that the fix doesn't work, and since SANS hasn't updated the information, I presume they haven't heard about it yet either.
.com label in the Authority section is technically a subdomain of any .com domain they may be querying, the SecureResponses key doesn't reject it. This would be a fairly big deal (not too big, you realize, since most of the world doesn't use MS DNS servers) that would require some independent testing in order to convince MS to change their stance (and fix the problem for real).
Despite the fact that your experience contradicts MS and CERT-CC, I'm willing to accept the possibility that because the
Any chance you captured some of the traffic as it was occuring on your would-be immune servers? Because the poisoning attack from abx4.com is over now, so it will take a bit of work to recreate it in the lab without those servers to conveniently supply the test packets.