Researchers from the University of Hamburg and the University of Cologne
a new technique for attacks on content delivery networks and caching proxies — (Cache-Poisoned Denial-of-Service). This attack allows for denial of access to a page through cache poisoning.
The problem is related to the fact that CDNs cache not only successfully executed requests but also situations where the HTTP server returns an error. Typically, when there are issues with request formation, the server issues an error 400 (Bad Request), with the exception of IIS, which issues a 404 (Not Found) error for overly large headers. The standard allows caching only for errors with codes 404 (Not Found), 405 (Method Not Allowed), 410 (Gone), and 501 (Not Implemented), but some CDNs also cache responses with code 400 (Bad Request), which depends on the sent request.
Attackers can trigger the original resource to return a '400 Bad Request' error by sending a request with specifically crafted HTTP headers. These headers are ignored by the CDN, therefore the information about the inability to access the page will enter the cache, and all other legitimate user requests may lead to an error being displayed until the timeout expires, despite the fact that the original site successfully serves the content.
Three attack variants have been proposed to force the HTTP server to return an error:
- HMO (HTTP Method Override) — the attacker can override the original request method through the headers 'X-HTTP-Method-Override', 'X-HTTP-Method', or 'X-Method-Override', which are supported by some servers but ignored by the CDN. For example, the original method 'GET' can be changed to a prohibited method 'DELETE' or an unsuitable method 'POST' for static content;
- HHO (HTTP Header Oversize) — the attacker can choose the header size so that it exceeds the limit of the original server but does not fall under the CDN restrictions. For example, Apache httpd limits the header size to 8 KB, while CDN Amazon Cloudfront allows headers up to 20 KB;
- HMC (HTTP Meta Character) — the attacker can insert special characters (\n, \r, \a) into the request that are considered invalid on the original server but ignored by the CDN.
The most affected by the attack was the CDN CloudFront used in Amazon Web Services (AWS). Currently, Amazon has already resolved the issue by disabling error caching, but it took researchers over three months to get the protection implemented. The issue also impacted Cloudflare, Varnish, Akamai, CDN77, and
Fastly, but the attack through them was limited to targeted servers using IIS, ASP.NET, and . , which means that potentially 11% of domains belonging to the U.S. Department of Defense, 16% of URLs from the HTTP Archive database, and about 30% of the top 500 sites in the Alexa ranking could be vulnerable to the attack.
As a workaround to block the attack on the website side, you can set the header "Cache-Control: no-store", which prohibits caching of responses. In some CDNs, such as
CloudFront and Akamai, you can disable error caching at the profile settings level. Firewalls for web applications (WAF, Web Application Firewall) can also be used for protection, but they must be implemented on the CDN side before the caching hosts.
Source: opennet.ru
