General Information

If your experience is at all like mine, you will find that you need to both educate and convince people — from the "on-the-front-lines" users to management. Here's some help.

Topics on this page:

Telecommunication Outages

Big-Money Losses

Cyberwar — Military applications of network attack and defense

This section grew enough to get its own page addressing:

Click here for that page.

COMSEC (Communications Security) — attacking cellular/mobile & GSM telephony

DNS (Domain Name System) Security Issues

DNS should work as follows:

  1. The human user types www.cromwell-intl.com into a browser. The browser recognizes that this is not an IP address, and it makes a library call to the resolver. That creates a DNS query packet asking for an A record for the fully-qualified domain name (FQDN). This is a relatively simple UDP datagram.
  2. That DNS query is sent to the client's nameserver. If you are reading this at home, that means the DNS server specified by your ISP when your system used DHCP to get its IP configuration. If you are at work, then it would be your corporate DNS server. Either way, the DNS server is willing to do some work on behalf of the client and answer its questions because it's a client.
  3. That nameserver (labeled "ISP nameserver" below) doesn't know and it doesn't know who to ask. So it asks a server authoritative for the entire .com domain, "Where is the nameserver for the cromwell-intl.com domain?", asking for an NS record. The root servers are authoritative for .com and so its IP address is coded into the DNS server software.
  4. The .com server answers the direct question and also passes along the answer to the obvious next question, "What are their IP addresses?". As it turns out, there are two. One question was asked, there were two answers and two additional pieces of useful information.
  5. Your nameserver now picks one of those servers and asks the original question, "What is the IP address for www.cromwell-intl.com?".
  6. That nameserver responds that www.cromwell-intl.com is really an alias. The canonical name is cromwell-intl.com and its IP address is 75.146.106.233. This information should be good for a while, feel free to cache it for 3,600 seconds.
  7. Your ISP returns that information to your client, which receives it and passes the information along to the browser application. It makes a connection to TCP port 80 on that IP address, and this page loads.
  8. Meanwhile your nameserver is caching that information in case some client asks the question within the Time To Live value.

Below you see those numbered steps as ASCII art:

[1,2] client -----------------------> ISP nameserver
              DNS query:
              www.cromwell-intl.com A record

[3]                                   ISP nameserver --------------------> .com name server
                                                     DNS query:
                                                     cromwell-intl.com NS

[4]                                   ISP nameserver <-------------------- .com name server
                                                     DNS answer:
                                                     cromwell-intl.com NS = ns31.domaincontrol.com
                                                     cromwell-intl.com NS = ns32.domaincontrol.com
                                                     Additional resource record:
                                                     ns31.domaincontrol.com A = 216.69.185.16
                                                     ns32.domaincontrol.com A = 208.109.255.16

[5]                                   ISP nameserver --------------------------------> ns31.domaincontrol.com
                                                     DNS query:
                                                     www.cromwell-intl.com A

[6]                                   ISP nameserver <-------------------------------- ns31.domaincontrol.com
                                                     DNS answer:
                                                     www.cromwell-intl.com CNAME = cromwell-intl.com
                                                     Additional resource record:
                                                     cromwell-intl.com A = 75.146.106.233
                                                     TTL = 3600 seconds

[7,8] client <----------------------- ISP nameserver <---> cache
               DNS answer:
               www.cromwell-intl.com CNAME = cromwell-intl.com
               Additional resource record:
               cromwell-intl.com A = 75.146.106.233
               TTL = 3600 seconds

What the attacker wants to do:
The attacker wants to fool many people into looking at the wrong web site. They build a bogus web site on some server. It looks like something people would trust, for example, a clone of the citibank.com web site. Of course, it is just going to steal information if anyone visits it and believes it's really Citibank!

They will then try to fool as many DNS servers as possible into beliving that the IP address for www.citibank.com and citibank.com is whatever IP address they have for their bogus site.

Note that they could have a digital certificate from Verisign or whoever, completely valid for their IP address and whatever their domain really is. Your browser would be happy to connect to that server via HTTPS and it would report no problem. You would have to examine the certificate details and see that it was issued to some organization in Russia instead of Citibank, and what is the probability of you doing that every time you use a banking site?

So how do the bad guys fool the world-wide DNS infrastructure?

Problem #1 — Stateless DNS
Early versions of the BIND DNS server did not keep track of which questions they had asked. If they got an answer, they assumed it was relevant and put it in the cache. So the bad guy does this:

Problem #2 — The Kaminsky DNS Vulnerability
Dan Kaminsky discovered a very serious problem in DNS and publicized it in the summer of 2008. Left out of the above explanation was the detail that DNS packets contain a field called the Query ID. This allows a DNS server to match answers to questions, and it allows newer DNS implementations with some sense of state to tell if a given answer corresponds to a question that they had asked.

The problem is that the Query ID is reasonably easy to guess in many DNS server implementations. The bad guy now:

This is also a cache poisoning attack, but it is far more powerful.

So, how do you avoid being a victim?
Your DNS server needs to be running up-to-date DNS software! Patched DNS server software will randomize both the UDP port used for its queries and the Query ID field itself. Unfortunately, six or so months after Kaminsky's discovery was announced to great fanfare, mention in newspapers and so on, over 25% of the DNS servers on the Internet were found to still be running out of date and vulnerable software!

The djbdns DNS server by Daniel J Bernstein has correctly randomized both the source UDP port and Query ID since the beginning. Many people find his djbdns easier to configure than the much more commonly used BIND software from ISC.

Incidents and Anecdotes

Government Warnings and Reactions

Further Reading


Back to the Security Page

Click here to inquire about advertising on this or any page on this site.
Home Unix/Linux Networking Infosec Travel Technical Radio Site Map Contact
Use /bin/vi! Manipulate images with ImageMagick! Hosted on OpenBSD
Hosted on Apache This site is viewable with any browser Valid XHTML 1.1! Valid CSS!
© Bob Cromwell Sep 2010. Created with /bin/vi and ImageMagick, hosted on OpenBSD with Apache.    Root password available here, privacy policy here.