DNS hacked again with poisoning attack

DNS hacked again with poisoning attack
DNS hacked again with poisoning attack 

By Roger A Grimes
San Francisco 
3 December, 2007

Amit Klein, of Israeli security company Trusteer, recently released 
details on DNS server cache poisoning attacks that affect both BIND 
(Berkeley Internet Name Domain) and Windows DNS servers. It goes to show 
that every time you think a problem with a well-known protocol or 
service has been solved, it may not be.

DNS has been with us since 1983 nearly as long as the internet. And 
although DNS RFCs have come and gone, DNS is still very similar to its 
original specifications. Certainly it has grown in feature set and 
complication, but it still has the same underlying security problems it 
did when it was invented by Paul Mockapetris. The biggest problem is the 
lack of default authentication. Several security mechanisms have been 
created for DNS with varying degrees of success (and failure) to solve 
the authentication problem, but it is still relatively easy to fake a 
DNS packet to either a DNS server or an unwitting client.

Klein's last find involved two discoveries, both of which allow 
important parts of a DNS server packet to be forged with trivial effort. 
The first implementation error involves the DNS UDP source port. 
Although it should be randomised to prevent forging, it turns out that 
the source port never changes the whole time the DNS server is up and 
running. The second, and more important, problem is the trivial 
predictability of the transaction ID value. Both errors allow DNS server 
packet information to be predicted and forged.

An attacker can send a malicious web page link and induce an end-user to 
click on the link. The clicked link sends off a DNS client query, which 
can be forged, sending the end-user to a bogus location. DNS has been 
found vulnerable in the same way before. In fact, Klein laments, "It is 
saddening to realise that 10-15 years after the dangers of predictable 
DNS transaction ID were discovered" that DNS software is still 
susceptible to transaction ID exploitation.

Klein reported his findings to BIND's caretakers, the Internet Software 
Consortium (ISC), in late May and to Microsoft in April. Both the ISC 
and Microsoft have released patches or updated software. Thanks are due 
to Amit Klein for his research and responsible disclosure.

Overall, Microsoft's DNS implementation has been relatively secure. The 
last major security update to Windows DNS was in Windows 2000 SP2 and 
SP4, as well as Windows Server 2003 (nearly five years ago). BIND is the 
most popular version of DNS server software used on the internet, and 
its overall security track record has been a bit more active over the 
years, as one would expect with more popular software. BIND versions 8.x 
and 9.x have had at least six different vulnerabilities published.

The most secure version of DNS is considered djbdns, named after its 
author, Dr Dan J Bernstein, one of the most prominent voices for 
security over functionality in computer software. Although djbdns (also 
known as tinydns for one of its daemons) is not nearly as functional as 
Windows DNS or BIND, it is run by some of the world's largest companies. 
Dr Bernstein claims that more than 1.8 million .com addresses use 
djbdns. And though Dr. Bernstein has been offering a US$500 (NZ$657) 
reward to anyone who can find an error in its 7,000 instructions, there 
has yet to be a successful claim. Unfortunately, djbdns is built only 
for Unix and could not be used efficiently to support an Active 
Directory domain.

Besides making sure your DNS servers are running up-to-date versions of 
DNS, I think Klein's findings bring up another interesting point. Open 
source advocates are always touting how open source software allows 
programming and security bugs to be found faster than with closed source 
software. It certainly makes sense there's source code to review, and 
more eyeballs to review it. But as Klein's research shows, it doesn't 
make that much of a difference. In the 10 to 15 years that have gone by, 
nobody (publicly) found the bugs in either the closed source or open 
source versions. Both errors went undetected for more than a decade 
until one person got interested in the research.

There are dozens of cases just like this, where open source bugs 
remained undicovered for a decade or more, until one lone individual on 
their own personal quest did some digging. You can look at any of the 
popular protocols (such as SMTP, SNMP, HTTP, FTP, ASN.1, and so on) and 
find vulnerabilities that went undiscovered for over a decade. Heck, 
people are still finding problems in IPv4 packets that have been around 
for 20-odd years. And as far as I can tell, whether or not the product 
was open source didn't really play a part in the finding or the fix, 
albeit the open source fixes are consistently coded faster when the 
problem is located. What mattered most was a single person (or company) 
that cared enough to investigate.

Visit InfoSec News 

Site design & layout copyright © 1986-2015 CodeGods