Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
The Internet Security IT

DNS Cache Poisoning Spreads Malware 314

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."
This discussion has been archived. No new comments can be posted.

DNS Cache Poisoning Spreads Malware

Comments Filter:
  • by DarkHelmet ( 120004 ) * <mark&seventhcycle,net> on Wednesday April 06, 2005 @01:25PM (#12156166) Homepage
    Oh man, this article gave me an idea. Too bad it's a couple days late, or else it would have made a *great* april fools for the workplace here.
    1. Change the company's DNS server here to map google.com to a private machine here on the network.
    2. Create a frontend on the internal machines here that looks exactly like google.com
    3. Map the internal IP addresses on the network to specific people here.
    4. Inject specific "spooky" messages into the search results based on the IP address of the querying machine. Examples would be like: "How about looking at some pr0n, Mr. Bridges?" or "You really should have that bald patch looked at, sir."
    5. April Fools! HA HA!
    6. Look for a new job.
    Oh well, you only live once.
  • IRC (Score:4, Informative)

    by Wizy ( 38347 ) <`moc.liamg' `ta' `chgtaggerg'> on Wednesday April 06, 2005 @01:26PM (#12156171) Journal
    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.
    • Yes and no. (Score:4, Informative)

      by jd ( 1658 ) <imipak@yahoGINSBERGo.com minus poet> on Wednesday April 06, 2005 @01:56PM (#12156596) Homepage Journal
      It has been dealt with, at the specification level. DNSSEC has been around for a while and for the ultra-paranoid, you can always run IPSec tunnels between DNS servers.


      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.

      • Re:Yes and no. (Score:3, Interesting)

        by MikeBabcock ( 65886 )
        Opportunistic encryption (ipsec) enabled for all root DNS servers would be a nice start. Published keys, etc.

        At least then we'd know the root data was from the roots.
    • No (Score:5, Informative)

      by temojen ( 678985 ) on Wednesday April 06, 2005 @02:04PM (#12156694) Journal
      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.
      • Re:No (Score:2, Informative)

        by Wizy ( 38347 )
        The first spoofing tool I used on irc (EFNet) actually did cache poisoning. I know there are the tools that only did the reverse lookup spoofing. But the cache poisoning was done way back when. I believe (and I could be mistaken) that a guy by the name of johan wrote one of the first ones.
    • Re:IRC (Score:3, Informative)

      by Anonymous Coward
      There are some things DNS implementors can do to protect against DNS cache poisoning. The best article about the subject is here [cr.yp.to].

  • by Cruithne ( 658153 ) on Wednesday April 06, 2005 @01:26PM (#12156175)
    following a rash of active DNS poisonings

    Damn internet rashes, they're the worst. Remember, dont surf without protecting your board. :/
  • by hey ( 83763 )
    I am sooo glad that SANS uses colored alerts like "Homeland" Security. Its pretty tacky. I guess the first time I heard about it was in the orginal Star Trek. Nothing tacky there.
  • by loqi ( 754476 ) on Wednesday April 06, 2005 @01:28PM (#12156207)
    I give it two years until the sight of a rainbow fills me with abject terror and confusion.
    • forget rainbow, wait till the perfect orange sunset, and run around screaming even mother nature knows terrorists are coming.

    • The rainbow [wikipedia.org] already fills most republicans with abject terror and confusion.

      Maybe that's why they invented that terror warning thing.
    • by oneiros27 ( 46144 ) on Wednesday April 06, 2005 @01:51PM (#12156523) Homepage
      Kryten:
      We must take action. Be bold, positive, decisive. I suggest we move from blue alert to red alert, sir.
      Cat:
      Forget red! Let's go all the way up to brown alert!
      Kryten:
      But there's no such thing as brown alert, sir.
      Cat:
      You won't be saying that in a minute. And don't say I didn't alert you!

      Red Dwarf, Series 8, Episode 1.

      • by mmkkbb ( 816035 ) on Wednesday April 06, 2005 @01:59PM (#12156635) Homepage Journal
        *KABOOM*

        Arrr, an attack! Matey, fetch me red shirt! Can't let the men see me bleedin' if I get hit! ...

        *KABOOM*

        Arrr, that was a close one! Fetch me brown pants too!
      • by Fjornir ( 516960 ) on Wednesday April 06, 2005 @02:18PM (#12156858)
        RIMMER: Go to blue alert.
        LISTER: What for? There's no-one to alert - we're all here.
        RIMMER: I would just feel more comfortable if I know that we're all on
        our toes 'cos everyone's aware it's a blue-alert situation.
        LISTER: We all are on our toes.
        RIMMER: May I remind you all of Space Core Directive 34124?
        KRYTEN: 34124. "No officer with false teeth should attempt oral sex in
        zero gravity".
        RIMMER: Damn you both, all the way to Hades! I want to go to Blue Alert!
        LISTER: Ok, ok.
        .
        .
        .
        LISTER: Too small for a vessel... maybe some kind of missile.
        KRYTEN: It's impossible to tell at this range. Whatever it is, they
        clearly have a technology way in advance of our own!
        LISTER: So do the Albanian State Washing Machine Company.
        RIMMER: Step up to red alert!
        KRYTEN: Sir, are you absolutely sure? It does mean changing the bulb.
        RIMMER: There's always some excuse, isn't there?
  • Then why haven't we hard about it before it got this serious?

    I mean, isn't there a way to make people aware of stuff like that? I don't want some script kiddie seeing my google searches for pr0n.
  • by bcmm ( 768152 ) on Wednesday April 06, 2005 @01:29PM (#12156220)
    Is this done basically by taking over insecure DNS servers or is something more subtle involved, e.g. making comuters treat your machine as their DNS server instead?
    • by Tony Hoyle ( 11698 ) <tmh@nodomain.org> on Wednesday April 06, 2005 @01:32PM (#12156265) Homepage
      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.
    • by Anonymous Coward
      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.
    • by Stuwee ( 739059 ) on Wednesday April 06, 2005 @04:05PM (#12158208)
      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.
  • by ackthpt ( 218170 ) * on Wednesday April 06, 2005 @01:31PM (#12156248) Homepage Journal
    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.

  • Question (Score:5, Funny)

    by Ryosen ( 234440 ) on Wednesday April 06, 2005 @01:32PM (#12156267)
    I've been using Opera for 6 years now and I'm a little confused.

    What is "malware"?
    • Malware would be the "bonus added value" that your younger_brother/sister/mother installed on your computer along with real_player/real_arcade/other_silly_program/etc.

      Tom
    • Re:Question (Score:4, Informative)

      by OnceWas ( 187243 ) on Wednesday April 06, 2005 @01:52PM (#12156544)
      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.
  • Isn't this kind of attack on the global Internet exactly the kind of thing that Homeland Security's "Cybersecurity" department is responsible for stopping? What are we paying them billions of dollars, and suspending our liberties, to do? While we're at it, what's the difference between National security, Homeland security, and Defense? Aren't they all just riding a single planebombing to unchecked power and riches, without accountability or results?
  • by bad_outlook ( 868902 ) on Wednesday April 06, 2005 @01:41PM (#12156398) Homepage
    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 [cr.yp.to]

    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

    • by Tuqui ( 96668 ) on Wednesday April 06, 2005 @01:49PM (#12156495) Homepage
      The separation between DNS Server and DNS Cache is very clever. This is a point that even BIND must take care.
    • by Anonymous Coward
      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 h
    • by nothings ( 597917 ) on Wednesday April 06, 2005 @05:49PM (#12159354) Homepage
      While I don't think I'm in the clear because of this, I feel better protected from the (unwashed ;)) internet.

      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:

      • Bugs outside of djbdns, such as OS bugs or browser bugs. (People could seize control of BIND 9.1 through an OpenSSL buffer overflow, but that was a bug in OpenSSL, not in BIND.)
      • The vulnerability of DNS to forgery [cr.yp.to]. (BIND's port reuse makes blind forgery much less expensive, but this is a quantitative difference, not a qualitative difference. The DNS architecture needs cryptographic protection.)
      • Denial-of-service attacks. (BIND 9's fragility makes denial of service completely trivial; but an attacker can easily take down the Domain Name System without using any of BIND's bugs. The DNS architecture needs to be decentralized.)

      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 [securityfocus.com], 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.

  • by loopsandsounds ( 752223 ) on Wednesday April 06, 2005 @01:43PM (#12156425) Homepage
    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.
  • Have you done this lately? I've never seen so much nonsense, rejections, security denials, et al.
  • by Paradox ( 13555 ) on Wednesday April 06, 2005 @02:04PM (#12156696) Homepage Journal
    Ahh, Windows. People use it for servers too.

    From TFA:
    Basically, the UNIX-based stuff has been secure against cache poisoning
    for quite some time, but there may always be a bug or design flaw that
    is discovered. We are not quite sure why Microsoft left a default
    configuration to be unsecure in NT4 and 2000. (Exercise to reader:
    insert Microsoft security comment/opinion/joke here, but keep it to
    yourself).


    The worst part about DNS cache poisoning is that it affects DNS nodes underneath it in the hierarchy. So if you're below a Windows DNS that gets attacked, you yourself may be subject even if your local DNS is in fact secure.

    Oh, and fear caching http proxy servers that touch DNS servers that get poisoned. They can keep the bad data around for a long time.

  • by tsu doh nimh ( 609154 ) on Wednesday April 06, 2005 @02:09PM (#12156740)
    Washingtonpost.com is running an interesting story [washingtonpost.com] 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."

    • by httptech ( 5553 ) on Wednesday April 06, 2005 @02:39PM (#12157076) Homepage
      I wrote this article [lurhq.com] 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/ [lurhq.com]

      • by McSpew ( 316871 ) on Wednesday April 06, 2005 @07:14PM (#12160173)

        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.

        • by httptech ( 5553 ) on Wednesday April 06, 2005 @09:32PM (#12161392) Homepage
          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.

          Despite the fact that your experience contradicts MS and CERT-CC, I'm willing to accept the possibility that because the .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).

          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.
  • Every undergraduate CS program should integrate some secure coding standards. Something like this:

    link [stanford.edu]
  • by latuZimZactly ( 753190 ) on Wednesday April 06, 2005 @02:21PM (#12156896)
    Wrote about this today in his blog:

    http://blogs.washingtonpost.com/securityfix/ [washingtonpost.com]

    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.
  • I've seen this (Score:4, Insightful)

    by benjamindees ( 441808 ) on Wednesday April 06, 2005 @02:29PM (#12156982) Homepage
    For months now, since at *least* the first of January. It's mostly been google.com, redirecting to some odd webpage, but not any of the ones listed.

    I figured the problem is that I was pointing to an old DNS server for SBC. They won't give you the IPs of the new DNS servers unless you fire up their awful PPPoE program. We use Linux, and this incident has been an excuse to remove the last few Windows computers from the network. It'll probably also be an excuse to rid ourselves of SBC's horrendous services.
  • by ewhac ( 5844 ) on Wednesday April 06, 2005 @02:56PM (#12157269) Homepage Journal
    ...the SANS Internet Storm Center has raised their alert level to Yellow following a rash of active DNS poisonings.

    ATTENTION: ALERT LEVEL UPDATE. The authorities at SANS (Sebben-Affilliated Network Security) have issued this network alert update:

    The DNS cache poisoning alert has been upgraded from "Yellow" to "Blackwatch Plaid." Repeat: DNS cache poisoning alert level is now at Blackwatch Plaid.

    Available information does not yet justify a further upgrade to alert level "Moving Pictures."

    And for everyone's safety and security, and to preserve our way of life, SANS is taking a drastic step and installing a network monitor. Just one. For safety, security, and omniscient, unblinking information gathering of everyone's activities.

    :-),
    Schwab

  • worst one; (Score:3, Informative)

    by jafac ( 1449 ) on Wednesday April 06, 2005 @02:57PM (#12157290) Homepage
    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.
  • DJB Says (Score:3, Insightful)

    by illuminatedwax ( 537131 ) <stdrange@nOsPAm.alumni.uchicago.edu> on Wednesday April 06, 2005 @06:15PM (#12159610) Journal
    I told you so!

    Time to stop running BIND and Windows, people.
    djbdns is easier to set up by leaps and bounds, anyway.

1 + 1 = 3, for large values of 1.

Working...