Host-of-Troubles is a class of new vulnerabilities that affect a wide range of HTTP implementations. The problem is that deployed systems are generally incorrect (non-compliant with RFC 7230) and inconsistent in parsing and interpreting “Host” headers in HTTP requests. This problem can be exploited by carefully crafting HTTP requests with ambiguous host information, inducing inconsistent interpretations between two parties. Such inconsistency can lead to severe security consequences, such as HTTP cache poisoning and security policy bypass.By issuring one single carefully crafted HTTP request, an attacker can:
These attacks, especially the cache poisoning ones, have a significant impact in the current Internet because transparent cache proxies such as Squid and ATS are widely deployed by ISPs. We conducted large scale measurements of transparent caches on the Internet and discovered that around 97% of users served by such caches are subject to some of the cache-poisoning attacks we found.Update Our paper for ACM CCS 2016 is released! You can find more technical details here.
This problem affects a wide range of HTTP implementations, including web servers, proxies, firewalls and CDNs. After we reported it to CERT/CC and individual vendors, CERT/CC assigned a VU number (#916855) to track this problem, and vendors were actively addressing it.
|Fixed, CVE-2016-4553, CVE-2016-4554
|Apache Traffic Server
|Palo Alto Networks
|Parental Control bypass
We found two forms of HTTP cache poisoning attacks against shared, transparent caches, and one form against CDN cache.
a) General cache poisoning attack against transparent cache(Squid)
We have demonstrated this attack for Squid-3.5.12, enabling cache poisoning of any unencrypted HTTP website. The scenario requires an attacker who can send HTTP requests that pass through a shared transparent cache(Squid 3.5.12). Note that attackers can readily obtain the necessary vantage point using techniques such as web ads. Squid has fixed this problem after our report. (You can also watch all the videos on Youtube.)
b) Exploiting co-hosting to launch attacks against transparent caches (Apache Traffic Server)
The second form exploits the situation where an attacker can obtain a web site hosted on the same server as a target web site, and the hosting server “cooperates” with a transparent cache to enable cache poisoning. Many co-hosting services such as Content Delivery Networks (CDNs) facilitate this attack. We have demonstrated this exploit on an Apache Traffic Server (ATS) 6.1.1, poisoning its cache of sites hosted on Akamai.
c) Exploiting co-hosting to launch attacks against Akamai CDN caches
The attack is different with the second form. It poisons Akamai CDN cache when a Squid proxy resides between Akamai CDN and victim's origin server. We have demonstrated this exploit on Akamai CDN. Akamai has fixed this problem after our report.
a) Bypass parental control features of Windows 8.1
We have demonstrated this attack by bypassing the Parental Control of Windows 8.1, a host-based firewall, by issuing the following request, which is sent to a server for “block.com”:
Apart from host-based firewalls, the evasion techniques can also be used to bypass network-based firewalls.
GET http://www.allow.com/ HTTP/1.1
Yes. The attacks not only affect HTTP websites, but also HTTPS websites: (a) Cache poisoning attacks against CDN caches can affect HTTPS websites whenever HTTPS connections terminate at CDN nodes. The attacks bypassing CDN security protections also apply to HTTPS websites. (b) Deploying HTTPS with preloaded HSTS can mitigate the threat of cache poisoning attack that targets transparent caches. Previous research , however, shows that the support and adoption of HSTS in the real world is still quite deficient.
No. The attacks do not require the use of Flash. An attacker can use other tools to poison a transparent cache if the attacker shares the cache with the victim. Given that transparent caches deployed by ISPs are typically shared by large groups of users, attacks launched from one such system under the attacker’s control suffices to affect all other users sharing that node’s transparent cache. In addition, some forms of the attacks, such as cache poisoning of CDN caches, can be launched from any client.
No. Host-of-Troubles attacks differ from request smuggling in that our attacks exploit discrepancies in the host definition of one request to create host confusion, while request smuggling takes advantage of implementation differences in Content-Length to induce inconsistencies in request-response association. Our study shows that the defenses against request smuggling attacks do not help prevent Host of Troubles attacks. In fact, some vendors expressed concerns that the use of whitespace in Host of Troubles attacks may also apply to Content-Length manipulation to re-enable request smuggling attacks.
 Michael Kranch, and Joseph Bonneau. "Upgrading HTTPS in mid-air: An empirical study of strict transport security and key pinning." In NDSS 2015.
 Chaim Linhart, Amit Klein, Ronen Heled and Steve Orrin. "HTTP Request Smuggling".
 Team, S. Squid Proxy Cache Security Update Advisory SQUID-2016:7. "http://www.squid-cache. org/Advisories/SQUID-2016 7.txt".
 Team, S. Squid Proxy Cache Security Update Advisory SQUID-2016:8. "http://www.squid-cache. org/Advisories/SQUID-2016 8.txt".
 Hodges, J., Jackson, C., and Barth, A. HTTP Strict Transport Security (HSTS). RFC 6797 (Proposed Standard), Nov. 2012. Demo videos hosted on Youtube. https://www.youtube.com/playlist?list=PL--A-gWJV1dLlPzVXBOIaeBWv4BZCU7zA