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."

13 of 314 comments (clear)

  1. IRC by Wizy · · Score: 4, Informative

    Anyone who has been on irc for over 8 years remembers when DNS cache poisoning first started showing up (about 97.)

    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 /dline ipmask :reason."

    It has been a well known problem since way back then and it has still not be dealt with in any real way.

  2. Re:If this is such a big deal... by Wizy · · Score: 5, Informative

    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

  3. Re:How does this work? by Tony+Hoyle · · Score: 4, Informative

    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.

  4. Re:windowsupdate.microsoft.com? by Anonymous Coward · · Score: 5, Informative

    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.

  5. Re:windowsupdate.microsoft.com? by Dejohn · · Score: 4, Informative

    I believe that all Windows Update patches are digitally signed, so this spoof might be harder to pull of than it would initially seem

  6. Re:How does it happen? by Anonymous Coward · · Score: 5, Informative
    There are a few ways. Off the top of my noggin:
    • If your target DNS server is running Microsofts DNS server, on W2K SP 1 or 2 (this may have been patched, I dunno), you can poison DNS using an alias. It's simple. You have to have control of a zone (say realzone.com) and a DNS server. You create a zone on your dns server under the name you want to poison, say example.com. Your DNS server thinks it is authoritative for the example.com zone. Next you create a host record in example.com that points to a host you control. In your real zone (realzone.com), you create a CNAME record for a host like spoof that points to hostname at example.com, like www.example.com. Then you point your local stub resolver at the target DNS server (most DNS servers will resolve for anyone by default). When you try to lookup spoof.realzone.com, the target DNS server will find your dns server. Your dns server will see that spoof.realzone.com is a CNAME for www.example.com and look that up. Since it thinks it is authoritative for example.com, it will ask itself, and returh that IP address to the target DNS server. Now it is in the targets DNS cache. Anyone who tried to resolve www.example.com from that DNS server will get the IP address of the host you defined in the example.com zone. Spoof!.
    • Another way is to sniff the traffic of the target DNS server and when it tries to resolve a host name, feed it the result of your choosing before the recursive query finishes. The first response wins, generally.


    There are probably other ways, but it isn't hard.

    The bottom line, DNS is an untrustworthy system.
  7. Re:simple by fimbulvetr · · Score: 4, Informative

    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...

  8. Re:Question by OnceWas · · Score: 4, Informative

    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.
  9. No by temojen · · Score: 4, Informative

    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.

  10. Re:How to stop DNS cache poisoning by menscher · · Score: 4, Informative
    If all DNS records had 0 lifetime, the load on the core DNS servers would cause them to melt. Nice if you want a DDoS, not so nice if you want the internet to work.

    Ever heard of a monoculture? It's dangerous. That's the primary reason Microsoft has so many security issues. To guard against this, the DNS infrastructure of the internet is intentionally made to be heterogeneous. They use different DNS software on different operating systems as much as possible.

    Top security consultant? Doubtful. More likely an AC trying (and failing) to impersonate someone with a clue.

  11. Re:Funny How Easy this is to prevent by McSpew · · Score: 4, Informative

    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:

    DNS cache pollution protection is enabled by default in Windows 2000 SP3 and later.

    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.

  12. Re:SANS vs. the rest of the security community. by httptech · · Score: 4, Informative
    I wrote this article about the source and motivations of the attack (also mentioned by the Washington Post blog), so SANS is not the only security organization talking about it. But there's a reason you're not hearing alarm bells all over.

    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/

  13. Re:How does this work? by Stuwee · · Score: 5, Informative
    From memory, classic DNS poisoning goes something like the following:
    1. Pick any DNS server which isn't authoritative for the domain which you wish to poison with the IP of your choosing. Something like your ISP's DNS server will work nicely.
    2. Send a legitimate DNS request to the server for a domain which is authoritative under a server you are in control of, and which your choosen server (and any in-between it and your own server) won't already have in its cache.
    3. When the request for the domain comes into your server, you have the sequence number which originated from your target DNS server. The idea with this sequence number is that your reply to the originating server contains the number, and hence the server knows which request is being replied to. Here is where the vulnerability comes in.
      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).
    4. Next up, make a request to your target server for the domain which you want to take control of. For this to work, your target DNS server must send out a further request for this domain. Since you have an idea of the sequence number which has been sent out with this request, you can now start flooding the target DNS server with false replies.
    5. The ultimate goal is that you will hit the correct sequence number with your false reply before the legitimate reply comes in, hence poisoning the DNS. Further requests to your target server within the record timeout (which you may specify yourself in your false replies, so they can last quite a while) will be replied to with a cached version containing your poisoned IP.
    6. Watch the requests come in for the content to your own IP, serve up appropriately.