On Monday, February 27, 2017, security researcher Omer Gil published a blog post laying out a data exfiltration method called a "Web Cache Deception Attack." The attack leverages web caching functionality to potentially expose sensitive information or allow for account takeover (ATO) attacks. Caching is often used to reduce load and time-to-delivery for a web server receiving requests for content, but this attack shows ways in which, given certain web configurations, the caching feature can be misused to serve content not intended for caching. Both the caching proxy and the origin site can have individually valid configurations, but in concert lead to unexpected behavior in light of this new attack method. This attack affects all forms of web caching and is not limited to proxies or Content Delivery Networks (CDNs) . Akamai is actively working with customers to identify configurations which may be affected and assist them in protecting their sites against this attack.
The AttackWhen performing a Web Cache Deception Attack, the adversary forces initiation of a request with the goal of having a web caching service, e.g. a load balancer, reverse proxy, CDN, etc., interpret the request differently than the origin web server would. The attacker attempts to trigger the caching of content that the origin would typically not allow to be cached. Many web servers will, if given a request for a non-existent object /a/b/c/d, will use /a/b/c or /a/b (if they exist), to process the request. This is used in many dynamic applications like ticketing systems (/show/TICKET-1234 can be answered by /show). In this attack, the attacker adds to the URL of a dynamic, uncacheable page a structure that ends in a commonly cacheable filetype (.jpg, .css., et al), with a target of having it cached.
For example, assume that URL www.example.com/personal.php refers to content containing sensitive data that should not be cached. The attacker tricks the target user into making a request to www.example.com/personal.php/bar.css causing the server to respond with www.example.com/personal.php containing sensitive information specific to the victim due to the victim's cookies being present in the request . However, the proxy interprets the request to www.example.com/personal.php/bar.css as being a request for a non-existent, cacheable 'bar.css' file, which in turn causes the content of '/personal.php' to be stored in the cache and accessible by others.
An important part of this attack is the requirement that the target user must be the one to initiate the first request. The attacker would then follow the same URL and caching server, and then have access to the cached contents of the legitimate URL containing the previously private data.
To further complicate matters, the Web Cache Deception Attack can also be used to further ATO attempts. If the cached response contains CSRF tokens, session IDs, security answers, etc., it can allow for complete control of the target account. An attacker can use these pieces of information to hijack user application sessions and interact with the system as if they were the legitimate account owner.
RecommendationsThe Web Cache Deception Attack can be triggered against any web cache where the origin and cache disagree about cacheability, which means customers should review the configuration of all caching solutions that may be used for their websites. The vulnerability is also very difficult to detect through log analysis. Mitigation efforts should be concentrated on review of configurations rather than review of logs to detect past attempts at the use of the attack. While a site's main page may be unaffected, other portions of the web presence may still be vulnerable. Due to issues such as URI diversity and CGI configurations differing from origin to origin there is no simple blanket test for this vulnerability.
Since website and caching configuration needs vary from site to site, there isn't a silver-bullet solution that will "just work" across the board. Depending on configuration needs, some set of the following remediation suggestions might help in protecting against this type of attack. Note: these should not be applied blindly with an expectation of absolute safety, but tested for workability and security given each individual web configuration.
Scripts and applications that do not expect to receive arguments in the URI after their location should issue a redirect back to a URL they expect to handle, or serve a 404 or 302 response.
Make sure that caching services strictly obey the caching expectations of the origin, especially when the expectation is "no-store". On Akamai, the Edge-control header can be used to force caching behavior, regardless of property configuration.
Disable features that could result in confusion about the file extension between the proxy server and the origin server (e.g. AcceptPathInfo, overly broad rewrite rules, etc.).
Akamai customers looking for more nuanced and tailored solutions can contact their account teams to work out a solution leveraging protections from both the origin and Akamai sides of the equation.
