==================================================================== CERT-Renater Note d'Information No. 2020/VULN028 _____________________________________________________________________ DATE : 16/01/2020 HARDWARE PLATFORM(S): / OPERATING SYSTEM(S): Systems running Content Delivery Networks software. ===================================================================== https://www.kb.cert.org/vuls/id/335217/ _____________________________________________________________________ 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 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 https://blogs.akamai.com/sitr/2020/01/ http-cache-poisoning-advisory.html 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 https://aws.amazon.com/compliance/shared-responsibility-model https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/distribution-web-values-specify.html https://docs.aws.amazon.com/waf/latest/developerguide/what-is-aws-waf.html 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: https://support.cloudflare.com/hc/en-us/articles/200172516-Understanding-Cloudflare-s-CDN#h_51422705-42d0-450d-8eb1-5321dcadb5bc Most CDNs cache what customer origins tell us to cache (respecting cache control headers), so most of these cache poisoning issues are on the origin side and not the CDN side. Cloudflare sensitive to what the customer requests to be cached, when possible Cloudflare prevents caching of dynamic content that is specific to one user (for example a distinct Set-Cookie header observed). Vendor Information We are not aware of further vendor information regarding this vulnerability. Vendor References https://blog.cloudflare.com/cache-poisoning-protection/ https://blog.cloudflare.com/cloudflare-response-to-cpdos-exploits/ https://support.cloudflare.com/hc/en-us/articles/200172516-Understanding-Cloudflare-s-CDN#h_51422705-42d0-450d-8eb1-5321dcadb5bc 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 http://carlos.bueno.org/2008/06/host-header-injection.html https://www.skeletonscribe.net/2013/05/practical-http-host-header-attacks.html https://portswigger.net/research/practical-web-cache-poisoning https://hostoftroubles.com https://www.owasp.org/index.php/OWASP_Periodic_Table_of_Vulnerabilities_-_HTTP_Request/Response_Smuggling https://www.owasp.org/index.php/Cache_Poisoning https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.html https://dl.acm.org/citation.cfm?id=2978394 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 ========================================================= + CERT-RENATER | tel : 01-53-94-20-44 + + 23/25 Rue Daviel | fax : 01-53-94-20-41 + + 75013 Paris | email:cert@support.renater.fr + =========================================================