Quick Introduction to DNS
The Domain Name System (DNS) is a critical Internet protocol and infrastructure. The major role of DNS is to translate human readable host names (such as www.trusteer.com) into IP addresses (such as 208.97.136.206). The underlying Internet infrastructure can route traffic only via IP addresses. The underlying Internet infrastructure knows nothing about the name www.trusteer.com and everything about 208.97.136.206. Without properly working DNS, the Internet is crippled; people typing www.trusteer.com in their browser address bar will not be able to access the site. Working directly with IP addresses is theoretically possible (i.e., typing 208.97.136.206 to the browser, instead of www.trusteer.com), yet in real life, impractical.
Now, let's discuss how the host name, www.trusteer.com, is translated into an IP address (in technical terms, this is called DNS resolution). When you type www.trusteer.com into the browser's address bar, the browser (through the operating system) requests a DNS server to resolve this address for the browser.
Which DNS server does the browser use? When the Internet connection is provided by an ISP (e.g., Internet at home, hotspots), this would be the ISP's DNS server, which is obtained by the operating system each time it connects to the Internet, or was configured manually when the Internet connection was set up. Likewise, when the Internet connection is provided in an enterprise environment (Internet at work), this would be the enterprise DNS server, which is again obtained at connection time or set up manually.
The DNS server receives the DNS query for www.trusteer.com. The DNS is a hierarchical system, and in a nutshell:
- The DNS server queries the root DNS server for www.trusteer.com.
- The root server refers the DNS server to the .com name server.
- which refers the server to the server responsible for the trusteer.com domain
- which finally answers the DNS server's query and returns the desired IP address, 208.97.136.206
- The DNS server returns to the browser with this response, and the browser can use TCP/IP to connect to this address.
As a performance improvement, modern DNS servers also cache responses. That is, if another DNS client now requests www.trusteer.com, the DNS server will not resolve this name again, but rather will serve the response from its cache.
Notice that there are two functions that a DNS server can perform:
- It can serve as a (caching) resolver for clients (such as the browser).
- It can serve as an authoritative name server for a domain.
In the example, the caching DNS server (ISP server) received a request from the browser, and then resolved it via a sequence of queries to various authoritative DNS servers - the root DNS server (authoritative for the root domain); the .com DNS server, authoritative for the .com domain, and the trusteer.com DNS server, authoritative for the .trusteer.com domain.
The leading DNS server, in terms of market share, is BIND 9 (by Internet Software Consortium (ISC), www.isc.org). BIND 9 probably powers most DNS servers nowadays. The rest of this discussion is mostly generic, but in some cases specific reference is made to BIND 9.
DNS Security Issues
In the early days of DNS, researchers noticed that there was an inherent vulnerability in the way DNS worked. DNS was implemented on top of User Datagram Protocol (UDP), which is a lightweight, stateless protocol. This means, that in UDP, there is no native notion of a session. In fact, at that time, an attacker who could predict what hostname would be requested by caching a DNS server, and to which authoritative DNS server this request was destined, could practically send his/her own forged response to the caching DNS server, and if that response arrived earlier than the genuine response from the authoritative DNS server, the genuine response was silently discarded.
To appreciate the impact, consider this example. Let's suppose the attacker requests www.trusteer.com from the caching DNS server, and the caching DNS server does not have this host name cached. It has to resolve it. Now, let's say that the caching DNS server does have the .com server address cached, so it needs now to request www.trusteer.com from the .com server. Since the attacker can predict this, he/she now floods the caching DNS server with forged responses which seems to arrive from the .com server, claiming that www.trusteer.com is resolved into an IP address under the control of the attacker. The caching DNS server will happily cache this response and return it to the attacker. Subsequent queries for www.trusteer.com from any other user of that ISP will be answered from the poisoned cache of the cache DNS server, and all such users will be routed to the attacker's IP address.
Back in the 90s this attack was dubbed DNS cache poisoning. Nowadays, it is one way to achieve pharming.
To counter DNS cache poisoning, the DNS protocol has a special 16-bit field called transaction ID. This field is part of the DNS query, and the response to the query should incorporate the same ID of the query. A response with a different query ID should be ignored. In the beginning, many DNS server implementations simply used an incremental counter, which is hardly effective security-wise, but early in this decade, the major DNS server implementations were repaired to produce a random transaction ID.
Now, the attacker has a problem: the query's name, destination IP, and port, etc. are predictable, but the transaction ID is not. Trying all 65,536 combinations of 16-bit renders this attack infeasible (remember that sending each forged response takes bandwidth and time, and the attack is only effective if a forged response with the correct transaction ID arrives at the DNS server before the genuine response from the .com server). Over time, some observations were made both on the randomness of BIND 9's transaction ID (using attractors) and on general methods to improve the cache poisoning attack (e.g., the birthday attack), but so far no method was suggested that practically poisoned the cache of BIND 9 when it is properly configured and DNS/BIND best practices followed.
BIND 9 DNS Cache Poisoning
A paper recently published by Trusteer demonstrates that although the BIND 9 transaction ID appears to be random, it is very far from actually being random. On the contrary, this transaction ID is very predictable. In order to predict the next transaction ID value, the attacker needs to observe the last few values of the transaction ID. To do so, the attacker needs to set up his/her own domain, with a specially crafted authoritative DNS server for that domain. Once this is in place, the attacker can use various methods to force the caching DNS server to send several DNS queries to his/her own DNS server. This way the attacker can collect several values of transaction IDs.
One attack technique requires that the last transaction ID be an even number. To facilitate this attack, the attacker can force the caching DNS server to send more and more DNS queries until the current query's transaction ID is even. When this happens (it takes two DNS queries on average), the attacker, through a simple algorithm developed by Trusteer, calculates 10 candidates for the next transaction ID value (this is a huge reduction of the guess space, compared to the 65,536 guesses the attacker would have to make when the transaction ID is strong). The attacker can cycle through these 10 values as quickly as possible, sending a forged DNS response with each such value.
Another technique requires more transaction ID values (typically 13–15), but in return, the pseudo-random number generator that is used by BIND 9 to produce transaction IDs can be fully reconstructed with this data. So now the attacker knows exactly what the next transaction ID is going to be. The attacker can send a single forged DNS response to the caching DNS server, and as long as this response arrives before the genuine response, the cache will be poisoned. This is a powerful attack, as it retracts the security of BIND 9 to almost where it was over a decade ago.
Trusteer privately notified ISC about the vulnerability, and enabled ISC to develop a fix for this problem in an orderly manner. ISC released their fix simultaneously with Trusteer's paper describing these issues.
Attack Effectiveness
As mentioned, DNS cache poisoning is one way of conducting a pharming attack. It is a very effective way too - the attacker interacts with a single client, and with the DNS server, and does so in a lightweight manner, i.e., in a way unlikely to trigger any IDS/IPS or other security mechanism (after all, each request/response is perfectly valid, and very few of these are made altogether). The gain can be enormous - poisoning the DNS cache of a large ISP or a large enterprise can effectively pharm thousands to millions of clients.
In order to successfully poison the cache, the attacker needs to lure a client that uses the DNS server into loading the attacker's page in the client's browser. That's very easy - spammers and phishers honed their skills in this matter into an art. Statistically speaking, it's almost guaranteed that at least one user (per ISP/enterprise) will fall prey to such techniques.
Next comes the attack staging. The attacker needs to set up a DNS server that is geared towards mounting the attack. This DNS server can be installed on any of the millions of bots in the Internet.
The attacker may face some difficulty if the target DNS server is heavily loaded, or if the DNS entry to be poisoned is already cached and will not expire for a long time (this is not typically the case). In many cases, the attacker will succeed on the first attempt, and in the rest of the cases, the attacker may attempt the attack several times until it succeeds.
Summary
DNS cache poisoning is a very potent attack, made possible (in the case of BIND 9) by a flawed implementation of the DNS server, enabling an attacker to predict DNS transaction IDs. With DNS cache poisoning, an attacker can redirect traffic originally destined to a host name, to an IP address under his/her control, thus effectively conducting a large-scale pharming attack affecting all clients of the DNS server (ISP-wide or enterprise-wide).
BIND 9 administrators are encouraged to apply the ISC fix ASAP to ensure that their server and clients are safe.
Trusteer will continue to research threats to the Internet and work with the relevant vendors to make the Internet a more secure environment.
References
This is a simplified version of the full paper available on Trusteer's web site. All references to previous work of others can be found in the full paper.
Click here for the full research paper
or
Download full PDF version
Click here for the press release
