Patched DNS servers still vulnerable to cache poisoning
But the sky won't fall just yet
Customer Success Testimonial: Recovery is Everything
Large swaths of the internet remain at risk from a potentially crippling vulnerability in the net's address lookup system even after installing emergency patches, a researcher has warned.
Russian researcher Evgeniy Polyakov posted exploit code here, which he says allowed him to poison domain-name system servers running the most recent version of the Berkeley Internet Name Domain (BIND), the most popular software for translating domain names into numeric IP addresses. The attack, which poisons the records of domain-name system servers with incorrect information, could allow criminals to silently redirect millions of users to fraudulent websites that attempt to steal login credentials or install malware.
Researchers who spearheaded an international push to get internet service providers and other large organizations to patch the flaw said they weren't terribly concerned about the exploit code. That's because Polyakov's attack took 10 hours to carry out using two machines connected directly to the targeted DNS server via a gigabit ethernet link.
"That's a little different then spending 10 seconds over the internet," to carry out an attack, said Dan Kaminsky, the researcher who first warned of the DNS cache poisoning vulnerability.
The original attack works by flooding a DNS server with thousands of requests for domains with slightly different variations, 1.google.com, 2.google.com, 3.google.com and so forth. That allows attackers to gain a secret transaction number needed to trick other computers into updating their records with IP addresses that lead to rogue websites.
Successful attacks took seconds to carry out using 10-megabit connections. The patch to BIND and other DNS programs randomizes the source ports used, vastly reducing the odds an attacker will gain the transaction credentials.
"We have successfully made the attack significantly less likely to occur in the real world," Kaminsky told The Register. "That doesn't mean the defense is perfect." He said the patch should be thought of as a "stopgap" until more thorough changes can be made to the net's DNS.
So a word to the Googles, Microsofts and Ciscos of the world: You dodged a bullet in surviving the Kaminsky bug with nary a scrape, but next time you may not be as lucky. Forging a real fix won't be easy, but it's essential. Time to get cracking. ®
COMMENTS
@TCP
"Another option would be to rework DNS to use TCP rather than UDP."
That would make DNS really suck. No thanks. Besides, if you are going to change the lower layer protocol, why not use something that's more reliable and faster: SCTP.
Or add a slow-down to reduce the risks further
Insert a Load Balancer, and ensure round-robin is used on the farm or caches. Now its incredibly difficult to doing poisoning. Go to Starbucks.
Protocol is the issue
You've got a 16-bit transaction ID and (with DJBDNS and now, with BIND) a 16-bit port. That's 32 bits of entropy now, which is why it's taking 10 hours over a fast line on average now, rather than the few seconds required for 16 bit of entropy provided by just the ID.
There's no more entropy to squeeze out of the existing protocol, so if 32-bits isn't enough and you don't fancy DNSSEC how about modding your caching nameserver to make each request twice and compare both results to ensure they're the same?That's 64-bits of entropy, and I imagine it's an easier upgrade path than DNSSEC - a few extra packets isn't as much of an issue as it was 10 years ago.
IT infrastructure monitoring strategies
What you need to know about cloud backup
Agentless Backup is Not a Myth
Top 10 SIEM implementer’s checklist
Customer Success Testimonial: Recovery is Everything
