Slashdot Mirror
BIND Still Susceptible To DNS Cache Poisoning
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."
Much better program, and faster recursion..
wheres the problem?
Russian hacker, Evgeniy Polyakov
a Russian physicist
Which one which one aaaaaarhhhhh I'm so confused.
BOUND
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?
Why do people still use BIND? It has a track record of security vulnerabilities almost as long as Sendmail's.
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.
The effectiveness of the attack in the presence of port randomization is equal to the amount of tries you can make per second.
On a GigE, port randomization has a much lower effect, just because you are throwing even more packets per second at the target server.
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.
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.
So, if you have a GigE lan, any trojaned machine can poison your DNS during one night...
People at home are safe though - that's the main thing. People on the local net at home are generally known people, with access to your house (WiFi excepted), and could probably find easier ways to steal your identity, capture keystrokes, etc. And you're safe from Internet people too - at the end of my 8Mb connection, I think I'd notice a Gb of traffic heading my way, to say nothing of it taking 125 times longer anyway.
Get your own free personal location tracker
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).
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.
Some universities provide students (and others) on their network extreme fast links. Think of the fun of hijacking your fellow students DNS queries.
So, the Internet at large is safe (at least as safe as before) until most computers are connected with gigabit links?
-- Sig down
Good thing my ISP (TM Net/Streamyx) sucks eh? They're not even giving me the 512kbps I paid for.
;).
;) ). So I'm not sure if the attack might work as well.
Let's see 10 hours * 1Gbps / 512kbps = 2.22 years.
If you have a 10Mbps link that makes it 41 days.
I think I would have made a dns request and got the valid dns reply into my cache before the 2 years are up. Or my connection would have gone down and I'd get a different IP by then. Thanks to TM Net for protecting me from such attacks
Either that or I'll be safe because the site would have DoSed me off the net with the flood of udp packets at 1Gbps...
BTW I'm using djbdns (any bets on whether my ISP would have patched their nameservers already?
I am not an expert on the problem.
Is it possible that configuring cache timeout on the DNS server to be significantly less than the non trivial attack time might avoid the problem?
I assume once cache is poisoned that that poison does eventually timeout in the cache unless the attack is continuous?
for DNSv2.
(whatever that means)
I'm not surprised. Port randomization doesn't make the attack impossible, just harder. It doesn't eliminate the birthday attack, it just increases the space you have to blanket to generate a collision. The only real fix for the attack is DNSSEC, allowing the software to reject forged responses completely. Short of that, I can only think of two more things that'd help:
These don't completely close down the attack, but I can't think of anything else that makes it harder short of having responses cryptographically signed and the signature verified as coming from the expected source. We need to start pounding on domain owners to implement DNSSEC. Yes, that's work. Yes, it's neccesary.
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?)
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
or when updating your cache, compare with your cached copy, and if different ask again to double check.
That is the best idea I've heard yet.
Right. Before the fix, you had to guess a 16-bit number. After the fix, you have to guess a 32-bit number. About 10 hours on a gigabit Ethernet should let you try the necessary 4 billion packets. 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.
If DNS used a 64-bit or 128 bit number to tie the response to the request, and the DNS client had a crypto-grade random number generator, guessing would be hopeless. An intermediate technical fix would be to define a "DNSv2" message format, with a 128-bit random message ID and a rule that no DNSv2 client will accept an answer to a question it didn't ask. (Some of the attacks depend upon an attacker forcing a query for "1245.example.com", which won't be found, and a phony DNS blindly blasting replies with random IDs for "www.example.com", which is accepted because it's in the same "bailiwick".) If everybody other than desktop clients went to an improved DNS, and desktop clients talked only to an improved server, we'd be reasonably OK.
DNSSEC, which has a whole signed-certificate chain like SSL, may be a way out of this, but it's much more complex than the existing DNS.
Thanks for beating me to the punch. As stated in the CERT KB article at http://www.kb.cert.org/CERT_WEB%5Cservices%5Cvul-notes.nsf/id/800113, "It is important to note that without changes to the DNS protocol, such as those that the DNS Security Extensions (DNSSEC) introduce, these mitigations cannot completely prevent cache poisoning." So DNSSEC is a viable solution.
Additionally, the folks at Emergingthreats.net are re-writing the Snort DNS preprocessor to detect DNS cache poisoning attacks on cryptographically-weak session IDs. http://www.emergingthreats.net/content/view/90/1/
Perhaps now is a good time for ISPs everywhere to start doing egress filtering? There is NEVER a good reason for a forged IP address to leave a network.
Especially the TLDs. Very few TLDs have DNSSEC which would make this attack practically impossible. IPv6 would allow for more source addresses as well, which is discussed in the link below. If you run a recursive resolver I highly advise using Unbound. It is the most secure resolver I know of and has an incredible amount of thought put into it (without BIND's bloat). It has many provisions for DNSSEC-less zones. See: http://www.unbound.net/documentation/patch_announce102.html
I see many options as potential to limit the security risks. 1) DNS moves to TCP only, the negative side to this, DNS becomes slower. 2) A simple solution, might be to modify the resolvers, so they resolve from multiple sources, and compare the responses. These could both be from the same server or from companion servers in the same network. 3)Add a token to the DNS query. This could be done via a hash with the hostname and a salt. 4) Single level Recursion, each level will only request from an upstream dns server, allows for limiting access, but requires a complete overhaul of the DNS infrastructure. 5) DNSSEC
People who are interested in signing their zones may want to read up on how things work at www.dnssec.net and take a look at the Sparta tools. It's really not difficult, and there is a lot of information out there.
If this happened to my DNS servers, I don't think I'd even notice it as poisoning right away. I'd likely just assume it was a DoS attack and deal with it accordingly. I also have my DNS servers on 100 Meg ports so unless I were on vacation, I'd likely notice it long before the cache got poisoned.
I'd just like to point out that GigE connections are becoming more and more available. Most corporate networks that are being built, or upgraded are being built with GigE to the desktop. Granted, most are set to 100k, but all it takes is one non-so-tech-savvy manager that demands er..."requires" GigE be turned on for his desktop, to be infected by spyware / some random virus.
The rest of the story will be blamed on the DNS administrator.
while (1) {
for (i = 0; i < port_range; i++) {
PoisonDNSCache(i);
}
}
What would break if you ignored additional DNS entries that changed IPs of entries already present in the cache and instead set the TTL of the entry to something low? That way it you'd stop poisoning of anything anyone cared about, but you'd still provide a way for DNS changes to propagate faster than the originally set TTL would allow for. You might have to combine that with a counter to stop denial of service attacks, but that wouldn't impact too much on legitimate traffic.
A couple of questions for experts:
1) Would the use of TCP instead of UDP solve this problem? Besides the (quite huge) protocol overhead and adoption, what are the main issues?
2) Could this be solved by temporarily (e.g. 30 sec) rejecting packets from a nameserver which already resolved N (e.g. 8) NXDOMAIN's for a single domain thus slowing down the attack? Does the RFC is allow this?
Why not have the DNS server check for flooding?
Basically when DNS poisoning is done you'll be sending thousands of fake/false packets that the DNS server receives and then ultimately rejects until one slips through because it guessed the correct ID/source port.
If the DNS server were to count the number of false/wrong packets from each source address, it would quickly detect when something is wrong. It could then just reject all packets from this IP and perhaps use a secondary DNS server for the specific domain. Or it could send the request to another DNS server which isn't under attack.
Wouldn't that just fix the entire issue and get this stuff over with?
DJB made a press release about this:
---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.
{{.sig}}
Sure, because nobody is going to notice a gigabit of traffic pouring into their DNS server for 10 hours in order to get -just-one- cache poisoning.
Sorry, but this extension of the attack is simply unworthy of mention. What is worthy of mention is the danger posed by corporate NAT boxes that reorder the source ports sequentially, defeating randomization.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.