Cache Poisoning
Cache poisoning, a form of DNS spoofing, focuses on corrupting the cached answers on the recursive name servers, either through software exploits or protocol weaknesses. Software exploits differ from vendor to vendor and can be patched with software updates. This article focuses on protocol weakness that cannot be easily fixed with software updates.
DNS Weakness 1: UDP
Being a mostly UDP-based protocol has its advantages: It is a lightweight protocol in comparison to TCP, tends to run faster, and is less resource intensive. However, UDP is much easier to spoof than TCP, meaning an attacker can craft a UDP packet with any source IP address easily. Figure 2-3 illustrates this type of source IP address spoofing that is easily accomplished with UDP. This type of source IP spoofing is also known as “reflection”, is discussed in more detail in DDoS Attacks.
Figure 2-3: UDP Reflection
DNS Weakness 2: (Lack of) Randomness
When a recursive name server makes a query, it sets the value of five (5) fields. If the response to the query matches the values of the five fields, it accepts the answer as legitimate. It then returns it to the client and stores it in its cache.
As it turns out, four of the fields are easy to figure out and spoof, so only one field is actually meaningful: the Query ID (also known as the TXID). By most computing standards, the Query ID has relatively few possible values. It is a 16-bit number or a value between 0 and 65,535. This makes it possible for an attacker to initiate an information request on a recursive name server, then immediately spoofs the responses, in order to continue to try firing a lot of responses with different Query IDs.
Figure 2-4 illustrates how this weakness was leverage in the well-published cache poisoning attack discovered by computer security researcher Dan Kaminsky in 2008.
Figure 2-4: Cache Poisoning Attack, or “Kaminsky Attack”.
- The attacker has prior knowledge of the target domain and sends a query to the recursive DNS server for a name that does not exist, such as q0001xxx.example.com
- Because this is a name that does not exist, the recursive DNS server must traverse the DNS namespace to find it.
- The attacker can beat the legitimate NXDOMAIN response from the authoritative name server, by sending a lot of spoofed responses that look like they are coming from the legitimate example.com authoritative name server. In the spoofed response, attacker claims www.example.com is the NS record of the domain, to trick the recursive name server into accepting www.example.com and its IP address.
- By the laws of probability, the attacker’s spoofed response may be accepted by the recursive server, and the bad answer www.example.com is now stored in its cache.
- Unsuspecting client queries for the name www.example.com A record.
- The recursive server provides the answer from the now-poisoned cache with the forged answer from the attacker.
A well-crafted Kaminsky attack can insert a bogus entry in the cache within minutes. He discovered new the vulnerability in the DNS protocol, and he used this to create cache-poisoning of records that aren’t even in the attack query by exploiting the Authority section and the inherent and necessary use of sending A records (called Glue records) when returning NS records for name servers. To make matters worse, the attacker could choose to poison an NS record itself, thus taking command of an entire domain rather than just a single entry.
Solution
UDP-based weaknesses are well studied, and there are generic network-based solutions that can be implemented independently of DNS. For a DNS-specific solution, please refer to Issues and Threats – DDoS Attacks on limiting the effect of source address spoofing in DNS.
As for cache poisoning, a very DNS-specific attack, the most common fix is to update the DNS software so that queries are sent from more random source ports. This effectively lessens the chance that an attacker will successfully guess all five (5) fields in the answer. In addition, this also results in it becoming much more time-consuming for the attacker to carry out this attack, what used to take minutes, now takes hours or even days. However, there is no sure-fire way to guard against cache poisoning, and no software updates can fix this issue once and for all. Software exploits can be patched with software updates, but protocol weakness can only be updated with protocol fixes or extensions. DNSSEC is the “fix” for the traditional DNS protocol.
DNSSEC addresses this problem as it creates authentication of the sender, and provides a pathway for receivers to validate the answer all the way up to the root.
