Squid's serious proxy vulnerability can “poison cache”

Jianjun Chen, a graduate student at Tsinghua University in China, discovered a dangerous vulnerability in the popular proxy server, Squid. As he managed to find out, the system does not comply with the RFC 7230 standard, and also does not work correctly when parsing and processing the Host header in HTTP requests. As a result, an attacker can form a malicious package and use it to cache cache with the help of it.

What is the problem

The researcher was able to carry out the Squid-3.5.12 cache poisoning attack for any unencrypted HTTP requests. To conduct such an attack, the attacker must be able to send requests through a proxy server to his site (say, attack.com). In this scenario, a TCP connection is first established with the attack.com web server of the site — since Squid is operating in transparent proxy mode, it intercepts and transmits these requests further. In the next step, the attacker initiates an HTTP request:
')

GET http://victim.com/ HTTP/1.1 Host: attack.com 

The caching module uses the node address from the request line (victim.com) for the key, but the verification module uses the Host (attack.com) header to verify communication between the node and the IP address. This makes the attack possible.

The researcher also published a demo video .

Such an attack can be carried out remotely, for example using Flash-advertising. Since Squid is used as a transparent proxy by many Internet providers, exploiting a detected vulnerability can lead to serious consequences.

Initially, the Squid developers considered that the discovered vulnerability repeated the error described in CVE-2009-0801. However, a Chinese researcher has proven that the new attack is not related to the old vulnerability. In the case of CVE-2009-0801, an attacker could carry out a SOP bypass attack: this error was due to incorrect processing of the destination node's IP address. The problem has been fixed since version Squid 3.3. The new vulnerability lies in the inconsistent operation of the route checking module and the Squid 3.5 caching module.

How to protect

At the moment, the vulnerability is fixed, but CVE is still not there, as well as the official patch in the form of a separate version of Squid. The fix is ​​enabled for now only in daily assemblies for versions 4 and 3.5 .

Positive Technologies experts recommend enabling the host_verify_strict option, disabled by default, and also using the Suricata IDS rule to detect attempted exploits: