Re: Squid URL Filtering Bypass

[Richard Barrett]

A forward proxy server when presented with a CONNECT request is solely responsible for attempting to facilitate an end-to-end encrypted path between the requesting client and the far end server. The CONNECT method does no more than create a temporary hole in your firewall.

Only once that is done is a normal HTTP request, including headers such as the Host: header, passed over the encrypted path by the client. Most crucially, the proxy server cannot see the HTTP request or its headers due to the end-to-end encryption. You can use the encrypted path to carry any protocol or data you like and the proxy server is quite oblivious to it as it is opaque to the proxy.

The only access control that the proxy server can perform is based on the CONNECT method request and the server identified in it by either IP number or FQDN and port.

You do not say what the acl is that you have asked Squid to apply but it cannot involve any examination of the Host: header of a request if the CONNECT method is used; only the far end server can see that.

The same conclusion also applies to your other post about a vulnerability with "McAfee Web Gateway URL Filtering Bypass"

On 16 Apr 2012, at 23:11, Gabriel Menezes Nunes wrote:

> # Exploit Title: Squid URL Filtering Bypass
> # Date: 16/04/2012
> # Author: Gabriel Menezes Nunes
> # Version: Squid Proxy
> # Tested on: Squid Proxy 3.1.19
> # CVE: CVE-2012-2213
>
>
> I found a vulnerability in Squid Proxy that allows access to filtered sites.
> The software believes in the Host field of HTTP Header using CONNECT method.
> Example
>
> CONNECT 66.220.147.44:443 HTTP/1.1
> Host: www.facebook.com
>
>
> It is blocked.
>
> CONNECT 66.220.147.44:443 HTTP/1.1 (without host field)
>
> It is blocked.
>
> But:
>
> CONNECT 66.220.147.44:443 HTTP/1.1
> Host: www.uol.com.br (allowed url)
>
> The connection works.
>
> From here, I can send SSL traffic without a problem. This way, I can
> access any blocked site that allows SSL connections.
>
>
> This vulnerability is different from the CONNECT Tunnel method. The
> flaw is on the Host field processing. The software believes on this
> field.
>
> So, any sites can be accessed. URL filtering in this software is
> irrelevant and useless.
> One of the most important (if not the most important) feature of this
> kind of device is to protect the network in accessing specific URLs.
> So, this flaw is very dangerous, and it can be implemented even in
> malwares, bypassing any protection.
> I developed a python script that acts like a proxy and it uses this
> flaw to access any site.
> This tool is just a proof of concept.
> <proxy_bypass.py>

[Gabriel Menezes Nunes]

In McAfee Web Gateway it is possible to convert GET methods in CONNECT
methods, and after the connection, send the same get packet, without
modification and without cryptography. Even with the get packets
passing through the proxy without cryptography and with the Host field
pointing to a filtered site, the proxy will accept.
I think it is a vulnerability!
See my python code.

Thanks

Gabriel Menezes Nunes

2012/4/18 Richard Barrett <r.ba...@openinfo.co.uk>:

[Mario Vilas]

What I understand from the advisory is the Squid proxy is basing its
filtering on the Host header when present, even for the CONNECT
command which doesn't allow this header at all as it makes no sense. I
haven't confirmed the bug but what's being described is definitely a
vulnerability.

There's also a small misconception in what you said. The proxy will
see the entire CONNECT request, headers and all - after the request
headers there'll be a pair of newlines, and only *then* the remaining
data is tunneled transparently. So it's the second request's headers
that the proxy won't see.

--
“There's a reason we separate military and the police: one fights the
enemy of the state, the other serves and protects the people. When the
military becomes both, then the enemies of the state tend to become
the people.”

[Jim Harrison]

To be clear, the CONNECT request is a single request/response cycle between the client and the proxy. Any request body is nonsensical and should be ignored by the proxy (or the request can be rejected if the proxy wants to be pedantic). There is nothing that explicitly disallows inclusion of the host header in a CONNECT request. Granted, including the host header incurs some degree of ambiguity (the FQDN may resolve to the IP address, but the IP address is not guaranteed to resolve to the FQDN), but this is clearly a debatable choice on the developer's part as to whether it should be used to determine traffic policy applicability for this request.

The proxy should only ignore further data between the client and remote if the proxy successfully established a TCP connection between them on the specified destination port.
IOW, if the client sends a CONNECT request that the proxy policy allows, the proxy should either queue or reject further communication from the client until the TCP connection has been successfully established and the proxy has responded to the client with "HTTP 200".
If the connection attempt fails, the proxy should provide an HTTP error response to the client and close the client-to-proxy connection.

Likewise, while the proxy does establish the end-to-end TCP connection between the client and upstream server, it is not responsible for any part of the encryption that may be involved in that communication - unless it specifically offers a "trusted MitM" feature such as TMG HTTPS Inspection or Juniper SSL Forward Proxy (other vendors have similar features).

Also, whether the McAffee proxy allows translating normal HTTP methods to CONNECT, then tunneling them to the upstream proxy is irrelevant to the question of whether the local proxy actually uses the host header or the host portion of the CONNECT request to determine policy applicability.

Regardless - unless the proxy under test explicitly states that the host header information is used to determine policy application to a request, there is no vulnerability.

Jim

[Amos Jeffries]

Can you please email these details and the squid.conf used to find it to
the security bugs reporting address bugs at squid-cache.org.

This appears to be an aspect of same-origin bypass (CVE-2009-0801) or
something closely related.

Thank You
Amos Jeffries
Squid Software Foundation

[Gabriel Menezes Nunes]

Hi,

I tested against a server that I do not have access to the config
file, but I did some tests in a new installation of Squid and the acl
that allows CONNECT only in the SSL_PORTS works well for the CONNECT
to GET translation attack, because the CONNECT method will not work
for port 80. But the method of converting Host to IP still works.
Squid do a better job than McAfee Web Gateway.
But it is still possible to access any site with SSL enabled, like
GMail, Facebook and Youtube(known sites that are filtered in most
companies).
Another possible attack is to find a web proxy in the internet that
allows SSL connection(there are several of them in Google!). This way,
the attacker will access the normal sites (port 80) through this web
proxy and the web proxy through Squid.
McAfee Web Gateway blocks several of this web proxies in regular
configuration. But the appliance is vulnerable to the attacks
mentioned.
One radical method is to block any connection with just the IP
address. Force the user to use DNS hostnames. I do not know if it is
practical, but it will stop the attack.
Many people tell that it is not a attack, it is normal working of SSL
CONNECT Tunnel, but I guess if you block a site in your
institution/company and the users can access this site, it is a
vulnerability! So, why did you install a proxy, if you can't block
anything?
People will waste your bandwidth with videos, access porn and malware
sites without a problem. For me, it is a serious vulnerability.

Thanks for the feedback and the discussion.

Gabriel Menezes Nunes

[ambass...@gmail.com]

please can anyone help me, i have a lab at the uni to exploit a vulnerability that exist in squid proxy server 3.1.19
kindly provide me any info that can help .
thanks,