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

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

  2. Why do people still use BIND? by Mr.Ned · · Score: 1, Insightful

    Why do people still use BIND? It has a track record of security vulnerabilities almost as long as Sendmail's.

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

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

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

  6. 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?)