Paranoid Penguin - DNS Cache Poisoning, Part I
As scary as Dan Kaminsky's cache poisoning attack is, the short-term fix is simple: make DNS server software send its DNS queries from random UDP source ports, rather than using UDP port 53 or some other static, predictable port. Prior to 2008, BIND, Microsoft DNS Server and other DNS server packages would send all DNS queries from a single port. This meant that to spoof replies to DNS queries, the attacker needed to know only what type of DNS software the target server was running to know what UDP port to use as the destination port for spoofed reply packets.
Randomizing query source ports thus makes spoofers' jobs much harder: they either have to eavesdrop network traffic and observe from what port a given query originates or send lots of spoofed replies to many different ports in the hope that one of them is “listening” for the reply. Thus, in the context of Kaminsky's cache poisoning attack, selecting a random source port from a pool even as small as 2,048 possible ports makes it exactly 2,048 times harder for attackers to guess what a valid DNS reply packet should look like, than if they have to guess only the correct Query ID!
Sure enough, before Kaminsky publicly announced the details of his attack, he convinced DNS server software vendors to issue patches that made their respective products randomize DNS query source ports, and now in 2011, this is the way DNS servers behave by default. This was only a partial fix, however. It's still possible to make Kaminsky's attack work; it just takes much longer.
A better fix is to sign DNS zone data cryptographically, so that recursing nameservers can validate DNS replies. This is possible with the DNSSEC extension to the DNS protocol, and DNSSEC will be the subject of the next column or two.
Having described DNS recursion and cache poisoning attacks in gory detail, next time, I'll begin showing you how to enable DNSSEC on your own (BIND-based) recursing nameserver, so that it checks the signatures of any signed DNS data it comes across. Until then, make sure your DNS software is fully patched, try not to worry too much, and be safe!
Linux Server Security, 2nd Edition by Mick Bauer, Sebastopol, CA: O'Reilly Media, 2006.
“An Illustrated Guide to the Kaminsky DNS Vulnerability” by Steve Friedl, Unixwiz.net Tech Tips: unixwiz.net/techtips/iguide-kaminsky-dns-vuln.html
“DNS Vulnerability: An Exclusive Interview with Cricket Liu” by Greg Ness, Archimedius: gregness.wordpress.com/2008/07/23/dns-vulnerability-an-exclusive-interview-with-cricket-liu
Birthday Problem: en.wikipedia.org/wiki/Birthday_paradox
“Understanding Kaminsky's DNS Bug” by Cory Wright: www.linuxjournal.com/content/understanding-kaminskys-dns-bug
Mick Bauer (email@example.com) is Network Security Architect for one of the US's largest banks. He is the author of the O'Reilly book Linux Server Security, 2nd edition (formerly called Building Secure Servers With Linux), an occasional presenter at information security conferences and composer of the “Network Engineering Polka”.
|Alice, the Turtle of the Modern Age||Mar 07, 2014|
|Using Django and MongoDB to Build a Blog||Mar 05, 2014|
|What virtualization solution do you use/manage at work?||Mar 04, 2014|
|Our Assignment||Mar 04, 2014|
|March 2014 Issue of Linux Journal: 20 Years of Linux Journal||Mar 03, 2014|
|Have Resume - Will Travel||Feb 28, 2014|
- You have to be careful there
1 week 4 days ago
- Wonder when LJ is going to
1 week 4 days ago
- Puerto Rico Free Software
1 week 5 days ago
2 weeks 3 hours ago
- I hate voice commands
2 weeks 17 hours ago
- usabilty --- AGAIN with this nonsense
2 weeks 18 hours ago
- Don't make excuses
2 weeks 22 hours ago
- Sorry to let you know, but
2 weeks 22 hours ago
- Ridiculous statement. Not a
2 weeks 1 day ago
2 weeks 2 days ago