DNS Threats part 1: DNS cache poisoning
The goal of cache poisoning attacks is to inject false information into the cache of the targeted resolver, usually an IP address that redirects the victim to a host that the attacker controls with the intention of extracting information or planting malware.
Before delving too deeply into DNS cache poisoning techniques, a comment about the target, i.e. the cache function of the DNS resolver, may be necessary.
The DNS resolver cache is one of many clever designs that evolved from the DNS protocol in the 1980s. The resolver cache makes the resolver fast. By storing responses and references from previous lookup iterations, the DNS resolver builds up enough resource records to take shortcuts instead of performing full iterations. This increases resolver speed while saving bandwidth.
Each individual resource record set is cached according to its TTL (time to live), which acts as an inverse counter. When the TTL for the individual record set reaches zero, it is purged from the resolver cache. The TTL value is measured in seconds and is defined by a 32-bit integer, giving the TTL a range between 0 seconds and approximately 68 years. General consensus and best practice rarely allows TTL’s to exceed 7 days (604800 seconds).
What is DNS cache poisoning?
First, let’s establish what a cache poisoning attack is and what it takes to infect a resolver’s cache:
The attacker must make the resolver send a known query to a known DNS server. The attacker must intercept its response with his own crafted response.
The crafted response packet must appear to come from the known DNS server with the correct criteria, and the packet must arrive before the correct response has arrived from the correct DNS server.
The above criteria have changed over the years and have become more difficult to predict as previous vulnerabilities have been fixed.
Because DNS primarily uses UDP to transport queries and responses, in order to eliminate overhead, DNS is more vulnerable to any kind of spoofing attack than if it had used TCP. This was a design trade-off for speed and a low bandwidth footprint.
History
The DNS and the domain name space were launched in 1984 and were prerequisites for continuous Internet growth. Up until that point, the “DNS” was actually a centrally managed and daily distributed text file by the Stanford Research Institute.
The DNS was designed and developed in a much different time and environment than how the Internet looks today. Back then, the Internet was, in reality, limited to agencies, scientists and the US military, so the focus was on function, availability and speed. Security didn’t become an issue until the Internet reached the public. At this time (early 90’s), the focus on security and robustness was getting more attention, and researchers were able to find fundamental flaws in both the underlying protocols and much of the software that had been designed and developed.
It wasn’t that the Internet community and its researchers were unaware of the security issues, neither in the network protocols nor in the DNS software. Steven M. Bellovin at AT&T Labs wrote a paper back in 1990 named “Using the Domain Name System for System Break-ins” but withheld its release until 1995, although there were indications that the paper was leaked before that.
Christoph Schuba supposedly followed up on that paper by releasing “Addressing Weaknesses in the Domain Name System Protocol” in 1993, in which he, among other vulnerabilities, described a DNS cache poisoning technique working on the predominant DNS server of the time, BIND.
He disclosed that the only authentication mechanism BIND had at the time relied on matching the 16-bit ID field. The big issue here was that the transaction ID field was generated sequentially, making it extremely easy to guess. In combination with the layer 3 and 4 mechanisms where source and destination IP addresses and ports had to match, this vulnerability was extremely serious!
Another unfortunate service the BIND resolver provided was that the additional information a query response could contain wasn’t authenticated thoroughly and could be used to provide data to poison the cache of the resolver.
The transaction ID vulnerability was eventually addressed when CERT release the CA-1997-22 vulnerability. New releases of BIND software now used randomised transaction ID’s.
Another outcome of CA-1997-22 was that all DNS resolvers uses bailiwick checking to prevent out of zone data in the additional section of DNS responses.
In 2002, it was discovered that the BIND servers (the overwhelming majority of the Internet DNS servers still used BIND at this time) were vulnerable to an attack called the Birthday attack, derived from the Birthday paradox. Since BIND sent multiple queries of the same type, it became fundamentally easier to guess the transaction ID, considering that there are only 65536 transaction IDs to choose from.
Even though many flaws were known, it wasn’t until Dan Kaminsky, a security researcher at IOActive, in early 2008, discovered flaws in the design of the DNS protocol by a magnitude that practically all DNS vendors were vulnerable to cache poisoning. Kaminsky worked with a coalition of vendors to fix the flaw which resulted in all vendors simultaneously on July 8th released patches for the their products. The Kaminsky bug went public at Black Hat 2008 on July 24th.
The fix was to use the 16-bit transaction ID and the 16-bit UDP source port to create a 32-bit transaction identifier. At least, this made the vulnerability exponentially harder to exploit.
To be fair, since Bellovin wrote his paper in 1990, the IETF has been hard at work fixing the problem. In 1997 the IETF published RFC2065, revised in 1999 as RFC2535, the first iteration of DNSSEC, which would render DNS cache poisoning useless. Although DNSSEC is worthy of an article series of its own, it’s beyond the scope of this article.
Present day
The mitigations discussed earlier have made it challenging to poison the cache of DNS resolvers. It is not bulletproof, but the chance of succeeding with such attacks has been reduced drastically.
On the negative side, computers and networks are getting faster, and with more botnets available to hackers, the likelihood of successful cache-poisoning attacks isn’t decreasing.
The hacker community in general and the APTs in particular are constantly evolving, exploring other ways to circumvent known mitigations. A few years back, undisclosed DNS software was found to have implemented a flawed random number generator, making the TXID more predictable, which led to another wave of cache-poisoning attacks.
Although limited to a specific DNS software, this indicates how the hacker community works.
Hacker community aside, plenty of research is ongoing to find security vulnerabilities in the academic, governmental and corporate world. At Black Hat 2023, researchers presented a paper on a new powerful poisoning attack named “MaginotDNS” that targets Conditional DNS resolvers due to inconsistencies in implementing security checks between the resolver and forwarder. The researchers found that the bailiwick check in the forwarding mode was vulnerable. Since both recursive and forward modes use the same global cache, the impact was potentially substantial and could compromise entire top-level domains.
The advantage of this kind of research is that the potential problem could be fixed at the software level before the paper was released.
Mitigations
It is safe to say that we haven’t seen the last DNS cache poisoning attack. The threat actors will keep refining tools for brute forcing or predicting the TXID and with vast botnets at their disposal it is more likely that we will see a rise in these types of attacks.
Signing the zones with DNSSEC is the best mitigation currently available. By signing all records with DNSSEC a validating resolver would discard all records that fail validation, thus preventing it from enter the cache.
Unfortunately, the adaptation to DNSSEC is painfully slow. Currently, not even 4% of the total number of zones on the Internet is signed. Until a sufficient number of zones are signed and most of the resolvers perform the validation by default, we will have to live with the threat of cache-poisoning attacks for a very long time.