Slashdot Mirror

← Back to Stories (view on slashdot.org)

BIND Still Susceptible To DNS Cache Poisoning

Posted by Soulskill on from the still-in-a-bind dept.

An anonymous reader writes "John Markoff of the NYTimes writes about a Russian hacker, Evgeniy Polyakov, who has successfully poisoned the latest, patched BIND with randomized ports. Originally, the randomized ports were never supposed to completely solve the problem, but just make it harder to do. It was thought that with port randomization, it would take roughly a week to get a hit. Using his own exploit code, two desktop computers and a GigE link, Polyakov reduced the time to 10 hours."

32 of 146 comments (clear)

  1. IPv6 could solve this! by jamesh · · Score: 4, Insightful

    With IPv6, you would have enough source addresses to add that to the 'random pool' too. Another 64K addresses would make it harder to hack.

    Does anyone else think that maybe we are approaching this problem the wrong way?

    1. Re:IPv6 could solve this! by diegocgteleline.es · · Score: 3, Insightful

      Another 64K addresses would make it harder to hack.

      You said it, it'd make it harder, but not impossible, specially with hardware geting faster every year.

    2. Re:IPv6 could solve this! by Niten · · Score: 3, Informative

      Does anyone else think that maybe we are approaching this problem the wrong way?

      Yes, the wrong way being tacking on extra transaction ID space by means of fragile kludges such as random source port numbers and, possibly, random IPv6 addresses.

      It will require a lot more effort, but the right way to solve this problem is by improving the protocol itself. That may mean putting a much larger transaction ID field in the packets, where it cannot be mangled by NAT devices. Or it may mean delegating nameservers by IP address rather than domain name so that resolvers will no longer need to accept potentially-malicious glue records. But preferably, it means moving to a cryptographically-strong domain name system such as DNSSEC.

    3. Re:IPv6 could solve this! by Paul+Jakma · · Score: 2, Informative

      Or it may mean delegating nameservers by IP address rather than domain name so that resolvers will no longer need to accept potentially-malicious glue records.

      Good post. Forgive me for focusing in on this one point and nitpicking it.. ;)

      0. Glue used to have a specific meaning: records configured in a parent to help delegate a zone. You (and many people reporting on the current flaws) seem additionally to use it to refer to "additional answers" in DNS replies. While such answers often are glue records, they're not quite the same thing. Least, it didn't use to be. Perhaps the meaning has moved on, but I'll use "glue" in the stricter sense.

      1. That's essentially already the case, for in-zone delegations (ie delegating example.com to a name in example.com. like ns.example.com.). The authorative server must be configured with glue, and it must return that glue in the additional answer section for anyone to be able to query ns.example.com.

      (Interestingly, DJB has long had a page arguing that "out-of-bailiwick" delegations are bad, amongst other things).

      2. Resolvers mustn't treat glue from the delegator as authorative anyway. Resolvers are only supposed to believe additional answers that are in-bailiwick (ie you'll only believe an additional record for/in example.com. if it came from a DNS server you know to be authorative for example.com., e.g. cause you just queried it for a name in example.com.)

      3. The problem here is not inherent to glue/additional, but in knowing whether a reply is authorative or not. The only good way to fix this is to secure the DNS chain of trust, either through near-ubiqutious deployment of IPSec+PKI for DNS servers (ha!) or a PKI inside DNS.

      --
      I use Friend/Foe + mod-point modifiers as a karma/reputation system.
    4. Re:IPv6 could solve this! by Antibozo · · Score: 2, Informative

      The third party hierarchical trust you disdain is one of the primary benefits of DNSSEC, because DNSSEC can eventually replace certificates for distribution of public keys. Currently, the only PKI we have is from a third-party non-hierarchical trust—the CAs—who are really not that trustworthy. DNS, however, is already hierarchical, and it makes a lot more sense to use a hierarchical system of trust—the same system in fact—to validate it. Do you really think having hundreds of trust anchors makes more sense than having a single trust chain?

      What hampers DNSSEC, more than anything, is all the FUD about it. It's really not difficult to implement, and there are tools for nameserver operators to use. If people would start actually practicing signing domains, even without the trust chain, a lot of their fears would be allayed. What is technically standing in the way is the failure to plan for it on the part of the major registrars, who need to provide a mechanism for signing the DS records. Of course, a lot of those those registrars also happen to make a lot of money on the side as CAs, and one of them in particular also operates the .com and .net TLDs. You do the math—who benefits the most both from FUD about DNSSEC and from the insecurity of traditional DNS?

      People need to set aside their paranoia about DNSSEC and understand that the worst case, most fantastical, trust violation scenarios for DNSSEC are still better than the status quo. And the best case is that everyone ends up with ubiqitous PKI with no per-unit cost. You could securely publish all your public keys, ssh host keys, personal public keys, etc. for the simple cost of getting a domain. If people can start seeing the possibilities for a single distributed, redundant, hierarchical, secure network database, there will be more community pressure on the registrars to get with the program. ICANN already plans to have a signed root by the end of the year and there are several ccTLDs that are already signing their zones. What excuse do we have for not even having a plan for .com? It's infuriating that we are facing the current situation, after all these years, and people are still questioning whether DNSSEC is a good idea.

    5. Re:IPv6 could solve this! by jamesh · · Score: 2, Insightful

      I meant the source address of your request. Eg when your internal dns caching server sends a dns request, your router nat's the source address from a random pool of 64k (or more) addresses. In order for someone to spoof the reply, they would need to know the dns request id, the source port you used to send, and the source IP address chosen by your nat router. It's a client side solution only.

      As a solution, it would rely on the following:
      . a useful number of DNS servers being reachable via IPv6 (not the case yet)
      . a router able to do IPv6 NAT to a random address (maybe possible if your router runs Linux?)

      I think that by the time the above is true, there will be better solutions around.

    6. Re:IPv6 could solve this! by jamesh · · Score: 2, Informative

      DNS does already work over TCP, and is used where the response will be over a certain size, eg a zone transfer from primary to secondary DNS server.

      The problem is one of efficiency. TCP has much higher overheads, you need three packets just to get a connection started and then you have to keep track of the connection and shut it down properly. Three packets doesn't sound like much but over a high latency link (eg 500ms) it makes for a huge increase in the time it takes to resolve a name.

    7. Re:IPv6 could solve this! by Znork · · Score: 2, Informative

      who are really not that trustworthy.

      I generally don't trust the CA's further than I can throw them. Who do you figure is trustworthy enough to handle it for DNS? Who could be regarded as trustworthy, no matter who in the world you ask? There seems to be some administrative problems with handing the keys to Mother Theresa.

      hundreds of trust anchors

      Having trust anchors at all is the problem. You need to verify against several independent sources, preferably sources you have some reason to trust, to avoid single points of corruption.

      Designing a system based on a single point not failing is simply bad engineering. You design with the expectancy that individual points _will_ fail, but minimizing the consequence of the failure of any such points.

      secure network database

      It's spelled _in_secure.

      I certainly see the possibilities for what you want to be talking about. DNSSEC isn't it.

      and people are still questioning whether DNSSEC is a good idea.

      Ok, here's a hint. If you've failed to convince people that DNSSEC is a good idea after this many years, and with the current (and, many would argue, since a long time ongoing) DNS situation, it should really, I mean, _REALLY_ tell you something. Maybe the problem is in the actual idea.

      It's not like it's hard to come up with a list of options to improve and design a naming system to be redundant, fault tolerant, intervention tolerant and secure, yet there's an apparent fixation of going with a system that has obvious flaws. Numerous suggestions to fix the flaws that made the latest round of problems obvious have been made in the past, yet the push continues.

      Why not actually sit down and redesign in a distributed way that would be acceptable to all parties? I mean, how bad does it have to get? DNSSEC gets bogged down in political and paranoid issues because DNSSEC has political issues designed into its core. It caters to the paranoid by ensuring there is plenty of opportunity to make paranoids right.

      When you reach insurmountable political issues you design around them. Maybe they'll go away in some utopian future when we'll have utterly secure trust anchors in the hands of incorruptible angels, but until then we could do well with a system that doesn't require unobtainable dreams to work.

    8. Re:IPv6 could solve this! by Antibozo · · Score: 2, Informative

      I generally don't trust the CA's further than I can throw them.

      Yet, they are the current standard for providing end-to-end security. So how mainstream to you think your level of doubt is?

      Mind you, I don't trust the CAs either, which is why I want DNSSEC, since it can provide a superior mechanism with far fewer vectors for subversion, which I can control for my own domains, and which also is not vulnerable to cache poisoning.

      Who do you figure is trustworthy enough to handle it for DNS? Who could be regarded as trustworthy, no matter who in the world you ask?

      I would trust ICANN for the root. Obviously, you can't please everyone in the world, nor do you have to. For the TLDs, the current gTLD registry operators also happen to be CAs, so they can subvert both DNS and SSL already. Have you ever heard of a case of a CA subverting SSL security by deliberately issuing a false cert?

      Having trust anchors at all is the problem. You need to verify against several independent sources, preferably sources you have some reason to trust, to avoid single points of corruption.

      Yes, those independent sources are called "trust anchors". From your somewhat vague statement I presume you mean you'd like to make your trust anchor some form of composite, perhaps a web of trust of some kind. So then it would require some form of conspiracy to subvert the trust anchor. And you think that's superior to having a single trust anchor, which would require some form of conspiracy to subvert it.

      And how do you propose that Joe User assess whether the DNS answer he gets is trustworthy in such a system, let alone come up with an initial set of trust anchors for his web of trust?

      Designing a system based on a single point not failing is simply bad engineering.

      Again you are vague; it's unclear what single point would fail in DNSSEC. Presumably the scenario you have in mind would be the root or TLD operators' subverting DNSSEC. Do you really think that's a plausible scenario? If so, why isn't it happening already with the CAs, any one of which could accomplish the same thing. Again, some CAs are also TLD operators, and many more of them can subvert DNS. Yet we don't have any evidence that this has happened.

      It's spelled _in_secure.

      That's your argument? Wordplay?

      Maybe the problem is in the actual idea.

      Or maybe the problem is in the FUD that people keep promulgating about the idea.

      It's not like it's hard to come up with a list of options to improve and design a naming system to be redundant, fault tolerant, intervention tolerant and secure, yet there's an apparent fixation of going with a system that has obvious flaws.

      Really? If it's so easy, let's hear your design.

      Of course, it's easy to claim that designs have obvious flaws without presenting actual examples. Would you care to describe these obvious flaws in DNSSEC? What vulnerabilities exist, what are the plausible threat models, and how do those threat models compare to those of the status quo, or the easily designed system you have in mind?

      DNSSEC gets bogged down in political and paranoid issues because DNSSEC has political issues designed into its core. It caters to the paranoid by ensuring there is plenty of opportunity to make paranoids right.

      If deploying SSL had required proving to all the tin-foil hats in the world that CAs wouldn't be able to subvert the security of the system (of course, they are), it never would have gotten off the ground. Would you have the designers cater to every marginal threat in order to design a system that would be unwieldy beyond measure, impossible for a regular user to understand, and which still fails to provide perfect security?

      When yo

  2. You Will Never Solve This Problem! by segedunum · · Score: 4, Insightful

    I might not have one of the lowest Slashdot IDs around, but I am absolutely astonished at some peoples' astonishment over this. DNS, by definition, is all about trusting the forwarders you are using or other DNS servers you are caching from and trusting the DNS server you use from there. That's where the problem is, so if people are shouting and screaming about trust now then it's all a bit late.

    If your DNS server says that slashdot.org resolves to something other than 216.34.181.45 then that's where you're going to end up. There are also legitimate reasons why someone might want to do something like that, and it is part of the inherent flexibility that has made the internet and its technologies as ubiquitous and as well used as they are. No one said that there weren't downsides. If you locked everything down in the manner that some idiots will inevitably now talk about, shouting and squealing about financial institutions, then I'm willing yo bet that you will lose a good portion of the flexibility that makes the 'internet' actually work on a wide scale.

    1. Re:You Will Never Solve This Problem! by gruntled · · Score: 2, Interesting

      Isn't the real issue here our continued reliance on passwords that can be used more than once? When are we going to move wholeheartedly into a single-use password environment?

      Incidentally, when is somebody going to throw the fact that US banks have completely ignored the two-factor authentication requirement (part of the Patriot Act, I believe; maybe we should start sending *bankers* to Gitmo and see if *that* gets their attention) back at the finance industry when they start to squeal?

    2. Re:You Will Never Solve This Problem! by boto · · Score: 3, Insightful

      I wonder why the parent is modded Insightful. You don't seem to have gotten the problem.

      The problem is not the servers being able to redcirect you to a different address, but the fact that any person (not only the people that control the servers you query) can make you server direct people to anywhere.

      The problem is not about trust, but not being able to make sure who you are really getting a message from. You can't even have a trust problem if you are not sure who is talking to you.

  3. Re:Why do people still use BIND? by PJCRP · · Score: 2, Funny

    Because most Networkers engage netorking-BDSM in regular practice?

    --
    Knows everything about nothing and nothing about everything.
  4. GigE by AndIWonderIfIWonder · · Score: 2, Interesting

    It seems that this only works so quickly because he had 2 machines connected to the server via GigE. Which I would guess means most DNS servers can't be poisoned like this.

  5. This isn't a BIND problem. by CustomDesigned · · Score: 5, Informative

    This has nothing to do with BIND vulnerabilities. DJdns, or whatever you feel is more secure, has exactly the same problem. It is a protocol weakness. The article mentions BIND only because it is the reference implementation for DNS.

    The most interesting idea I've seen is to use IPv6 for DNS. The oldest idea is to start using DNSSEC.

    1. Re:This isn't a BIND problem. by CustomDesigned · · Score: 3, Insightful

      Since the basis of the attack is spoofing server IPs, how does DJBDNS detect spoofed packets? "only come from defined servers" is useless when the packets are spoofed. It helps, of course, to not accept new glue records whenever they appear, but keep existing ones until they expire. But this just makes the attack take a little longer.

    2. Re:This isn't a BIND problem. by Anonymous Coward · · Score: 5, Informative

      The basis of the attack is to include "extra" information in a forged response to a query for a non-existent host. Bind trusts that extra information and other DNS servers only pay attention to that information if it falls under certain strict rules.

      I ask for aaaae3fcg.bankofamerica.com and also send 100,000 responses to that query to that same recursive DNS server, that all say something to the effect of "a record aaae3fcg.bankofamerica.com = bah, also look to 666.666.666.666 for anything else related to bankofamerica.com. Oh, and cache this until the sun goes dark"

      Nobody asks Bind to believe the part about THE REST OF THE WHOLE BLOODY DOMAIN in the response for a single record in the domain. No other servers cache that information.

      That bind also used non-random ports made it a 5 minute attack over a fast link, instead of a 10 hour attack. That in the past bind used bad random numbers for the transaction ID made it a 30 packet attack...

      Who's the fanboy now?

    3. Re:This isn't a BIND problem. by Anonymous Coward · · Score: 2, Interesting

      It does not make the attack take "a little longer". It makes cache poisoning take as long as it took before the new attack method. If you only get a chance to poison the cache once whenever the cache purges the target record, then you have to guess the transaction ID correctly on the first try. The new thing about the current attack is that you get as many tries as you want at guessing transaction IDs and port numbers. That only works because servers allow glue to replace already cached records.

      Port randomization makes it less probable that you guess right, but since you can guess hundreds of times per second, you'll eventually succeed at poisoning the cache. If the server only accepted glue records when it doesn't already have the information cached, then you could only guess once per TTL.

    4. Re:This isn't a BIND problem. by Anonymous Coward · · Score: 3, Informative

      Not all dns servers cache the glue records beyond that transaction. Those that don't *cache* the glue are not vulnerable to this attack.

  6. Isn't it a birthday attack? by Timothy+Brownawell · · Score: 2, Interesting

    Why can't the resolvers make sure to never have multiple outstanding requests that could potentially give the same answer? Check the cache for known zone boundaries and implied non-boundaries (if the server for foo.com also answers requests for x.y.z.foo.com, there's no zone boundary in between), and only send one request crossing a particular potential boundary at a time to a particular server (like a.c.foo.com and b.c.foo.com, we don't know yet that .c.foo.com is answered by the same server as .foo.com, since nothing under that domain is in the cache).

  7. Limit the bandwidth, compare notes by CustomDesigned · · Score: 3, Insightful

    The exploit depends on a GigE connection to the DNS server. So a caching server behind a T1 is going to take much longer to exploit. So running your own caching server on a T1, DSL, or cable is going to be more resistant than using the ISP DNS with a fat pipe.

    If there is actually 1 GigE of DNS traffic at an ISP, they could distribute the requests to 100 bandwidth limited servers. Then the attack would only manage to poison one of the servers in 10 hours. Even more interesting would be if the 100 servers could compare notes to detect the poisoning.

    1. Re:Limit the bandwidth, compare notes by Tony+Hoyle · · Score: 3, Insightful

      A decent firewall could be trained to recognize an attack like this take preventative action easily enough - to even get it to work you'd have to saturate the link with packets hoping to get a 'hit'.. So you can do it in gigE in 10 hours. You can attack just about any connection based system using similar methods, but you'd have to saturate the link and it'd get noticed... especially if you did it at gigE bandwidth for 10 hours!!

    2. Re:Limit the bandwidth, compare notes by Tony+Hoyle · · Score: 2, Insightful

      The packets won't look like that though will they - at that bandwidth they'd have to be on the local network so they'd be coming from a different source mac (and that's pretty much the only way to do this attack anyway - any ISP worth the money will drop any packets with fake source addresses on the floor before they get routed externally, so it'd have to be an internal attack).

      Worst case you shut down the DNS server and everyone drops to the backups until the attacker is traced and shut down.

  8. Re:BIND by MrNaz · · Score: 4, Funny

    I think you mean B0wnd

    --
    I hate printers.
  9. Re:Power DNS Recursor.. by shallot · · Score: 4, Informative

    % apt-cache -n search pdns-recursor
    pdns-recursor - PowerDNS recursor

    Granted, it *is* actually missing on several architectures because of some unimplemented system calls, but that shouldn't bother too many people.

  10. Re:I guess it's time... for Secure DNS by mibh · · Score: 4, Insightful

    It's long past time for Secure DNS, which is a combination of TSIG+TKEY, SIG(0), and DNSSEC. End to end crypto authentication. Protects not just against off-path spoofed-source attacks like Kaminsky's, but also on-disk attacks against zone files, and provider-in-the-middle attackers who remap your NXDOMAIN responses into pointers to their advertising servers.

    Sadly, it's a year away even if everybody started now, and most people want to be last not first, so very few people have started, and some of those people are saying "why bother, if it's not an instant solution there's no point to it, let's scrap the design and start over." (Had it not taken 12 years to get Secure DNS defined, then the prospect of doubling that time would not daunt me as much as it does.)

    So, everybody please start already. NSD and Unbound from NLNetLabs supports DNSSEC. So does BIND, obviously. Sign your zones, and if your registrar won't accept keys from you, send them to a DLV registry while you wait for that. Turn on DNSSEC validation in your recursive nameservers. Write a letter to your congresscritter saying "please instruct US-DoC to give ICANN permission to sign the root DNS zone." In the time it would take for this Russian physicist's attack to work over your 512K DSL line (2.2 years, I heard?) we could completely secure the DNS or at least the parts of DNS whose operators gave a rat's ass about security (which is not the majority but it certainly includes your server, right?)

  11. DJB's take . . . by geniusj · · Score: 5, Informative

    For those that haven't seen it, djb threw up some information regarding this problem and various options a few years ago.

    http://cr.yp.to/djbdns/forgery.html

    1. Re:DJB's take . . . by vic-traill · · Score: 2, Informative

      For those that haven't seen it, djb threw up some information regarding this problem and various options a few years ago.

      http://cr.yp.to/djbdns/forgery.html

      I went and had a look at the thread (dated from Jul 30 2001) referenced in the excerpt at djb's site (follow the posting link in the URL above). As far as I can tell, Jim Reid was pooh-poohing the usefulness of port randomization, the approach used as an emergency backstop against Kaminsky's attach just over seven years later. To be fair, Reid was doing so in the context of advocating for Secure DNS.

      djb drives people crazy (particularly the BIND folks), but he's someone to listen to - is it the case, as I understand from reading through these docs, that in 2001, djb's dnscache performed the port randomization that everyone's been scrambling to deploy over the past several weeks for other implementations, including BIND?

      Or am I mis-interpreting here?

      --
      [17] Leary, T., White, C., Wood, P. R., Bhabha, W. D., and Wirth, N. Lambda calculus considered harmful. In Proceedings
    2. Re:DJB's take . . . by Maniacal · · Score: 2, Informative

      Here's something DJB posted to his mailing list on Thursday. Don't know if I'm allowed to post this here but what the heck:

      http://cr.yp.to/djbdns/forgery.html has, for several years, stated the results of exactly this attack:

            The dnscache program uses a cryptographic generator for the ID and
            query port to make them extremely difficult to predict. However,

            * an attacker who makes a few billion random guesses is likely to
                succeed at least once;
            * tens of millions of guesses are adequate with a colliding attack;

      etc. The same page also states bilateral and unilateral workarounds that would raise the number of guesses to "practically impossible"; but then focuses on the real problem, namely that "attackers with access to the network would still be able to forge DNS responses."

      I suppose I should be happy to see public awareness almost catching up to the nastiest DNS attacks I considered in 1999. However, people are deluding themselves if they think they're protected by the current series of patches. UIC is issuing a press release today on this topic; see below.

      ---D. J. Bernstein, Professor, Mathematics, Statistics, and Computer Science, University of Illinois at Chicago

      DNS still vulnerable, Bernstein says

      CHICAGO, Thursday 7 August 2008 - Do you bank over the Internet? If so,
      beware: recent Internet patches don't stop determined attackers.

      Network administrators have been rushing to deploy DNS source-port randomization patches in response to an attack announced by security researcher Dan Kaminsky last month. But the inventor of source-port randomization said today that new security solutions are needed to protect the Internet infrastructure.

      "Anyone who knows what he's doing can easily steal your email and insert fake web pages into your browser, even after you've patched," said cryptographer Daniel J. Bernstein, a professor in the Center for Research and Instruction in Technologies for Electronic Security (RITES) at the University of Illinois at Chicago.

      Bernstein's DJBDNS software introduced source-port randomization in
      1999 and is now estimated to have tens of millions of users. Bernstein released the DJBDNS copyright at the end of last year.

      Kaminsky said at the Black Hat conference yesterday that 120,000,000 Internet users were now protected by patches using Bernstein's randomization idea. But Bernstein criticized this idea, saying that it was "at best a speed bump for blind attackers" and "an extremely poor substitute for proper cryptographic protection."

      DNSSEC, a cryptographic version of DNS, has been in development since
      1993 but is still not operational. Bernstein said that DNSSEC offers "a surprisingly low level of security" while causing severe problems for DNS reliability and performance.

      "We need to stop wasting time on breakable patches," Bernstein said. He called for development of DNSSEC alternatives that quickly and securely reject every forged DNS packet.

      Press contact: Daniel J. Bernstein

      --
      MG
  12. Re:Power DNS Recursor.. by bconway · · Score: 4, Informative

    Consider reading the links in the article. Obfuscation isn't a fix.

    Article says, that DJBDNS does not suffer from this attack. It does. Everyone does. With some tweaks it can take longer than BIND, but overall problem is there.

    --
    Interested in open source engine management for your Subaru?
  13. Re:32 bit guess vs. 16 bit guess. by LarsG · · Score: 2, Interesting

    This isn't an attack one could run against a client out on a DSL line, but if you were able to take over one machine in a colo, you might be able, over time, to get traffic for other machines directed to yours.

    True. On the other hand, if you are on the same network segment then there are many other options available to you if you want to do evil. Blasting about 4 terabytes (1 Gb/s for 10H) at a DNS server isn't exactly a quiet attack, so if you intend to stay below the radar you're probably a lot better off trying some good old arp spoofing or tcp hijacking instead.

    --
    If J.K.R wrote Windows: Puteulanus fenestra mortalis!
  14. Re:I'm safe, in my ADSL utopia by Lennie · · Score: 2

    It depends ARP spoofing is just confined to the broadcast-domain (possible a VLAN), while a DNS-server probably is used by a much broader 'audiance'.

    --
    New things are always on the horizon