Forgot your password?
typodupeerror
Security The Internet IT

Ten Percent of DNS Servers Still Vulnerable 170

Posted by Zonk
from the watch-our-back dept.
maotx writes "Even with the uproar caused by the recent DNS attacks, a recent study shows that roughly 10% of 2.5 million DNS servers show that they are still vulnerable to DNS cache poisoning. To put that a little bit more in perspective, of that 10% discovered, 230,000 were identified as potentially vulnerable, 60,000 are very likely to be open to this specific type of attack, and 13,000 have a cache that can definitely be poisoned." From the article: "The use of DNS cache poisoning to steal personal information from people by sending them to spoofed sites is a relatively new threat. Some security companies have called this technique pharming."
This discussion has been archived. No new comments can be posted.

Ten Percent of DNS Servers Still Vulnerable

Comments Filter:
  • by bigwavejas (678602) * on Thursday August 04, 2005 @12:44PM (#13241197) Journal
    Why is it that the Admins can't take it upon themselves to keep their software updated with the latest patches? Instead, it takes an article like this to get them off their asses to take action. It shouldn't be this way.

    This is strikingly similar to the Cisco OS debacle, where a patch had been available for some time, yet Admins failed to patch their hardware on their own. Yes, it's a pain in the ass to take your network down, but look at the alternative...Hacked!

    • agreed, with phishing scams, we can blame the users who fall for the scheme... it seems these techniques are undetectable to the end user...
      • with phishing scams, we can blame the users who fall for the scheme

        While there are always some who fall for the most obvious scam, theses attacks are becoming more professional by the day, and no company can afford to absentmindedly blame their users (yes, I work for a company that sells anti-abuse services, we've been on the cutting edge of this for a while).

        The article writer references the term "Pharming"; while DNS cache poisoning is a form of Pharming, its much bigger than that. Its basically a va

    • by Kainaw (676073) on Thursday August 04, 2005 @12:49PM (#13241275) Homepage Journal
      Why is it that the Admins can't take it upon themselves to keep their software updated with the latest patches?

      You are assuming the fix is a patch. I get vulnerability reports for my servers every week. The issues are never patches because I check for new patches every day. I get vulnerabilities that have no patch of any kind, yet I'm expected to somehow rewrite all of the software on the computer to fix the vulnerability. If I could do that, I wouldn't be working here. I assume that I am in the same position as most admins, I have to wait for the patches to come out and hope nothing bad happens while I'm waiting.
      • I agree, it's not always going to be a patch. Although I would venture to say for the majority of problems, patches are avaialble. Yes, there are going to be excuses why people don't maintain a secure environment. For me it's generally a PITA to update our internal servers (inside the firewall), because I depend on our "Security Group" to post the system patch somewhere inside the firewall where I can download it. Yet, I can guarantee you one thing... the instant a new patch *is* available I immediately
      • >Why is it that the Admins can't take it upon themselves to keep their software updated with the latest patches?

        You are assuming the fix is a patch. I get vulnerability reports for my servers every week.

        And then there are patches like the last two Oracle patches which - get this - actually made it worse.

        Sometimes it's a good idea to wait for them to patch the patch.
      • by Bi()hazard (323405) on Thursday August 04, 2005 @01:26PM (#13241795) Homepage Journal
        The fix in question here is available. The BIND webpage [isc.org] has a scary warning box on the right with details. Everyone should be upgrading to the new version.

        But it's not surprising that there's still vulnerable servers out there. In fact, I'm surprised the total is so low. Aside from the few admins who just aren't doing their jobs, these kinds of things often run into bureaucracy. In many organizations, upgrades have to be thoroughly tested before release and there's standard schedules for patch cycles. An admin who wants to simply stick a new version of something on the production server may be told to wait until approval comes. That could take a while. And occasionally you'll have some crappy system that doesn't work well with the new software, and they're stuck rolling back until the problem is solved.

        I had a friend who worked at a small ISP that had some serious security issues. The guy who should have been patching things "resigned"-something to do with the smell of pot lingering in his office. Anyways, the position went vacant for a little while and the task fell to the two new interns, my friend and another girl. Coincidentally they were both young women and had no experience relevant to the job, proof of quality hiring practices. To make a long story short, the (not terribly large) customer database got hacked and the company was sued. The owner, who had been heavily in debt already, vanished completely. Naturally the whole thing went down in flames and my friend didn't even get a reference out of it.

        Most of you are probably sitting there thinking this story is too outlandish to be true. Haha, well, this is the internet so you never know what to trust, but you know there's places out there where things just aren't done the way they're supposed to be. It's shocking what goes on, and there will always be vulnerable servers around.

        Getting it down to the numbers in the article this quickly is actually pretty good. The real lesson here is that you need to insulate yourself from the fools who won't take responsibility. Always assume 10% of the internet is out to get you, because they probably are. Hey, I don't even want to think about what 10% of slashdotters would want to do to me.
        • Aside from the few admins who just aren't doing their jobs, these kinds of things often run into bureaucracy. In many organizations, upgrades have to be thoroughly tested before release and there's standard schedules for patch cycles.

          It's not bureaucracy at all.

          A patch can have the following adverse qualities

          1) Bring down your systems. (Not quite as bad as being hacked but nonetheless not something that most businesses want and some simply can't afford it)

          2) Break individual applications. Custom applicatio
    • by Anonymous Coward
      Why is it that the Admins can't take it upon themselves to keep their software updated with the latest patches?

      Maybe they are all Microsoft Certified?

    • Well, the Admins cannot be blamed entirely in the Cisco case. Cisco was blamed for not pushing the importance of that patch.

      While, in a perfect world, admins should immediately be on top of every new patch, if I noticed a patch that I thought was just a couple of minor bug fixes, it would go on the end of the "whenever I have time" list.
    • This is strikingly similar to the Cisco OS debacle,

      No, it isn't. Before the IOS "debacle" it was assumed that remote code execution on IOS was impossible. It's pretty hard to compromise an unpatched system if it's impossible to execute code on it, so admins didn't bother taking down their networks to run the (mostly aesthetic) patches.

    • This is worse than the Cisco debacle.

      Bind9 has been out for years now so there should have been plenty of time to make the few changes needed to the configs to make them compatable with bind9.

      This is just a shot in the dark but I'm guessing any isp dumb enough to be still running bind 4 has much more serious problems than DNS cache poisoning.
    • Hmmm...
      emerge bind
      /etc/init.d/named restart
      Seems to work pretty well. And doesn't take anything "down."

      Gentoo, of course.
      • emerge bind; /etc/init.d/named restart seems to work pretty well

        Cool. You can share it with your LUG at the local library. Now pardon me while I return to rearchitecting an 8,000 server environment.
        • "Cool. You can share it with your LUG at the local library. Now pardon me while I return to rearchitecting an 8,000 server environment."

          You'll be using DJBDNS instead of BIND then I take it?

    • by Burdell (228580) on Thursday August 04, 2005 @01:36PM (#13241947)
      In the case of the Cisco IOS problems, nobody knew there was a problem
      to be patched. That was the biggest part of the problem: Cisco's
      silence.

      When you run services that must be up 24x7, you don't donwload every new
      IOS release and load it on dozens or hundreds (or more) of devices just
      because there was a new release. IOS often has more new bugs in each
      release than bugs fixed; when you find a release that has the features
      you require and is stable with those features running, you don't touch
      it until you find a bug, require a new feature, or Cisco announces a
      security problem.

      I run a relatively small network, and I'm looking at having to upgrade
      around two dozen devices running IOS in six cities (a number of which
      require visiting an unmanned office because some things can't be
      upgraded remotely) plus another dozen or so devices in our spares
      inventory in two cities. I'm not going to upgrade any operating devices
      until I can test new releases in a test setup. All of that takes a lot
      of time, which means something else has to get pushed back.
      • Some while back, I was working as a sub-contractor to a contractor working at a government facility. Due to some needed new features and security holes, it was decided that all the Cisco routers would be upgraded to a new IOS. The work was scheduled for a weekend when the entire facility would "go quiet". The planning was immaculate -- with time alloted for each router IOS upgrade, time set aside for new IOS patches, and reloading the working data. Through some rather long weekend hours, the Cisco route
    • wait!! (Score:2, Insightful)

      by tdubya (823850)
      Why isn't this said when a microsoft issue comes about, and there has been a patch for some time... it's always bad microsoft!!!

      Now that's it's Bind, it's the admin's fault?
      • Well, the difference between this and MS is that admins are supposedly being paid to take care of these systems. End users are a bit of a different story.
    • ...are 20 year olds who count computers and networking as their prime hobby.

      Some of us are 40, with kids, houses, and other interests that make some server in a hard-to-get location with hard-to-get downtime less than appealing to patch. And then there's management's attitude towards it -- you patch, after hours, and you don't get paid. OK...

      I can remember when patching all night was kind of fun. Now I call sleeping kind of fun. I get paid to do my job, but not to bust my hump doing it.
  • What? (Score:5, Funny)

    by ucahg (898110) on Thursday August 04, 2005 @12:46PM (#13241220)
    230,000 were identified as potentially vulnerable, 60,000 are very likely to be open to this specific type of attack, and 13,000 have a cache that can definitely be poisoned.

    Okay, let's have it for unclear writing!

    Seriously, what does this even mean? Of the 250,000 that are vulnerable, 230,000 are vulnerable, 60,000 are vulnerable, and 13,000 are vulnerable.

    Okay, that clears it up.
    • 230,000 we don't know but needed to boost our numbers, 60,000 we're pretty sure but still needed more of a numbers boost, and 13,000 we actually got around to testing!
    • Seriously, what does this even mean? Of the 250,000 that are vulnerable, 230,000 are vulnerable, 60,000 are vulnerable, and 13,000 are vulnerable.

      You beat me to the punch. 10% of 2.5 million is 250,000. While the person who wrote the article might be a good writer, it stands to reason because they are terrible at math.

      Anyways, that aside, if they identified 250,000 DNS servers with their rating scale, couldn't they at least let the admins of each of the 250,000 DNS servers know? Yeah, I know I'm going t

    • 230,000 IP addresses forward to BIND8. They may BE that same host, though, with an alternate address. Or they may be other BIND8 systems.

      60,000 hosts forward to BIND8, but are not themselves running BIND8. I don't know about every single other host.

      13,000 are Windows systems forwarding to BIND8. This is verboten explicitly.

      Things are made much harder by the fact that I'm reticent to actually exploit this many hosts.
  • Not Suprising (Score:2, Interesting)

    by cmdrTacyo (899875)
    This is not suprising at all especially considering the history of DNS and it's mainframe components. They will always be vunerable, especially for people who do not have the proper PPS setup. I wouldn't be suprised if it's more then 10%.

    It's tacyo YO!
  • bad math (Score:4, Insightful)

    by rwven (663186) on Thursday August 04, 2005 @12:51PM (#13241301)
    with almost all of the potentially vulnerable ones they only said really that 73k of them were vulnerable to something... and only 10k of those "definately" were.... 73k = 2.92% The onlther 230k might not have been vulnerable at all, they just think there's a chance that they might be. This, ladies and gents, is called sensationalism...
    • This is like - OMFG!!! We need to drum up business, only 3% of servers are vulnerable, you know what I mean? We need to - pssssshhh, you know, get some stuff in print, but, like you know, we can't just say 3%, we gotta blow that up a bit, like by 1000%, like, put some more and bigger numbers in there, nobody is gonna check, math is hard, you know what I mean??? Pssshhh...

      Stupid idiots...
  • DJBDNS -- rocks (Score:4, Informative)

    by www.sorehands.com (142825) on Thursday August 04, 2005 @12:52PM (#13241329) Homepage
    I have been using the DJBDNS with the DJBDNS rocks [djbdnsrocks.org]installation under FC2. This makes it very easy to install and manage.

    The same person also does Qmail Rocks [qmailrocks.org]. Of course djbdns and qmail is much more secure than bind and sendmail.

    • Re:DJBDNS -- rocks (Score:3, Insightful)

      by winkydink (650484) *
      Too bad its author is so off-putting as to drive poeple away from both in droves.
      • I've met DJ twice. It isn't that he doesn't have a sense of humour or tact. It's that he thinks he's so much better than everyone that he ignores anyone elses opinions or suggestions or ideas.

        If he gave two shit about OTHER PEOPLE he'd spend more time making the tools [not just djdns but his crypto code] actually easy to work with.

        I mean it's a DNS server. I don't understand the big guffaw about it. Respond to requests on port TCP:53 ... not exactly hard.

        Tom
        • It's that he thinks he's so much better than everyone that he ignores anyone elses opinions or suggestions or ideas.

          Making him the biggest megalomaniac since Captain Ahab.
        • "If he gave two shit about OTHER PEOPLE he'd spend more time making the tools [not just djdns but his crypto code] actually easy to work with.

          I mean it's a DNS server. I don't understand the big guffaw about it. Respond to requests on port TCP:53 ... not exactly hard."


          Having used both extensively I'd say while BIND4 is a little bit easer to set up, TINYDNS (the authoritative DNS server in the DJBDNS suite) is easier than BIND8 or 9 to set up and (MUCH) easier to work with in a production environment.

          The fir
      • Do you run Bernsteins software or his personality?

        I tried putting his personality in a file and running it, but damn if it would not resolve any names.

        Then I tried using his code and ohfuck does it work SO MUCH better than the Buggy Internet Name Daemon.

        I've seen Dan about for 20 years on usenet. He's always been a prick but so am I; we get along fine. Don't waste his time and he's one of the nicest and smartest people you'll meet. He does not suffer fools well.

        I have no problem getting along with people th
    • Re:DJBDNS -- rocks (Score:3, Informative)

      by Feyr (449684)
      as i said many times when i installed djbdns a few months ago. djbdns is crap, but it's the best crap available

      as for being more secure... it doesn't have nearly the same complexity and features as say, bind.
      • The thing is, it doesn't need to. It's just DNS. It should be simple and not like BIND where things are (imho) unnecessarily complicated. djbdns is a great example of 'set it and forget it'. Not as good of an example as, say, a Ronco Rotisserie, but it's up there.
      • Re:DJBDNS -- rocks (Score:4, Insightful)

        by arivanov (12034) on Thursday August 04, 2005 @01:39PM (#13241993) Homepage
        Correct.

        Apples and oranges.

        There are places where you would have to use BIND and places where you can get away with a partial implementation. If an ISP is using DJB-DNS I would recommend to stay away from it. There is a number of neat tricks in the bind cache expiration algorithm (from late 8 and early 9 onwards) which DJB has blamed unnecessary (see the BUGTRAQ archives for the discussion). While they are not necessary they are essential to ensure that operational mistakes have a limited life. That does not happen with DJB implementation as well as some other ones. So if you screw up your TTL or serial no on the zone files - this is it. Same for poisoned entries.

        Further to this. DNS is the most easily upgradeable service. Clients fallback automatically and a few seconds of downtime are in the "who cares" area. In fact every ISP out there has scheduled daily mandatory reloads which update configs. Do users notice - nope.

        Even further to that, there are methods to make any number of dns servers answer the same address and because DNS is stateless this can be done without any clustering crap. ISC which writes bind have done this for 7+ years. Most global telcos and ISPs do it as well.

        And, in order for DNS poisoning attacks to be effective name servers usually need to have both recursion turned on and return authoritative answers. Doing this on an internet facing server is an idiocy. If your ISP does that and serves authoritative requests from the same server which is used for name resolution in clients - RUN. They have NO CLUE WHATSOEVER. If they use clustering for resilience - run even faster.
        • "So if you screw up your TTL or serial no on the zone files - this is it."

          That'a why there's instructions on the DJBDNS site to fix this. (You wrap around the serial, duh).

          Even without the almost daiy BIND bugs, there's no reason to use it, ever.
      • Re:DJBDNS -- rocks (Score:3, Interesting)

        by demon (1039)
        If you think that DJBDNS is as good as it gets, you really need to check out http://www.powerdns.com/ [powerdns.com]. We switched to it at work (I pushed it, really), and I wrote a nice custom web-based frontend so our customers can manage their DNS domains independently - they can even create new ones as necessary. It's taken DNS out of the "necessary evil" realm, and brought it into a realm of being a "useful service". I recommend it heartily.

        (No, I'm not a developer or otherwise affiliated with the project - just a ver
        • i actually looked at powerdns before settling on djbdns. i even had a working setup

          the problem is that there is no easy way to manage the data. there's no good frontends already available for it. whereas with tinydns you don't need one.
          • I guess I don't consider cryptic zone files (ala DJBDNS) better than SQL tables. Structured storage is a very nice thing, and it makes it a lot easier to manage. Also, I've heard at least some good things about PowerAdmin (though I haven't used it myself, since our requirements were such that a custom frontend was necessary).
    • Re:DJBDNS -- rocks (Score:3, Informative)

      by geniusj (140174)
      I use djbdns for the dynamic DNS/DNS hosting provider mentioned in my sig. It's worked out amazingly well, and it's been deployed that way for a few years now. There's a few reasons I really like it:

      1) The rsync method of replication is very well suited for keeping multiple DNS servers synced with the exact same records.

      2) I never have to worry about it or touch it

      3) The CPU and memory usage are much lower than when I was doing this with BIND. In fact, it's pretty much negligible with a few hundred queri
    • djbware is so broken its not even funny. the "human readable" zone files is beyond a joke. lack of support for ipv6 is also a huge blow (yes, I know you can get 3rd party patches for it. but I can also just run bind, and have an actually functional dns server).

      mark me as a troll, I don't care.
  • by Zab UvWxy (694326) on Thursday August 04, 2005 @12:53PM (#13241339) Journal
    Some security companies have called this technique pharming.

    Phor phuck's sakes! I've had enough of this phreaking 733T-speak from the phucking security compaines! It was original with phreaking; it was mildly amusing with phishing; now it's just annoying.

    Why not just leave the terminology as "DNS cache poisoning" and be done with it?
    [/rant]
  • Don't Know Standard patches
  • by Anonymous Coward on Thursday August 04, 2005 @12:54PM (#13241358)
    ...or for any other DNS exploits, for that matter?

    Any good tools to (or sites to help) check for those?
    • by Malor (3658) on Thursday August 04, 2005 @01:50PM (#13242144) Journal
      I'm confused about this one too. This is what I THINK is going on with this exploit. Hopefully, someone who ACTUALLY knows will correct my mistakes. :)

      One of the possible ways to set up a DNS server is as a 'forwarder'. This means that it doesn't do lookups itself, but rather passes all DNS requests to another machine, gets replies, and then sends replies to the clients. One reason you might do this would be to distribute DNS load in a big ISP; you have a few machines that do the actual outbound DNS determination, and then the cache ripples back to the servers that are actually talking directly to the clients. DNS is fairly low-load, relatively speaking... this architecture would date from when everyone was deploying 50Mhz machines as servers. I'll call the local BINDs 'caching' servers, and the one doing the actual lookups on the internet the 'point' server.

      So in and of itself, this architecture isn't a problem. But one of the features of the DNS protocol is that any server can send back more data than what was actually asked for, even data that is totally unrelated to the main query. Caching BIND servers by default trust their point server. And, when functioning as a point forwarder, BIND4 and BIND8 apparently just pass along queries they receive without checking them. The point BIND assumes that the caching BINDs are checking, while the caching BINDs assume the point BIND is checking, and the packet never gets checked for sanity at all.

      So Joe Hacker snoops around... he tries to find DNS servers on your network. Once he finds one, he queries it for a name in a domain he controls. (or he initiates a connection to a webserver on the same machine, which may cause the same DNS lookup). He watches for the request to his DNS server coming from a DIFFERENT machine. That often indicates a forwarder configuration.

      So he waits for his cached info to expire, and does it again... except this time, his reply packet includes extra information, "Oh, by the way, www.microsoft.com is on joes.evil.server.here." If BIND4 or BIND8 is the functioning as the master lookup in a forward configuration, it just passes along the packets it receives. And when BIND is in a SLAVE configuration, it just trusts what it gets from the forwarder. So suddenly, your whole network is connecting to joes.evil.server.here instead of www.microsoft.com. And if it doesn't work, oh well, next DNS server... this is a very low-profile attack. You have to really be LOOKING for it to be able to see it.

      Apparently, the workarounds are A) don't use a forwarder configuration. There's no real need for this anymore, even a cheap 1ghz machine with a gig or so of ram will serve tens of thousands of clients. B) if you MUST use a forwarder, use BIND9 (or, presumably, DJBDNS) as your 'point' machine. BIND9 does sanity checking when it's on point.

      Hopefully I got this right. I haven't been paying much attention to this before, because I (rightly) didn't think it affected me. If I'm wrong, PLEASE correct me, I hate to spread misinformation.
      • If I'm wrong, PLEASE correct me, I hate to spread misinformation.
        Oh, you must be new here. ;)
      • by 3l1za (770108) on Thursday August 04, 2005 @09:03PM (#13246219)
        So he waits for his cached info to expire, and does it again... except this time, his reply packet includes extra information, "Oh, by the way, www.microsoft.com is on joes.evil.server.here."

        What the badguy actually does is:
        • gets queried for www.badguy.com by target.com
        • delegates authority for HIS nameservers to ns.yahoo.com, for example; so he says:
          • www.badguy.com NS ns1.yahoo.com
          • www.badguy.com NS ns2.yahoo.com
          • ...
        • ALSO includes fake mappings of the form:
          • ns1.yahoo.com A 1.2.3.4
          • ns2.yahoo.com A 1.2.3.4
          • ...
        • so target.com contacts "ns1.yahoo.com" at 1.2.3.4 and asks to resolve "www.badguy.com"
        • since ns1.yahoo.com is *actually* a name server under bad guy's control (bad guy controls 1.2.3.4), ns1.yahoo.com returns how to get to www.badguy.com
        • then in future queries for www.yahoo.com, the name server will ask 1.2.3.4 for the IP for www.yahoo.com and send that reply to the requestor
        Much better explained here [cr.yp.to]

        As DJB says, the "work around" is not to accept authoritative mappings (e.g. ns1.yahoo.com A 1.2.3.4) from anyone but yahoo.com.
      • [parent deleted]

        That's rather long winded but the bottom line is DJBDNS will not believe any answers that don't come from the corect servers. BIND is a whore and will believe anything, even out of balliwick answers. Big problem. Well understoood for a long time.

        The technique you describe above is how EK stole the internic.net domain a decade or so ago. He sent you mail, which bounced, your machine looked up up his MX record by asking his server to return the bounce, and got wrong internic.net A records when
  • New term! (Score:4, Funny)

    by springbox (853816) on Thursday August 04, 2005 @12:55PM (#13241367)
    "Some security companies have called this technique pharming."

    A lot of these new vulnerabilities have the "phat" theme as dictated by the industry's leading security researcher/rapper Prompt Master Chizzy. Expect an RFC soon on the new naming convention.

  • Stealing? For important information websites should use HTTPS (certificates detect DNS spoofs).
    • Certificates do not detect nothing, the clients using the certificates *may* detect that the hostname is not correct. There is a bug in IE that can be easily used to spoof websites using a man in the middle attack. And certificates can be had pretty easily, there is enough proof for that.

      Furthermore, the use of HTTPS is not a panacea. Not all companies may like HTTPS since the underlying SSL connection will not let their proxy scan the contents of the connection. This would make it very easy for e.g. porn s
  • by Epistax (544591) <epistax AT gmail DOT com> on Thursday August 04, 2005 @12:59PM (#13241441) Journal
    Exec 1: We at our company want a an attack name with attitude. It's edgy, it's "in your face." You've heard the expression "as easy as stealing from a baby"? Well this is an attack which makes it "eezzay!". Consistently and thoroughly.

    CEO: So it's speculative, huh?

    Exec 1: Oh, God, yes. We're talking about a totally outrageous paradigm.

    Exec 2: Execuse me, but "speculative" and "paradigm"? Aren't these just buzzwords that dumb people use to sound important? [backpedaling] Not that I'm accusing you of anything like that. [pause] I'm fired, aren't I?

    CEO: Oh, yes.
    CEO: The rest of you start thinking up a name for this funky attack. I dunno, something along the line of say... farming, only more dangerous and 1337.

    Exec 1: So, Pharming okay with everybody?

    All: [reclining in their chairs] Yeah...
    • Redundant? Fine. Note to self: Do not go searching for a funny way to state what I know others will say. Do not do it more intelligently. Allow the people who are bitching to simply type out a message as fast as they can. It does not matter that when I started my message, none of theirs had been posted yet. Since they will beat me to pressing the button because I am putting thought into my post, I am redundant.

      Well excuse me. Go back to MTV.
  • Didnt ISC release a warning to stop using forwarders on BIND4/8 several months ago? Guess it'll take a major attack, in which thousands of people lose personal information, for people to act on the warnings.
  • by sarlos (903082)
    Someone's gotta speak up for the poor admins. Not all of them really are morons for not patching. There are cases where the patch breaks more than it fixes. In these cases, it's often more economical to just leave the vulnerability there (hey, at least you know about it) than to try to patch it. SQL Slammer caused some serious problems with IIS because the 'patch' for the bug it exploited was part of a large update that required a lot of man-hours to clean up after. Of course, there are plenty of moron
  • by kossak (905158) on Thursday August 04, 2005 @01:34PM (#13241924)
    DNS Cache Spoofing is not the only nasty trick available to DNS hackers; There is a (still) relatively unknown vulnerability afecting the vast majority of nameservers today, and one that is not easily resolved by patches alone.

    Check out my paper about this, its called DNS Cache Snooping [sidestep.pt], and allows for a bunch of interesting tricks. It afects most of DNS Server/Cache combination implementations and is triggered by an extremely common misconfiguration, one that allows for the whole of the internet to use a given DNS server as their primary DNS server.

    Luis Grangeia
  • Email redirection (Score:4, Interesting)

    by Deanalator (806515) <pierce403@gmail.com> on Thursday August 04, 2005 @01:36PM (#13241959) Homepage
    DNS cache poisoning doesnt stop at tricking people out of their money. At defcon Kaminsky also showed how it can easily be used to do things like email misdirection, which I think is much more of a big deal.
  • by PhraudulentOne (217867) on Thursday August 04, 2005 @01:43PM (#13242056) Homepage Journal
    Can I get a list of these vulnerable servers so I can.. umm... see if I'm on it and patch my systems? Yeah.. that's it.

  • Given that it is djbdns, I'm not worried, but having a test suite for vulnerabilities is a good thing.
  • Hardly New (Score:3, Interesting)

    by DynaSoar (714234) * on Thursday August 04, 2005 @01:59PM (#13242272) Journal
    We were fighting people doing this 10 years ago. Some of the second-gen (meaning they used at least some technology rather than outright and direct use as is) usenet spammers and flooders and email spammers were doing it. The new uses to which this is being put are news, but DNS poisoning is not. IIRC, the icq.net servers were so compromised after having been bought out by AOL and put to new use.

    I'm betting there's still a problem with admins that don't want it fixed, because they have given permission, or worse, for their servers to be used thus with some plausible deniability. Arranging this was the origin of the second-gen spammers.
    • The 1999-2000 era of DNS poisoning focused on exploits. Then we had Kashpureff force the hand of BIND to implement all that complex bailiwick verification stuff, so a query for foo.com couldn't return glue for google.com (though the protocol really wants you to be able to do that). The recent stuff focuses on a situation where bailiwicks are ignored, i.e. forwarders. It was considered to be an obscure situation...I had NO IDEA there was so much forwarding going on.

      --Dan
  • The news.com article is short on specifics about what the thousands of servers are actually doing, but there's better info at Dan Kaminsky's site: http://www.doxpara.com/ [doxpara.com]

    This powerpoint presentation has some details: http://www.doxpara.com/Black_Ops_Of_TCPIP_2005.ppt [doxpara.com]
  • The internet license (Score:5, Interesting)

    by erroneus (253617) on Thursday August 04, 2005 @03:30PM (#13243328) Homepage
    I think there should be an internet user license program. I know it smells like some way of identifying people and all that, but it doesn't have to be any more than a driver's license does at present.

    I'm thinking of something along the lines of a radio operator's license with different levels and qualifications and all that. Then people who are said to be administrators of web hosts and stuff like that would be required to posess a certain level of knowledge (and potentially a certain level of pay?) and ability. If it is shown that they do not demonstrate the proficiency required for some reason, then their license should be revoked or downgraded.

    Furthermore, certain levels of internet "safety" and "security" ratings should be given to all software, firmware and hardware products that run on the public internet. The consumers can be better aware of the quality of the products they use on the internet. (Examples might include a rating for MSIE having a lower security rating than Firefox because of that whole ActiveX thing... or a Linksys firewall/router giving the users behind it a certain rating of security over a Windows box connected directly to the public internet.)

    Not only would we be able to leverage these sorts of licenses and ratings to have a better and safer internet, but we would be able to have a more conscious set of consumers who just might be able to look at the label to determine that product A is better than product B. They will no longer need to get an education in how the internet works just to get their home computers on the net... and we'll be less likely to deal with all those spambots and zombies out there as well.
    • HAHAHAHAHAHAA... good luck on getting all sorts of foreign countries to adopt this theoretical licensing system.
    • internet user license program

      I agree. I'd like to nominate Microsoft to make this happen. But lets instead of having an arbitrary license, tap this into DRM! That way, our DRM-enabled trustworthy computers will be allowed to install/run certain types of trusted apps depending on the DRM-based license of the operator.

      Of course, we won't have un-trustworthy computers *cough*everything non-Windows Vista*cough* on this new world order Internet because well.. that would just screw everything up. And pigs will fl
    • Well, lets see. First, you need to completely break backwards compatibility with the entire existing Internet infastructure for that to work (or else people will circumvent it trivially -- "Sorry, this user is running an obsolete client"). Oh, and spend many billions or trillions doing it, depending on which protocols exactly you want to reengineer (TCP/IP? Saves you the trouble of having to rewrite every application but you'll have to rewrite every network driver... Application layer? Congratulations,
  • Today I received a standard phishing email, except this one was different in one important way. The link to "please to update your details" went to http://www.paypal.com/ [paypal.com] (not even any i18n tricks in there). I thought maybe the spammer had made a mistake, but after reading this, it all falls into place.
    • by 3l1za (770108)
      So you're thinking of a slight variation on the canonical DNS cache poisoning theme:
      1. Victim gets email (allegedly from user@target.com--doesn't really matter) containing link to www.target.com
      2. Victim clicks on link and in response victim's local name server send a query for www.target.com
      3. Malicious guy interposes and spoofs a response to victim NS query: saying "I'm www.target.com and here is my [fake] IP"
      4. Then victim connects to fake IP (spoofed paypal site)

      So that really describes a timing attack on nam

      • I was thinking another spam message may have been involved, to trigger the poisoning. I get dozens per day with tracking images that my client refuses to render.
  • The DNS cache poisoning has been reported long time ago by Jon Lasser from Security Focus Online. As a response to that i created this page :

    "Secure Bind 9 Example"
    http://crashrecovery.org/bind9.html [crashrecovery.org]

    Robert

Mathemeticians stand on each other's shoulders while computer scientists stand on each other's toes. -- Richard Hamming

Working...