How DNS Spoofing Can Happen

How DNS Spoofing Can Happen

Suppose a name server somewhere on the Internet has been compromised by a security attack or is being controlled by an intruder. This name server will provide authoritative responses for some domain and all hosts on the Internet will trust those responses. The authoritative responses can direct clients looking up the names of servers to connect to servers under the control of the attacker rather than the legitimate servers.

A falsified reverse address lookup can fool servers attempting to determine if the IP address of a prospective client corresponds to the name of an authorized client. Within the DNS system, absolutely nothing can be done about such a direct attack.

A standard attempt at a defense to a DNS spoofing attack is to cross-check all responses to reverse lookup queries by making a forward lookup query. That is, a server queries the DNS system with the IP address of a prospective client via a reverse lookup and receives the DNS name(s) of the prospective client. Then it takes the names and queries the DNS system for the address(es) that corresponds to the name. Cross-checking has become a standard technique with TCP wrapper systems.

Cross-checking may help if the attacker is clumsy and alters the name server files corresponding to reverse lookups, but not those corresponding to forward lookups. Because these tables are kept in separate files, they may also be kept on separate name servers. If the attacker has compromised only one of the two name servers, the cross-checking may discover the inconsistency.

Because of potential abuses of the efficiency mechanisms in DNS, the name server may not discover the inconsistency.

Another attempt to stifle DNS spoofing is to make iterative rather than recursive resolution requests so that checks on consistency and authoritativeness can be made more carefully than the name servers themselves do. In particular, when a name server makes a non-authoritative response to an iterative query, it responds with the name of a name server more likely to be authoritative than itself. If the name server has been compromised, it may direct the iterative query to another compromised name server or it may claim authoritativeness when it does not have authoritativeness for the domain being queried. In such cases, a check on authoritativeness should, in principle, detect the attack.

A check on authoritativeness requires querying a root-level name server for the address of the name servers that are authoritative for the base domain of the DNS name. One must then ask the name server at that address for the address of the name server that is authoritative for the next component of the DNS name and so on. Such a procedure is clearly quite time consuming and places considerable load on root-level name servers. Also, it does not help if an authoritative name server has become compromised; it only detects invalid claims to authority.

Note, however, that the plural was used when referring to authoritative name servers. The DNS standards require that data for each domain be replicated on separate computers with no common point of failure, meaning that the name servers with the duplicated data must not be attached to the same network or obtain electrical power from a common source. It seems unlikely that an attacker would be able to compromise all of the authoritative name servers for a given domain.

For this reason, it might seem that you could poll all authoritative name servers when making a query to look for a discrepancy. Unfortunately, one name server is typically designated as the primary authority and the others as secondary authority. The secondary name servers simply make a copy of the data in the primary on a periodic basis after the serial number on the data for a domain has changed. If the primary authoritative name server is compromised, all the secondary authoritative name servers will also contain invalid data after enough time has elapsed. Meanwhile, inconsistencies may simply indicate that the secondary has not copied legitimate changes to the data on the primary.

Efficiency Mechanisms: Downfall of DNS Security

The truly troubling part of the DNS security problem is that when a name server caches invalid data, the invalid data can remain in the cache for a very long time and can misdirect queries that are unrelated to the query that placed the data in the cache in the first place.

For example, suppose one query places the name of a domain and the name of its name server in the cache as well as the name of the name server and its address. All later queries for names in that domain will be referred to the earlier named name server at the earlier specified address.

If either of these cached records is invalid, all subsequent queries for this domain will be directed to the wrong place. The responses to these misdirected queries will also be cached. A compromised name server may cause errors in the caches of uncompromised name servers that cause the uncompromised name server to provide invalid data to its clients.

Furthermore, a DNS name server can supply arbitrary information in the additional information section of a response to any query. Thus, it may provide a perfectly valid response to the original query, but arbitrary misinformation provided in the additional information section of the response will be cached by a name server that queries it.

Suppose, for example, that a server (not a name server) attempts to check on the name of a prospective client by making a query that forces the DNS system to do a reverse lookup on the address to find the DNS name of the prospective client. A compromised name server might provide an invalid response, which would seem to make the prospective client legitimate.

When the server attempts to cross-check this information, the name server may respond with misinformation provided as additional information to the reverse query. If the server makes an iterative query instead, it will not cause immediate corruption of its name server’s cache when the compromised name server is not directly interacting with the local name server, but any client of the local name server may trigger a request that corrupts the cache of the local name server.

Case Study: A Passive Attack

Consider the case of Frank and Mary, who work at Widgets, Inc. Their company runs a name server to support their DNS domain, widget.com. Their workstations consult this name server when looking up the IP addresses of outside networks. One day, Mary is surfing the Web and finds a reference to something that looks interesting at a site in the podunk.edu domain. Her Web browser does a DNS query of the widget.com name server that forwards the query to the podunk.edu name server. The widget.com name server caches the reply from podunk.edu and supplies the requested IP address information to Mary’s Web browser.

Unfortunately, the podunk.edu name server has been taken over by a malicious college student. When the reply goes back to the widget.com name server, additional information fields are attached. One of these contains the name “well.sf.ca.us,” the DNS name for the Well—an online service provider located in San Francisco. The additional information field says that this name is associated with yet another machine controlled by the malicious college student.

A little while later, Frank decides to telnet to his account on well.sf.ca.us and is greeted with the usual login information and prompt. When he types in his username and password, there is a brief pause, he is presented with his usual menus, and continues his work.

What has happened is that when Frank used telnet, it made a DNS query of the widget.com name server. The widget.com name server found the entry for well.sf.ca.us in its cache and returned the IP address of the college student’s machine. Frank’s machine established a connection with the college student’s machine and it began the classic Trojan horse routine.

The student’s machine provided the login prompt and stored up the username and password. It then turned around and used a modified version of telnet to connect to well.sf.ca.us and passed packets back and forth between it and Frank’s machine at Widgets, Inc. The Trojan horse created the illusion that Frank was directly connected to the Well and gave the college student the password for Frank’s account on the Well.

Case Study: An Active Attack

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.

Note: 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.