The previous case study is a passive attack exploiting DNS weaknesses—the attacker had to wait for someone to stumble into his trap and could not be sure who he would catch. Now examine an active attack exploiting this same weakness, and with an attacker who targets a specific individual. Assume that Frank, Mary, and the malicious college student at Podunk University are involved.
Suppose Frank has set up his account at Widgets, Inc. so that he can use rlogin to connect to it from his account on the Well (well.sf.ca.us) without being required to supply a password. Frank trusts that the folks who run the Well are keeping his account secure (he’s probably right). The malicious college student sends a mail message to a mail server at Widgets, Inc. addressed to someone at Podunk University. The mail server performs a DNS lookup for podunk.edu. The compromised name server supplies additional information in its reply that indicates not only that well.sf.ca.us has the college student’s IP address but also that the reverse is true: the student’s IP address corresponds to the name well.sf.ca.us.
The student then uses rlogin from his machine to connect to Frank’s account at Widgets, Inc. His machine starts up the rlogin daemon. The rlogin daemon gets the IP address of the incoming connection and performs a reverse query of the widget.com name server, looking for the name that corresponds to the IP address of the college student’s machine. The widget.com name server finds this information in its cache and replies that the IP address corresponds to the name “well.sf.ca.us.” The college student gains access to Frank’s account at Widgets, Inc. The only thing the logging information indicates is that Frank connected from his account on the Well. The logs on the Well show that Frank was not logged in, however, which would tip Frank off if he ever cross-checked them with his own logs.
rlogin is handy when you want to keep passwords out of sight of sniffers, but it suffers from the problem outlined here. Do not use rlogin to allow access from machines that do not have authoritative entries in the local name server database. Otherwise, the DNS name of the accessing machine is checked to determine whether it can be trusted to authenticate its users. A DNS spoof will subvert this check.
Defenses against DNS Spoofing
The ultimate defense against DNS spoofing is not to use the DNS. However, DNS style naming is such a part of the way users and system administrators work that it is unthinkable to do without it. On the other hand, many name-to-IP address mappings will not change and, in some cases, it may make as much sense for a system administrator to configure clients to use an IP address as it would to use a DNS name. Every place an IP address is used in place of a DNS name is one less place the system is vulnerable to DNS spoofing.
Many operating systems simplify the process of reducing use of the DNS by having an API for name-to-address and address-to-name mappings. The API is the same whether DNS is being
used to implement these mappings or some other standard. Some implementations of the API will consult local data that is believed to be faster or more secure than DNS. The DNS is consulted by these implementations of the API only if the local sources fail to give conclusive results.
Even if the API on your system only implements the naming system via one mechanism (in which case choosing to use DNS may be unavoidable), it may be possible to change the implementation and reap widespread benefit immediately. In particular, many modern operating systems use dynamic linking or shared libraries to reduce the size of executable files. With these systems, replacing the library containing the implementation of the API with an implementation that behaves differently will affect all programs started after the replacement.
Note When using SunOS 4.1 as shipped from Sun, for example, you can choose to have
the gethostbyname() and gethostbyaddr() functions use either the /etc/hosts file or the NIS system. When I wanted my programs to use the DNS system instead, I had to get source code to implement those functions using the DNS, compile it, and include it in the shared C system library.
One way to limit the spread of invalid cached entries is to use name server software running on many hosts in your network. If a client on one machine triggers the corruption of the cache on one name server, the use of multiple name servers reduces the likelihood of widespread damage. Placing a name server on every timeshared Unix host, for example, will not only provide quick responses to local clients from the cached entries on the name server, but will also reduce the set of hosts affected by a compromised name server consulted by a set of users on a single timeshared host.
Other hosts can use a different name server that will not have its cache corrupted as long as the name server on the timeshared host does not forward recursive requests to the other name server. An active attacker targeting a particular system may make direct queries of any name server to trigger the corruption of its cache. The technique outlined here limits damage from a passive attacker waiting for victims to come along. You can also add checks to some name servers so that they will respond only to select clients rather than an arbitrary client. Placing such a limitation on a name server does not make it useful for serving requests to the outside world but makes it more secure for internal use.
In the case study of Frank’s and Mary’s Widget company you read about earlier, the college student would not have been so successful in his attack if Frank and Mary had been running name servers on their own workstations. In the first case study, Mary’s cache would have been corrupted but it would not have caused problems for Frank. In the second case, the cache for the name server used by the mail server would have been corrupted, but, again, Frank would not have used the corrupted cache unless his name server consulted with the same one as the mail server.
The use of local name servers on workstations also may reduce total network traffic and aids in fault tolerance. If a network-wide name server goes down, it will not create any delays for information stored in the local name servers.
You are still at risk of a DNS spoof if local name servers on workstations are configured to process queries recursively when they consult the network wide name server. You are also at risk if the local name server refers its local clients to query the network wide name server for names for which the network wide name server is also non-authoritative. In either case, a corrupted network-wide name server cache will affect the workstations.
The use of local name servers will limit, not eliminate, risks. Local name servers are also subject to cache corruption. The reduced risk comes from fewer interactions with any single cache. You should be sure local name servers only process queries from the local machine to prevent an active attacker from directly contaminating their cache. Hiding the workstations behind a firewall will also help.
You might also modify local name server software to be more selective about the information it caches. Again, doing so will be of limited value if the erroneous data is coming from the cache of an unmodified name server being consulted by the local name server. Selective caching by doing such things as ignoring information in the additional information section of DNS replies will certainly have an adverse impact on efficiency. Response times will also be length- ened by any cross-checking or authority checking done by the modified name server, but cached authority checks may ease the problem somewhat.
RFC 1788 proposes an alternative to DNS reverse lookups: all machines would respond to a new ICMP message requesting the set of names that correspond to the IP address on which the ICMP message was received. These responses can then be cross-checked through forward DNS lookups. Although this proposal aims to increase the security of DNS, it is not clear how it would have helped in the case study involving Frank and Mary described earlier. Name-based authentication is fundamentally insecure when the name is not coming directly from a trustworthy source.
The simplest thing a name server administrator can do to prevent a DNS spoof from corrupt- ing the name server cache is to have the most recent version of the operating system’s DNS name server software. The most common implementation of a DNS name server is BIND (Berkeley Internet Name Daemon) on Unix. Newer versions of BIND incorporate modifica- tions made with a more security conscious attitude than older versions. For the most current version, consult the Web at http://www.dns.net.dnsrd/servers.html.
Tip For a more detailed treatment of the security weaknesses of the DNS system, see the paper “Countering Abuses of Name-based Authentication” by Christoph Schuba and Eugene Spafford of the COAST security lab at Purdue University. The COAST department supplies useful security-related information and many useful tools.
COAST has a site on the World Wide Web at http://www.cs.purdue.edu/coast/
coast.html.