May 5, 2016

“Squoison” Attack: High-severity Vulnerability in Squid Proxy Server Allows Cache Poisoning



Jianjun Chen, a postgraduate student at Tsinghua University, discovered a critical vulnerability in the popular Squid proxy server.  He found that the system fails to conform to the RFC 7230 standard and is not capable of parsing/processing the Host header in HTTP requests properly. This allows attackers to conduct a Cache Poisoning attack using a specially crafted malicious packet.

What is the problem?

The researcher managed to execute a Cache Poisoning attack targeting any unencrypted HTTP requests in Squid-3.5.12. For successful exploitation, an attacker must be able to send requests to some website (like attack.com) through the proxy server. Under this scenario, the attacker first establishes a TCP connection with the attack.com web server. As far as Squid works in transparent proxy mode, these requests are intercepted and transmitted further. At the next stage, the attacker initiates the following HTTP request:

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

The cache module uses the host address from the request string (victim.com) to create the key; however, the verification module uses the Host header (attack.com) to check the communication between the host and the IP address. This is what makes the attack possible.

The researcher has also published a video demonstration of the attack.

Such attacks can be carried out remotely using Flash ads. The consequences of this vulnerability can be severe because many Internet providers use Squid as a transparent proxy.

Early on, the Squid developers considered that the detected vulnerability is the same with CVE-2009-0801. Still the Chinese security expert has proven that this new attack is not related to the recent vulnerability. In the case of CVE-2009-0801, an attacker could perform a SOP bypass attack: the issue was caused by improper processing of the destination IP address. The issue has been fixed since the new 3.3 version of Squid. The newly detected vulnerability in Squid 3.5 is caused by inconsistent operation of route verification and cache modules.

How to Protect Yourself

The vulnerability was already fixed but there is still no CVE for the issue or patched version of Squid available. The bug fix is included only in the daily builds for 4 and 3.5 versions.

Positive Technologies experts recommend enabling the host_verify_strict option disabled by default and using the Suricata IDS rule to detect exploitation attempts:

24 comments:

  1. This comment has been removed by a blog administrator.

    ReplyDelete
    Replies
    1. This comment has been removed by a blog administrator.

      Delete
  2. This comment has been removed by a blog administrator.

    ReplyDelete
  3. This comment has been removed by a blog administrator.

    ReplyDelete
  4. This comment has been removed by a blog administrator.

    ReplyDelete
  5. This comment has been removed by a blog administrator.

    ReplyDelete
  6. This comment has been removed by a blog administrator.

    ReplyDelete
  7. This comment has been removed by a blog administrator.

    ReplyDelete
  8. This comment has been removed by a blog administrator.

    ReplyDelete
  9. This comment has been removed by a blog administrator.

    ReplyDelete
  10. This comment has been removed by a blog administrator.

    ReplyDelete
  11. This comment has been removed by a blog administrator.

    ReplyDelete
  12. This comment has been removed by a blog administrator.

    ReplyDelete
  13. This comment has been removed by a blog administrator.

    ReplyDelete
  14. This comment has been removed by a blog administrator.

    ReplyDelete
  15. This comment has been removed by a blog administrator.

    ReplyDelete
  16. This comment has been removed by a blog administrator.

    ReplyDelete
    Replies
    1. This comment has been removed by a blog administrator.

      Delete
  17. This comment has been removed by a blog administrator.

    ReplyDelete
  18. This comment has been removed by a blog administrator.

    ReplyDelete
  19. This comment has been removed by a blog administrator.

    ReplyDelete
  20. This comment has been removed by a blog administrator.

    ReplyDelete
  21. This comment has been removed by a blog administrator.

    ReplyDelete
  22. This comment has been removed by a blog administrator.

    ReplyDelete