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

10 of 314 comments (clear)

  1. internet rash by Cruithne · · Score: 5, Funny

    following a rash of active DNS poisonings

    Damn internet rashes, they're the worst. Remember, dont surf without protecting your board. :/

  2. More color-coded warnings? by loqi · · Score: 5, Funny

    I give it two years until the sight of a rainbow fills me with abject terror and confusion.

    --
    If other reasons we do lack, we swear no one will die when we attack
  3. Let's Kill The Golden Goose by ackthpt · · Score: 5, Insightful
    Sure, internet click-thrus generate money, but when they get so invasive and destructive, they'll drive people way from the internet. I can't imagine any advertiser likes that idea.

    Worse, perhaps, is that all these problems may encourage some horrible proprietary internet standards to arise, claiming safety from ad/spy/malware, phishing, etc. and all the cattle have to do is sign up, abandoning the old internet.

    --

    A feeling of having made the same mistake before: Deja Foobar
  4. 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

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

  6. Djbdns - immune to DNS cache poisoning (?) by bad_outlook · · Score: 5, Insightful
    Anyone using Djdns? I've set it up on my home network server running FreeBSD to provide dnscache for all my boxes within 192* and thus far it's working perfectly. From Djdns' security page, it says that it's impervious to DNS poisoning:

    • "dnscache does not cache (or pass along) records outside the server's bailiwick; those records could be poisoned. Records for foo.dom, for example, are accepted only from the root servers, the dom servers, and the foo.dom servers."

      "dnscache is immune to cache poisoning."

    Djbdns

    While I don't think I'm in the clear because of this, I feel better protected from the (unwashed ;)) internet. Anyone care to comment, please do, as I've just started using this and want to know how effective it is.

    bo

  7. The most frightening part... by loopsandsounds · · Score: 5, Insightful

    If you read down the SANS presentation you come to this:

    The following list shows how far-reaching this attack proved to be. The list is a small, categorized excerpt of the 665 domain names from his site (with my short notes) that were being re-directed to hostile web servers. It is very important to note that e-mail, FTP logins, HTTPS sessions, and other types of traffic were also being re-directed to the malicious servers. We do not believe that the attacker was reading e-mail or collecting passwords, but we have no conclusive proof to assert either theory.

    Totally browser/machine agnostic attacks, no user intervention. If you look at the names of the sites, many of them are financial institutions! And all of those victims that click okay everytime they get an "invalid certificate" message. Be afraid, very afraid.

    --
    I was throwing you the 48, but you made me switch to the 132.
  8. 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.
  9. SANS vs. the rest of the security community. by tsu+doh+nimh · · Score: 5, Interesting
    Washingtonpost.com is running an interesting story about how SANS is really the only major player in the security community that is making any noise about this.

    ...(snip..)

    ...."But here's the rub: Symantec Corp., which maintains tens of thousands of "sensors" at various points around the Internet to pick up signs of Internet attacks, said it isn't seeing anything out of the ordinary with DNS attacks.

    Dave Kennedy, director of research services at Herndon, Va.-based Cybertrust (formerly TruSecure), had this to say about the reports: "It's been nearly a month since SANS started ringing their alarm bells over this and maybe I'm not looking in the right places, but I'm grading this as hype until I see some independent support."

    Russ Cooper, Cybertrust's chief technologist, put it this way: "In my opinion, our industry's creditiblity comes from further reports from multiple sources. We run a very large operation worldwide, and we've looked for signs of what SANS is talking about, but we're just not seeing it."

    All of this may seem like an academic debate to those who claim to have been victimized by these attacks.

    On March 24, Ken Goods, a computer network administrator for a mid-sized insurance company in Idaho, learned that the company's DNS servers had been attacked when employees began reporting that their Internet browsers were being redirected to a Web site hawking generic Viagra and other prescription drugs.

    "I kept trying to go to Google to research the problem, but even though my Web browser said I was at Google.com, the only content that showed up was this pharmacy site," said Goods, who asked that his employer not be named because the company is still in the process of fixing the problem.

    John, a systems administrator for a major U.S.-based manufacturing company, said a DNS poisoning attack like the one SANS described last month led to Internet problems for roughly 8,000 of his company's 20,000 employees. John asked that his surname and employer's identity be omitted from this story because the company is trying to determine if it is still vulnerable.

    In the following weeks, several more attacks ensued that sent victims at John's company to Web sites advertising penis-enlargement pills.

    Marcus Sachs, director of SANS and a former White House cyber-security adviser, said the security industry's response to their alerts about the attacks has been little more than a collective "yawn." Meanwhile, Sachs said, it appears the Internet connection at a San Diego hotel where the organization is holding its annual conference this week also was hit with a poisoning attack (the guy at the hotel who handles Web site security hasn't yet returned my calls.)

    "People are waving this off and saying 'This is nothing new, we've seen this kind of thing before, let's move on.' But the consensus amongst the SANS folks is that something doesn't feel right here, and that there's more to this story than meets the eye. We feel like there's something deeper going on here, but the fact is there are not a lot of people out there in the security industry who are willing to dig deep and get to the bottom of this."

    --
    ...because you never know who you're dealing with.
  10. 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.