Introduction
The cache is a crucial part of modern IT infrastructure. It refers to a category of components temporarily storing data to allow its faster retrieval in future requests. Central processing unit (CPU) cache, web cache, domain name system (DNS) cache, and web browser cache are all examples of caches. Although implementations vary between these types, attacks that target caches use similar principles: acquiring unauthorized access to a cache’s contents, or delivering a malicious content into a cache and substituting it for a response to a legal request. Cache poisoning is a type of attack where a cache’s content is substituted with a malicious payload. For instance, a DNS cache poisoning, or DNS cache spoofing, attack aims to replace a DNS record with a falsified address, redirecting a user to a malicious site while also preventing access to the desired location (Zhang et al., 2019). This can be achieved through a variety of methods that exploit different vulnerabilities.
As the consequences of a successful cache poisoning attack can be severe, prevention and detection measures should be serious. Therefore, understanding the vulnerabilities that such attacks exploit and taking steps to remove or cover them is crucial. A significant portion of attacks rely on the semantic gap, differing interpretations of HTTP messages by the origin server and the cache (Nguyen et al., 2019). Often, this results from a cache’s response to a malformed HTTP request (Nguyen et al., 2019). Such invalid responses are generally enabled by poor adherence to the RFC 7234 (HTTP/1.1 Caching) standard (Nguyen et al., 2019). As such, ensuring strict adherence to standards and limiting a potential attacker’s ability to modify cached data form the backbone of cache attack prevention.
Cache Poisoning Attacks
Many web caches can be attacked via a malformed HTTP request. For instance, HTTP request smuggling is a method of injecting a payload via a POST request with two Content-Length headers (Linhart et al., 2005). In this case, two Content-Length headers with differing values are used to exploit the differing interpretation of the request between the origin and the proxy server operating on different software (Linhart et al., 2005). These headers are followed by two different GET methods, one referencing the address of a legitimate cacheable page, the other containing the attack’s payload, a malicious address (Linhart et al., 2005). The difference in which parts of the request are interpreted by the caching proxy and the origin server causes the payload page to be cached in place of the legitimate one (Linhart et al., 2005). Until the cache is flushed, the malicious page will continue to be served to users requesting the legitimate one.
Other types of attack can exploit similar differences in interpretation of malformed requests. Duplicate Host headers or dividing a request into two can be used to achieve a similar outcome: malicious content is delivered instead of the requested legitimate one (Nguyen et al., 2019). Against attacks that exploit the semantic gap in the handling of HTTP requests between the origin and caching proxy servers, stricter adherence to the standards can be a significant countermeasure (Nguyen et al., 2019). Furthermore, restricting suspected malformed requests through limiting header sizes and blocking meta characters is another suggested strategy to counter cache poisoning attacks (Nguyen et al., 2019). However, attacks exploiting these countermeasures, such as a cache-poisoned denial-of-service attack, which poisons the cache with maliciously cached error messages, also exist (Nguyen et al., 2019). Nguyen et al. (2019), discoverers of this particular attack, suggest blocking oversized headers entirely rather than responding with an error message. In general, however, stricter adherence to standards and limiting potential attackers’ ability to modify the contents of a cache, are the base of any countermeasures against cache-based attacks.
Summary and Conclusion
The cache remains a critical part of the modern digital infrastructure. Although the examples given above concern web caches, the principles of attack are similar for different types of cache: a malicious payload is substituted for a legitimate response. As shared caches become more common with the global adoption of cloud computing solutions, so do attacks against them. As the effects of such an attack can vary from denial of service to phishing and compromising of data, deploying countermeasures against them becomes more crucial. Most such attacks target shared caches — i. e. caches that allow concurrent use by multiple users, such as the web cache in the examples above. CPU caches in hardware running virtual machines used in a cloud computing environment, however, can be attacked by similar means, as can personal caches, such as a web browser cache.
Cache-based attacks often use the discrepancies in the interpretation of requests by the origin agent and the caching agent. The general purpose of countermeasures against cache-based attacks is minimizing such discrepancies. If a standard exists documenting these requests and responses, developers should adhere to it as strictly and consistently as possible. It should be updated to include countermeasures against known attacks, and systems implementing it should be updated as quickly as possible. Finally, if the decrease in performance from doing so is justifiable, usage of shared caches in cloud computing should be reduced to prevent cache-based attacks against them.
References
Irazoqui, G., Eisenbarth, T., & Sunar, B. (2015, May). S$A: A shared cache attack that works across cores and defies vm sandboxing — and its application to AES. 2015 IEEE Symposium on Security and Privacy.
Linhart, C., Klein, A., Heled, R., & Orrin, S. (2005). HTTP request smuggling [White paper]. Watchfire.
Nguyen, H. V., Iacono, L. L., & Federrath, H. (2019). Your cache has fallen. Proceedings of the 2019 ACM SIGSAC Conference on Computer and Communications Security – CCS ’19. Web.