Networking / Beginners

---

DNS Cache Poisoning

Whereas unauthenticated responses target a requester, DNS cache poisoning targets any type of caching DNS server. An attacker observes a DNS request and generates a forged DNS reply. The reply appears authoritative and contains a long cache timeout value. A poisoned DNS server will provide the false data to any data request. For example, a caching DNS server can be poisoned so that the hostname www.happydomain.lan is mapped to the localhost address (127.0.0.1). Any DNS host requesting a lookup for www.happydomain.lan receives the localhost address rather than the true address. This makes the domain unreachable. Moreover, the incorrect information will be provides as long as the poisoned information is in the cache.

There are few viable options for mitigating DNS cache poisoning. DNS servers may be configured with an upper limit for cached data storage. For example, if the server is configured for a maximum cache period of 24 hours, then a poisoned reply containing a 7-day cache timeout will expire after 24 hours. However, the attack is still viable for the 24-hour window.

Although an attacker can generate a fake DNS reply, they cannot easily prevent a valid DNS server from replying. Caching servers may discard cache entries when multiple replies are received with differing values. This prevents the propagation of tainted information (but impacts the cache performance).

Blind ID Attack

Unauthenticated responses and cache poisoning usually require an attacker to observe the DNS request and session identifier. But observing a request is not always essential. An attacker may choose a common domain name and begin an attack when the hostname appears to timeout. This attack method generates a flood of DNS replies, each containing a different session identifier.

For example, consider a caching server with data that expires in a few seconds (Listing below). In this example, the hostname entry expires in 158 seconds, and the IP addresses expire in 127 seconds. When they expire, the caching server (dnscache) relays the next request to other DNS servers. The replies from these servers repopulate the cache.

Because the attacker knows when the cache expires, the attack can be precisely timed. The only thing needed is for the caching server to generate a request after the cache expires. The attacker can initiate this process by sending a request to the server when the cache is known to expire.

During this window of opportunity, the attacker can generate 65,536 false DNS packets-one for each session identifier. If the correct session identifier is generated before a real server can provide the true reply, then the caching server becomes poisoned. If the attack fails, then the attacker must wait for the cache to expire before trying again. This type of attack is a race condition; the attack does not always succeed. If tried enough times, however, it will eventually succeed.

Example Listing of a DNS Cache Expiration

$ dig @dnscache www.google.com
; <<>> DiG 9.3.0rc4 <<>> @dnscache www.google.com
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 14183
;; flags: qr rd ra
;; QUERY: 1, ANSWER: 4, AUTHORITY: 5, ADDITIONAL: 5

;; QUESTION SECTION:
;www.google.com. 			IN 	A

;; ANSWER SECTION:
www.google.com. 	158 	IN 	CNAME 	www.l.google.com.
www.l.google.com. 	127 	IN 	A 	64.233.161.99
www.l.google.com. 	127 	IN 	A 	64.233.161.104
www.l.google.com. 	127 	IN 	A 	64.233.161.147

In theory, a blind attacker must also guess the UDP port number, however, most DNS servers reuse the same port number for subsequent queries. By reusing the same port, the DNS software does not need to manage a suite of UDP network connections and does not spend time binding to new UDP ports. Unfortunately, this also means that the attacker can determine the port to attack before initiating the attack. Although rare, DNS servers can rotate their UDP ports when making queries. This lessens the risk from a blind attack but increases the software complexity because multiple ports must be managed.