Security researchers have disclosed three new variants of the web cache poisoning attack first discussed at the 2018 DEFCON conference. These new attacks are being categorized as cache poisoning denial of service (CPDoS) attacks. These vulnerabilities allow an attacker to inject their own malicious content to be served by the cache in lieu of the expected content.
The three attacks discussed in a paper written by Hoai Viet Nguyen and Luigi Lo Iacono from Cologne University and Hannes Federrath from the University of Hamburg all follow a similar pattern. An attacker sends a simple HTTP request containing a malicious header targeting a resource on a web server. That request is processed by an intermediate cache that does not use the selected header elements as part of its cache key. This request is forwarded to the origin server which returns an error page due to the malicious header content. This error page is then cached and served whenever that resource is requested by other users.
These exploits were proven to be practical, and the authors of the paper responsibly disclosed these attacks to the systems that they found were susceptible. A detailed list of cache frameworks, web servers, and web frameworks that are susceptible can be found on the CPDoS site. The researchers noted that: "according to our experiments 11% of the DoD web sites, 30% of the Alexa Top 500 websites and 16% of the URLs in the analyzed HTTP Archive data set are potentially vulnerable to CPDoS attacks."
There are three specific flavors of attack disclosed here. In the first attack, HTTP Header Method Override (HMO), an attacker takes advantage of some web frameworks that allow for overriding HTTP methods sent in an HTTP request. Many intermediary systems such as proxies, load balancers, caches, and firewalls only support the GET and POST verbs. To work around this some REST-based APIs and web frameworks provide headers such as X-HTTP-Method-Override, X-HTTP-Method, or X-Method-Override to support these blocked methods.
In this exploit, an attacker sends a GET request with the X-HTTP-Method-Override set to POST. While the cache interprets this as a GET request, the web application uses the X-HTTP-Method-Override value and interprets this as a POST. Assuming that the web application doesn't implement business logic for POST on this route, an error is returned, which is then cached as the GET response.
In the HTTP Header Oversize (HHO) exploit, the attacker takes advantage of discrepancies in the definition of size limits for HTTP request headers. As the HTTP standard does not define limits for HTTP request header size, intermediate systems, web servers, and web frameworks have defined their own. For example, Apache HTTPD has a header size limit of 8,192 bytes. However, AWS CloudFront allows up to 20,480 bytes. In this example, since the cache accepts a larger header size limit than the origin server, an attacker can craft a GET request with a header larger than the size supported by the origin server but smaller than the limit for the cache. The origin server will send an error response which will then be cached for that GET request.
In the final disclosed exploit known as HTTP Meta Character (HMC) the attacker attempts to bypass the cache with a request header that contains harmful meta characters (e.g. \n, \r, \a). If the cache forwards the request without blocking or sanitizing the origin server may classify the message as malicious and return an error page. As in the HHO exploit, that error page is cached in lieu of the proper response to that GET request.
Cloudflare released a blog post outlining the recommendations for their clients. For most users of Cloudflare, nothing needs to be done. However, users who are running unpatched versions of Microsoft IIS with request filtering enabled on origin, or have forced caching of HTTP response code 400 through the use of their Cloudflare Workers, are recommended to make configuration changes. Cloudflare notes that they have not seen any attempts to leverage these exploits on their infrastructure.
The authors also notified the AWS CloudFront team of these exploits. While the AWS team stopped caching error pages with an HTTP 400 status code by default, the authors of the paper noted that AWS "suggests users to deploy an AWS WAF in front of the corresponding CloudFront instance. AWS WAF allows defining rules which drop malicious requests before they reach the origin server."
Microsoft resolved this issue under CVE-2019-0941. The Play 1 framework released updates in versions 1.5.3 and 1.4.6 to limit the impact of the X-HTTP-Method-Override header. It is recommended to update to one of these versions to mitigate CPDoS attacks. While the exploit was disclosed to the Flask team, the researchers note that they received no response from the development team.
The researchers have released their research paper on the CPDoS attacks, and will be presenting at the upcoming CCS 2019 conference as well. Additional information can be found on the CPDoS site.