Cache Poisoning

Imagine a trusted librarian who helps you find books. You ask for a history book, but someone has secretly swapped the card in the catalog. The catalog now points you to a book of fiction, which you accept as fact because you trust the source. In the digital world, this is the essence of cache poisoning. An attacker corrupts a temporary storage system—a cache—by inserting malicious data, which is then served to unsuspecting users who believe they are receiving legitimate content from a trusted source. This deceptive attack turns a system designed for speed and efficiency into a distribution channel for malware and misinformation.

What Is It?

Cache poisoning is a class of cyberattack where an attacker exploits a caching mechanism to inject malicious data into its storage. This corrupted data is then served to users, redirecting them to malicious websites, serving them compromised files, or manipulating web content. The attack targets the trust between a user and the caching system, which could be a DNS resolver, a web server cache, or a Content Delivery Network (CDN).

There are two primary forms of this attack:

  1. DNS Cache Poisoning (also known as DNS Spoofing): This attack targets the Domain Name System (DNS), the internet’s phonebook. It corrupts the cache of a DNS resolver by feeding it a false IP address for a legitimate domain name. When users query that domain, the poisoned resolver returns the attacker’s malicious IP address, sending the user to a fake website without their knowledge.
  2. Web Cache Poisoning: This attack targets the caching mechanisms of web servers and proxies (like CDNs). An attacker sends a specially crafted HTTP request that causes the server to generate a malicious response, which is then stored in the cache. Subsequent users who request the same resource receive this poisoned content.

Both attacks are particularly dangerous because they are indirect. The attacker doesn’t target the end-user’s machine; they target an intermediary system. This allows them to compromise a single cache and affect thousands of users simultaneously.

How Does It Work/Happen?

The mechanics of cache poisoning differ based on the target (DNS or Web), but the underlying principle is to trick a system into storing and serving bad data.

DNS Cache Poisoning

The goal is to corrupt the cache of a recursive DNS resolver. This process, defined in detail by security researcher Dan Kaminsky in 2008, typically involves a race condition.

  1. Initiate the Query: The attacker gets a target DNS resolver to query a domain name for which the attacker controls the authoritative nameserver. For example, the attacker might embed an image from attacker.com on a popular forum that uses the target resolver.
  2. Flood with Fake Responses: As the resolver sends its query out to find the IP for attacker.com, the attacker floods the resolver with thousands of forged DNS responses. These fake responses claim to be from attacker.com‘s nameserver.
  3. The Malicious Payload: The forged responses not only contain the IP for attacker.com but also include a malicious entry in the “additional records” section of the DNS response. This malicious entry might claim that www.onlinebank.com points to the attacker’s IP address.
  4. Win the Race: The attacker needs their forged response, with the correct transaction ID, to arrive at the resolver before the legitimate response does. If they win, the resolver accepts the fake response as authentic.
  5. Cache is Poisoned: The resolver stores the malicious entry for www.onlinebank.com in its cache. For the duration of the entry’s Time-To-Live (TTL), every user who asks this resolver for www.onlinebank.com will be directed to the attacker’s fraudulent server.

Web Cache Poisoning

This attack is more complex and targets the way web applications and caches interact. The attacker’s goal is to craft an HTTP request that an application interprets as benign but causes it to generate a malicious response that the cache deems safe to store.

  1. Identify Unkeyed Inputs: The cache key is the set of HTTP headers a cache uses to determine if two requests are for the same resource (e.g., Host and request path). The attacker looks for headers that the application code uses but the cache ignores (unkeyed inputs). A common example is the X-Forwarded-Host header.
  2. Craft the Request: The attacker sends a request for a standard page, like /, but includes a malicious unkeyed header. For example:
    GET / HTTP/1.1
    Host: legitimate-website.com
    X-Forwarded-Host: evil-website.com
  3. Application Generates Malicious Response: The web application, if poorly configured, might use the X-Forwarded-Host header to dynamically generate asset URLs. It might return a page where all JavaScript links now point to evil-website.com.
  4. Cache Stores the Poisoned Page: The cache sees a standard request for / on legitimate-website.com. It ignores the X-Forwarded-Host header and stores the malicious response, associating it with the legitimate URL.
  5. Serve to Victims: Any user who now requests the homepage of legitimate-website.com receives the poisoned version from the cache, and their browser loads and executes the attacker’s malicious JavaScript. This attack can be amplified by techniques like HTTP Response Splitting, which allows an attacker to inject entirely new headers and content into the server’s response.

Examples

Cache poisoning attacks rely on exploiting specific vulnerabilities in software and protocols.

DNS Cache Poisoning Tools and Campaigns

The Kaminsky attack of 2008 was a landmark discovery that exposed a fundamental flaw in the DNS protocol itself. Software like BIND (Berkeley Internet Name Domain), the most common DNS server software, was highly vulnerable. While the core vulnerability has been patched in modern DNS servers, the threat remains. Attackers use tools to automate the process of sending floods of spoofed DNS packets in an attempt to win the race condition against a target resolver.

Web Cache Poisoning Techniques

Web cache poisoning is a more modern threat, highlighted by security researchers like James Kettle. The attack vectors are diverse and depend on the specific architecture of the target application.

  • Exploiting Verbose Headers: An attacker might inject a malicious payload into a less common header like X-Forwarded-Scheme. If the application uses this header to decide whether to generate http:// or https:// links, the attacker can force it to generate insecure HTTP links on a secure page, opening users up to man-in-the-middle attacks.
  • Abusing Fat GET Requests: Some applications and frameworks improperly process GET requests that contain a request body. An attacker can send a GET request with a body containing a malicious parameter. The cache stores the response for the GET request, but the application processes the parameter from the body, leading to a poisoned cache entry.

How Does This Impact Your Business?

A successful cache poisoning attack can have devastating consequences for a business, impacting revenue, reputation, and customer trust.

  • Widespread Credential Theft: By redirecting users to a pixel-perfect clone of your login page, attackers can harvest thousands of usernames and passwords. This is far more effective than a standard phishing email because the user is typing the correct URL into their browser, and the address bar looks correct.
  • Malware Distribution: The attacker’s malicious website can be used to deliver drive-by downloads of malware, including ransomware or spyware, to your customers. Your brand becomes an unwitting distributor of malicious software, leading to immense reputational damage.
  • Revenue Loss and Downtime: If your website is serving poisoned content, you may need to take it offline to purge the caches and fix the vulnerability. This downtime results in direct revenue loss. Furthermore, a poisoned DNS entry can redirect traffic for an extended period (based on the TTL), making your legitimate site completely unreachable.
  • Loss of Customer Trust: The core of the attack is a breach of trust. When customers can no longer be sure that your domain leads to your genuine website, they will stop doing business with you. Rebuilding that trust can take years.

Preventing It

Defending against cache poisoning requires a layered approach, securing both the DNS infrastructure and the web application stack.

Preventing DNS Cache Poisoning

  1. Deploy DNSSEC (Domain Name System Security Extensions): DNSSEC is the most effective defense. It adds cryptographic signatures to DNS records. When a resolver receives a DNSSEC-signed response, it can verify that the data came from the legitimate source and has not been tampered with. It moves DNS from a system of trust to a system of verification.
  2. Use Source Port Randomization: Modern DNS resolvers (like recent versions of BIND) use randomized source ports for outgoing queries. This makes it much harder for an attacker to guess the correct combination of transaction ID and port number needed to forge a successful response.
  3. Keep DNS Software Updated: Regularly patch and update your DNS server software to protect against newly discovered vulnerabilities.

Preventing Web Cache Poisoning

  1. Disable Unused Headers: Identify which HTTP headers your application actually uses. Configure your CDN or caching layer to strip any unrecognized headers from incoming requests before they reach your application. If your application doesn’t need the X-Forwarded-Host header, remove it at the edge.
  2. Have a Strict Cache Key: Ensure that your cache key includes all inputs that are used to generate the response. If your application varies its content based on the Accept-Language header, that header must be part of the cache key.
  3. Avoid Taking Input from Headers: As a general principle, avoid using data from HTTP headers to dynamically generate content, especially URLs or script includes. If you must use them, be sure to rigorously validate the input.
  4. Regular Vulnerability Scanning: Use web vulnerability scanners and conduct regular penetration tests to proactively identify and remediate cache poisoning vulnerabilities in your applications.

Beyond the Illusion of Trust

Cache poisoning attacks shatter the implicit trust we place in the internet’s infrastructure. They demonstrate that the content we receive may not be what it seems, turning systems designed for performance into weapons of deception. Both DNS spoofing and web cache poisoning exploit the gap between how a system is intended to work and how it is actually implemented. As applications and networks become more complex, these gaps will continue to emerge. Moving forward, security cannot be based on trust alone. It must be built on a foundation of cryptographic verification like DNSSEC and a defense-in-depth architecture that assumes any input could be malicious until proven otherwise.

How I Can Help You

Identifying and mitigating complex vulnerabilities like cache poisoning requires deep expertise in network protocols and application security. As an independent contractor, I specialize in uncovering hidden risks through comprehensive security assessments.

Here’s how I can help:

  • Audit your DNS infrastructure to identify vulnerabilities and assist with deploying DNSSEC.
  • Perform penetration testing on your web applications to detect web cache poisoning vulnerabilities and other flaws.
  • Review your cache configuration to ensure it’s secure against header-based attacks.
  • Implement a secure software development lifecycle (SSDLC) to help your team build resilient applications from the ground up.

Don’t let misconfigurations or subtle flaws put your infrastructure at risk. Get in touch today to secure your digital presence and protect your customers from cache poisoning threats.