search menu icon-carat-right cmu-wordmark

CERT Coordination Center

Multiple caching service providers are vulnerable to HTTP cache poisoning

Vulnerability Note VU#335217

Original Release Date: 2020-01-14 | Last Revised: 2020-01-14

Overview

A Content Delivery Network (CDN) is a distributed network of proxy servers that deliver web content collected from a back end web server using a temporary local storage called a cache. HTTP cache poisoning is a type of attack that allows a remote attacker to inject arbitrary content using unsanitized HTTP headers to poison the remote cache of a CDN. Once an attacker has successfully injected malicious content, future visitors accessing the compromised website will collect and execute the attacker’s injected scripts.

Description

CDNs use HTTP caching software to provide high availability and high performance by distributing the service spatially relative to end-users. The HTTP caching software interprets the HTTP request from a website visitor (web client) using the supplied HTTP headers to select and deliver appropriate content. The content can either be delivered from the local cache or collected by reaching the appropriate back end web servers.

This vulnerability works by sending arbitrary headers into the HTTP request stream, which may be processed by the back end web server or by the HTTP caching software. If either the web server or the HTTP caching software is vulnerable, it will include the attackers injected content in the response without performing any type of sanitization. Once the attacker's malicious content is returned, it will also be cached by the HTTP caching software. The HTTP caching software will continue to serve the malicious content to all future visitors of the website until the cache expires or is deleted. This allows the attacker to inject arbitrary content once and have multiple future visitors of the CDN hosted website collect the attacker's content and execute unwanted scripts.

HTTP header injection using traditional headers, like the Host header and X-Forwarded-Host header, is not a new attack method. New HTTP headers like X-Forwarded-Proto, Referer, Upgrade-Insecure-Requests, and X-DNS-Prefetch-Control have been created to provide more capabilities for HTTP processing. Cloud caching in addition to newly available headers allows for an increase in prolonged, large scale attacks against busy and popular websites.

Some examples of the vulnerable headers are:

    Content-Security-Policy-Report-Only
    Forwarded
    Server-Timing
    Set-Cookie
    Strict-Transport-Security
    X-Forwarded-Proto
    Location
    Accept-Language
    Cookie
    X-Forwarded-For
    X-Forwarded-Host
    Referer
    Max-Forwards

There are at least two common reasons why these attacks are possible:
1. Certain HTTP headers (e.g., X-Forwarded-Host) are sent by the reverse proxy or CDN to the web server and are many times presumed to be generated/modified by the CDN and therefore trusted.
2. Certain HTTP headers (e.g., User-Agent) are not sanitized by the CDN before being delivered to the web server.

Impact

By performing a malicious request using HTTP headers, an attacker could poison the cache of an CDN provider and inject malicious content that will affect multiple future visitors of the website.

Solution

CDN service providers should implement both of these recommendations:

1. CDNs should inspect and sanitize headers using appropriate enforcement and strict adherence to applicable RFCs before forwarding theses headers to back end web servers.
2. CDNs should also replace, remove, or append headers after sanitiziation that are submitted by the client but are expected to be generated or validated by the CDN, such as the X-Forwarded-Host header.

Back end web servers should not trust any content sent as part of the HTTP request. Web servers should implement secure encoding of output appropriate for the common context targets in web applications (e.g. HTML, XML, JavaScript, etc) as recommended by OWASP.

As a work around, caching software providers can disable caching when suspicious content is found in the HTTP headers or the body of the HTTP requests. This prevents the storing and distributing of malicious content to all visitors of a website.

Back end web server administrators can use the appropriate Cache-Control and Expiry headers to avoid caching of dynamically generated content by the CDNs. This will prevent the storage and delivery of malicious content to future visitors.

Vendor Information

335217
 
Affected   Unknown   Unaffected

Akamai Technologies, Inc.

Notified:  October 04, 2019 Updated:  January 14, 2020

Status

  Affected

Vendor Statement

Akamai acknowledges this issue and has been aware of similar research in the past. This advisory highlights a reflected XSS vulnerability in origin web applications that exists whether or not a CDN is involved, exacerbated by having responses cached. HTTP header values can be crafted by the attacker to include malicious payloads, which will then be stored in the cache and sent when subsequent requests are made for the same content. In essence, this is a traditional reflected XSS attack, elevated to a stored XSS due to caching by CDNs. Website operators should treat HTTP headers as an injection vector that must be validated prior to being parsed. Akamai can work with site operators to help create mitigation strategies specific to their systems. Header values presented to customer's application should be considered untrusted input and validated before use.

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Vendor References

Amazon

Notified:  October 04, 2019 Updated:  January 14, 2020

Status

  Affected

Vendor Statement

Amazon acknowledges the HTTP Cache Poisoning issue and see this as part of AWS's shared security responsibility model with Amazon's customers. CloudFront follows the standards defined in RFC 7234 when defining cache keys, which are used to identify cached content. Customers are further able to specify the headers that CloudFront considers when caching objects The issue described needs to be addressed using CloudFront distribution configuration. Customers can also use AWS Web Application Firewall (WAF) to deploy Access Control Lists (ACLs) in front of their CloudFront distributions, which adds a layer of defense to CloudFront distributions by defining which traffic will be permitted to reach the associated distribution

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Vendor References

Cloudflare

Notified:  October 15, 2019 Updated:  January 14, 2020

Status

  Affected

Vendor Statement

Cloudflare is aware of the issue and has done some mitigations in the past. Most of the cause is due to back end web server or origin of the content. In addition to those blog posts, we direct customers to information about how our cache works:

Vendor Information

We are not aware of further vendor information regarding this vulnerability.

Vendor References


CVSS Metrics

Group Score Vector
Base 5.8 AV:N/AC:M/Au:N/C:P/I:P/A:N
Temporal 5 E:POC/RL:W/RC:C
Environmental 4.9 CDP:ND/TD:H/CR:ND/IR:ND/AR:ND

References

Acknowledgements

Thanks to Dr. Mingkui Wei from Cyber Forensic Intelligence Center, Computer Science, Sam Houston State University for reporting this vulnerability. We would also like to acknowledge the prior research completed by Carlos Bueno and James Kettle.

This document was written by Vijay S Sarvepalli.

Other Information

CVE IDs: None
Date Public: 2020-01-14
Date First Published: 2020-01-14
Date Last Updated: 2020-01-14 19:27 UTC
Document Revision: 61

Sponsored by the Department of Homeland Security Office of Cybersecurity and Communications.