Cache poisoning (or DNS spoofing) exploits the open qualities of DNS design to cause disruption or infiltrate the network and steal data.
DDoS may be the most known and widely feared threat for businesses. But cache poisoning is a lot more malicious and can cause more damage.
Let’s take a look at what it is and how to defend against it.
A cache poisoning attack can be as simple and relatively harmless as redirecting traffic to a distinctively different destination, such as causing visitors to a corporate website to end up on a page that blasts them with ads or inappropriate content. But it can be highly sophisticated and use pages that are close to identical of the original but designed to capture data like credit card numbers or passwords.
DNS is, at its core, a simple construct: connecting domain with IP address. Nobody could’ve predicted the growth and impact of the internet — and by the time vulnerabilities came to light, it was too late to fundamentally change how it all works.
DNS was also developed at a time when networks were a lot simpler. Computing power and bandwidth were scarce (compared to today) and expensive. This resulted in foundational concepts like caching DNS data to conserve that processing power and bandwidth.
Cache poisoning (or DNS spoofing) exploits these two qualities of DNS design to cause disruption or infiltrate the network and steal data.
When we say ‘DNS data’ in this context, we mean records — most often A (or AAAA, for IPv6) records. These A/AAAA records have a TTL value. In essence, it tells the DNS resolvers to keep and serve the data for a certain amount of time in their cache, and until it expires, the resolver will not query the authoritative DNS server for updates.
The lower the TTL is, the shorter amount of time the record is cached. Low TTL can help propagate changes in DNS records quickly, but also results in increased load on DNS servers, as they need to update more often.
Cache poisoning targets the cached DNS data and corrupts the records to connect victims to malicious machines.
DNS is, by design, open. It relies on a chain of trust, from root to lower-level servers. Cache poisoning breaks that chain. And DNS wasn’t designed to offer validation for the data or to be in clear view for users. It uses the UDP protocol instead of TCP (which would perform a handshake before establishing a connection) that further complicates verification of identity. As long as the machine sending the query trusts the resolver, the end-user likely will not know something went wrong.
But just as its use, the development and functionality of DNS have evolved as well. There are ways to defend against cache poisoning attacks and keep your networks safe.
One of the best ways to close down the network for attacks against the DNS cache is DNSSEC. Although its merits are often debated in regards to the internet as a whole, business networks can benefit greatly from deploying DNSSEC.
DNSSEC formalizes the chain of trust that DNS is supposed to operate through. In the form of electronic signatures, DNSSEC can offer validation for DNS data. The query is tested against a public key, stored within the DNS records, and the connection is not made unless it successfully matched to the encrypted private key.
DNSSEC doesn’t encrypt the traffic; it only provides a way to establish trust for a particular record. Because of the additional process of decrypting the signature and comparing it to the public key, processing DNSSEC signed packets consumes more processing power and bandwidth (to the point where DNSSEC can be exploited and used in amplification attacks) — but that’s a tradeoff that is increasingly less relevant with today’s powerful hardware.
Cache poisoning, despite using well-known vulnerabilities, is still complicated and hard to use. It requires, in addition to gaining access to the DNS server, the right timing to inject the corrupted data into the traffic.
DNSSEC, especially in environments like corporate networks that are vastly more limited than the open internet, can be effective in closing down most attack vectors for cache poisoning. However, because DNSSEC has issues in scaling and usability concerns when deployed on the open internet, it has a bad reputation and limited adoption rate.
Our advice is to deploy DNSSEC in your corporate network. It’ll help defend against cache poisoning. You can start with our guides on this blog; and if you need a refresher, we offer a DNSSEC training course.
Cache poisoning can be further mitigated by encryption. Encrypting DNS traffic, like with DNS-over-TLS and DNS-over-HTTPS (DoT and DoH, respectively), closes opportunities for attackers to spoof the data. They do, however, come with other caveats, and we’ll take a closer look at them next time.