By Roger A Grimes
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
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