Web cache poisoning is aimed at vulnerable caching servers to reply with a malicious response back to the requester. It involves two phases:

1. Elicit a response from a web server to deliver a dangerous payload
2. Cache the response to target more requesters

In delivering content, cache servers provide faster downloads at the edge of the network. They can also be targeted to launch attacks that can affect the most number of users who are requesting for content. If the content has been compromised, it can deliver a harmful response back which could contain a link to malware or other malicious code.

Supposed I want to visit a website called:

https://cool.widgets

The main server will not respond to my request to retrieve the website, instead I will be redirected to a cache server that contains the URL of the website and the DNS name space and IP address.

The web cache server will respond with a typical status code for successful GET or POST request:

“response”: {“statusCode”: 200,“reasonPhrase”: “OK”,“errorDetails”: “”},

If the cache server were in any way attacked using an exploit like unkeyed input headers, it will serve the malicious content to other users and appear to be just another normal response.

A type of method used, called an HTTP Response Splitting, can force the cache server to generate 2 responses to 1 request. This replaces the cache content with the one being sent from the header.

The Impact Of Web Cache Poisoning Attacks

If a cache server is successfully compromised due to vulnerabilities, it has a wider implication. If the content being delivered is popular, the network would usually have multiple cache or caching servers.

If those servers are now serving malicious content to users, the effect of the attack can lead to an exponential rise. If each caching server is responding to 1000 clients (i.e. users) at a rate of 1000 client requests per second, for every second the malicious content is served the more clients are affected.

N = 1,000/sec * 60 sec = 60,000

At that rate, 60,000 clients will be affected every minute. The only mitigation here to stop the exponential rise in affected clients is to shut down the network and prevent the downstream caching servers from serving the malicious content.

The intention of the attack can have multiple agendas. First is to serve the malicious content (e.g. malware). It can also be designed to overload the network and lead to an eventual denial of service (DOS).

The SIEM may not detect a network anomaly since the traffic flowing appears to be normal content being served in response to HTTP client requests. The best way to identify that the cache is not serving legitimate content is if there was a service checking the response coming from the cache server.

If the injected payload is a redirect, then it will send the client to another server outside the network. Perhaps this is part of a botnet that will attempt to install the malware on the client. The problem is if the cache server contains the payload and it is executed when the client receives the content.

Mitigating The Damage

The most important thing to do when a cache server or caching servers are rogue is to shut them down. The admin should probably take them offline because there could be another process running on the server in the background.

Rather than leave the server online while troubleshooting, that gives opportunity for more damage so it is best to remove it from the network by shutting the server off or removing its network connection.

Depending on how the admin have configured their system, rebuilding the cache server can be as simple as launching a new instance from an image or if else reinstalling everything from scratch.

The cache should be flushed of all harmful content if there is no need to rebuild the servers, but the admin has to make sure that there are no hidden processes or backdoor programs that have been planted on the server. That is a thorough investigation, which is why it takes probably less time to just build a new instance of the cache server from a virtual machine.

After the cache has been rebuilt, it will take a while to serve the content. When network activity resumes, the cache will receive hits once again and providing content can return to normal. Unfortunately, some networks may have blocked the caching servers as a security response to the web cache poisoning attack. Those networks will have to allow traffic from those servers back through their firewall.

Synopsis

Mitigation is necessary, but perhaps having a plan for prevention is the best way to face web cache poisoning attacks. This is applicable to service providers who have a CDN that requires mission critical workloads to be delivered. Sometimes caching is not required, so it is best to turn the service off and prevent web cache poisoning.

Some CDN providers can even off load caching services to their cloud provider like Amazon or Akamai. Using a third party for caching requests removes administration headaches and moves content away from the local network and to the cloud. The cybersecurity duties will also be the responsibility of the third party, but this can come at a premium price.

Perhaps the most important thing admins can do is to install patches and regular security updates on their servers. This always leads to peace of mind with some certainty.

The only threat will be if the attack is a zero day exploit. In that case a more aggressive IT cybersecurity policy has to be put in place to monitor network traffic and identify perceived threats more accurately. IPS/IDS and threat management systems can help with that task along with alerts and notifications regarding any sort of suspicious read/write operations in the cache server.

Note: Content is provided for informational and educational purposes only.