• 5 June 2023

Cache Poisoning is the result of a security breach in which invalid entities can be fed into a cache. Generally, web content caching enhances server and client performance. But since integrity checks are only carried out by the HTTP protocol used in the caching technique, there is usually a lack of authentication in web applications like DNS software. This vulnerability can let the attackers feel free to “poison” the cache respiratory system.

After the cache is tainted, users are directed to malicious websites or an attacker-controlled IP address, and this keeps happening until the contaminated cache entry is deleted or purged.

But you must be still wondering what exactly Cache Poisoning is.  So, let’s read on to know what it is, what behaviors can lead to it, and how you can prevent your systems from succumbing to them. We have also listed some of the ways these vulnerabilities can be exploited and how you can avoid them in the future.

What Is Cache Poisoning?

The cache poisoning attack inserts fake information into the DNS (Domain Name System) cache or web cache to harm users.

When DNS cache poisoning or DNS spoofing occurs, a malicious server diverts traffic from a legitimate server to one which is malicious or harmful. By entering false information into the DNS cache, such as a fake website address, the perpetrator redirects users to an unexpected or dangerous website. This puts users at risk for malware infections, data theft, and other risky situations. By sending malicious HTTP requests to a user using a web server and cache, an attacker can send the attacker malicious HTTP requests.

Threat actors can exploit applications that are vulnerable by injecting malicious data into the cache memory, which prompts the webserver to provide the user with a false HTTP response. Web cache poisoning is the name given to this kind of attack.

What Is DNS Cache Poisoning?

In DNS cache poisoning, a threat actor feeds inaccurate information to the DNS cache, causing the user’s web browser to return invalid results.

When DNS cache poisoning happens, users are usually redirected to a website that is different from the one they intended to visit. Once a malicious site is visited by the user, they may download worms, spyware, web browser hijackers, or other forms of malware to the computer.

DNS resolvers can’t verify the data integrity stored in their caches, which means that incorrect data will remain in the cache until the TTL expires or until the issue is manually resolved.

What Causes Cache Poisoning?

The cause of this attack can be attributed to several factors. One is that DNS was designed for a smaller internet and, as such, was not built to handle large volumes of traffic, it was unable to handle it. Additionally, it was built on trust since there was no reason to believe anyone would spread incorrect information about DNS or redirect users to malicious websites.

The DNS system has inherent and longstanding weaknesses that make it easy for attackers to hijack a DNS lookup for malicious purposes, such as poisoning the DNS cache.

Also, DNS servers use User Datagram Protocol (UDP) rather than Transmission Control Protocol (TCP). Two-way communication is typically initiated by performing a handshake between the communicating parties in a TCP server to verify the identity of the devices involved.

Since UDP does not use an equivalent handshake mechanism, there is no way to guarantee that senders are whom they claim to be. This vulnerability exposes the DNS cache to being poisoned by attackers.

Why Is DNS Cache Poisoning Dangerous?

A DNS cache poisoning attack refers to installing malicious code on a device so that users think they are on a legitimate site. Since the URL is legitimate, the users believe they are on the actual website.

As the browser determines the domain address automatically without the user having to intervene, the user has no reason to be suspicious. This is one of the reasons why DNS cache poisoning is such a sneaky type of cyber-attack.

Additionally, if an attacker inserts a single fake record into a caching server — meaning that the server accepts the fake entry — hundreds or thousands of users may be redirected to rogue websites operated by the attacker

Based on the popularity of the original domain, an attack of this magnitude could be launched on a large scale to achieve the following:

  • Install malware on a user’s computer
  • Steal user credentials, like passwords
  • Steal personal or financial data from users

What Is Web Cache Poisoning?

In creating a web cache poisoning attack, attackers exploit vulnerabilities within caching systems to store negative and modified responses in cache entries, thereby serving malicious content to the site’s users. In most cases, hackers attempt to construct a successful web cache poisoning attack by following these steps.:

  • Identification and evaluation of unkeyed inputs

An unkeyed input is any part of the request that is ignored when determining whether the resource requested must be served from the cache. Hackers identify vulnerable code that injects malicious headers into the HTTP response header field.

As a result of this vulnerability, manipulation of unkeyed inputs can be used to inject poisoned responses to all users who match the cache key when requesting the resource.

It takes understanding how the web server processes unkeyed input to successfully elicit the harmful response. Attacks on the server’s cache can only be successful if these inputs can be used dynamically to generate other responses or if these inputs are reflected in the response without adequate validation and input sanitation.

  • Caching the malicious response 

A web caching attack relies on storing the harmful response in cache memory for success. To examine cache memory behavior, attackers have to engage in various observations and trial-and-error strategies.

The caching of responses depends on factors such as status code, response headers, route, file extension, content type, etc. Once the response is caching successfully, the exploit can be delivered to potential targets.

Numerous conditions must be met for a web cache poisoning attack to succeed. The attack’s impact largely depends on how well-cached responses are stored and how much traffic is related to the poisoned cache.

A cache poisoning attack may be combined with another attack, such as cross-site scripting payloads, to increase the effectiveness of the exploit. When an attacker poisons the browser cache, the impact is merely on a few users. By contrast, server-side cache poisoning can affect many subscribers without constant contact with the attacker.

What Happens When a Web Cache Poisoning Attack Strikes?

Web cache poisoning attacks are difficult to determine because their impact is largely based on two factors:

  • The fake content attacker cached

An attacker can cache an infected file, a malicious script, a malicious link, or some other exploit based on how the web server is configured. Using any of these attack vectors could compromise your personal information, download malware onto your machine, or perform a wide range of other attacks.

It is also important to remember that a web poisoning attack can be used in conjunction with other attacks, causing even more damage than if used alone.

  • Traffic volume on the pages affected by the attack

Nothing will happen if nobody visits the compromised page(s). The poisoned response will be served to users requesting the compromised page(s) while the cache is poisoned. Based on the popularity of the pages in question, the aftermath can range from no impact to disastrous.

Even when caches expire, attackers can script their attack to re-poison them again and again. It is important to ensure your cache expires after a specified period, but it is not guaranteed to prevent web cache poisoning attacks.

How Web Cache Poisoning Attacks Work

Three basic steps are typically involved in a web cache poisoning attack:

  1. Finding unkeyed inputs

Unkeyed inputs, such as headers, are manipulated to perpetrate web cache-poisoning attacks. The cache will not consider unkeyed inputs when calculating whether or not to serve a cached response.

If the attacker can manually identify unkeyed inputs, he or she can add random inputs to requests and wait to see if the server responds in a certain way. However, this process is tedious and time-consuming, unfortunately, there are tools for automating this process, which makes the attack possible.

  1. Generating a malicious response from the web server

To generate a malicious response the attacker must understand how the web server processes the inputs from the known unkeyed inputs. Attackers search for vulnerable web servers that can be exploited, such as those which reflect user inputs in responses without properly sanitizing them or those that generate dynamic content when input is provided by users.

These are the types of misconfigurations that make web cache poisoning attacks possible, among many other types of attacks as well.

  1. Getting the malicious response cached

Now that the server has delivered a malicious response, the attacker needs to cache it and store it on the server for later use. The attacker knows how to communicate a malicious response but needs to convince the caching server to cache the payload.

The attacker must experiment with the caching logic and observe how it behaves at every step while simultaneously recording the behavior. If an attacker can cache his payload on a cache server, all subsequent requests for that same resource will result in a poisoned cache response.

How to Prevent Web Cache Poisoning Attacks

Web cache poisoning attacks can be prevented by disabling caching altogether. This may be not so feasible for larger websites, but for some smaller ones, it is possible.

Here are some guidelines to follow if caching is necessary for your website/application:

  • Only cache static files

To enable caching for a response, you must only use static files that are never modified or affected by any input from the user. This ensures that an attacker cannot retrieve a malicious version of a file instead of the intended good version.

  • Avoid third-party software 

Generally, websites or applications today use some third-party software. When you add third-party software, you implicitly depend on the robustness of the security practices of that third-party development team. If these third-party codes are weaker than yours, your website/application becomes as vulnerable as that code.

  • Regularly test for vulnerabilities

In addition to protecting yourself against other online threats, regular vulnerability analysis can also help you to ensure that your web application or website no longer suffers from cross-site scripting attacks.

  • Use a Vulnerability Scanner

A vulnerability scanner will enable you to detect open endpoints within your web application that might accept harmful responses into the cache memory. In addition to detecting flaws that hackers can exploit, cache vulnerability scanners can also be used by developers to uncover holes that hackers could exploit so that harmful responses, such as HTTP response splitting, can be injected into the system.

The scanners can also detect malicious payloads that are contained in the cache memory, enabling the removal of harmful responses before they are sent to the users by the processing engines.

  •  Disable Unkeyed Inputs

Attackers commonly embed malicious responses into request bodies using these unkeyed headers, which are included in the HTTP response but not part of the cache key. Web developers can prevent such attacks by removing unkeyed inputs from the cache, adding a cache key, or turning off unkeyed inputs altogether.

Overall, Cache poisoning is a very common security breach that can lead to much damage to your website and business image. So, it is crucial to secure your services and minimize vulnerabilities.

Click on the link to know more and sign up for ArvanCloud Free CDN.

If you need help with cloud security services, contact us now to consult with ArvanCloud experts.

Frequently Asked Questions

1. What is the difference between DNS Cache Poisoning and Web Cache Poisoning?

A DNS cache poisoning attack consists of embedding invalid data into the cache of a DNS server, which then compromises the DNS server in a way that can cause problems.

In contrast, Web cache poisoning is changing a request body to invoke a destructive response stored in the server’s or browser’s cache memory.

2. How is Web Cache Poisoning different from Cross-user Defacement?

It is important to know that both attacks are often reliant on HTTP response splitting, but the approach to delivering a harmful payload differs in terms of the way the harmful response is delivered to the victim. The destructive response is held in cache memory in the web cache poisoning attack.

Cross-user defacement involves an attacker sending a single request to a server causing it to respond with two responses. The second response typically contains malicious code misinterpreted as responding to the second request.

3. What is the reason for the DNS cache poisoning attack?

In DNS cache poisoning, a threat actor feeds inaccurate information into the DNS cache, resulting in users’ web browsers returning an incorrect IP address. This IP usually redirects users to a different website than they intended to visit.