To be clear, the CONNECT request is a single request/response cycle betwee=
n 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 incur=
s 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 spe=
cified destination port.
IOW, if the client sends a CONNECT request that the proxy policy allows, th=
e proxy should either queue or reject further communication from the client=
until the TCP connection has been successfully established and the proxy h=
as responded to the client with "HTTP 200".
If the connection attempt fails, the proxy should provide an HTTP error res=
ponse to the client and close the client-to-proxy connection.
Likewise, while the proxy does establish the end-to-end TCP connection betw=
een the client and upstream server, it is not responsible for any part of t=
he encryption that may be involved in that communication - unless it specif=
ically offers a "trusted MitM" feature such as TMG HTTPS Inspection or Juni=
per SSL Forward Proxy (other vendors have similar features).
Also, whether the McAffee proxy allows translating normal HTTP methods to C=
ONNECT, then tunneling them to the upstream proxy is irrelevant to the ques=
tion of whether the local proxy actually uses the host header or the host p=
ortion of the CONNECT request to determine policy applicability.
Regardless - unless the proxy under test explicitly states that the host he=
ader information is used to determine policy application to a request, ther=
e is no vulnerability.
Jim
-----Original Message-----
From: Mario Vilas [mailto:mvilas@gmail.com]=20
Sent: Thursday, April 19, 2012 10:03 AM
To: Richard Barrett
Cc: Gabriel Menezes Nunes; bugtraq
Subject: Re: Squid URL Filtering Bypass
What I understand from the advisory is the Squid proxy is basing its filter=
ing on the Host header when present, even for the CONNECT command which doe=
sn'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 tr=
ansparently. So it's the second request's headers that the proxy won't see.
On Wed, Apr 18, 2012 at 7:46 PM, Richard Barrett <r.barrett@openinfo.co.uk>=
wrote:
>
> A forward proxy server when presented with a CONNECT request is solely re=
sponsible for attempting to facilitate an end-to-end encrypted path between=
the requesting client and the far end server. The CONNECT method does no m=
ore than create a temporary hole in your firewall.
>
> Only once that is done is a normal HTTP request, including headers such a=
s the Host: header, passed over the encrypted path by the client. Most cruc=
ially, the proxy server cannot see the HTTP request or its headers due to t=
he end-to-end encryption. You can use the encrypted path to carry any proto=
col 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 CONN=
ECT method is used; only the far end server can see that.
>
> The same =A0conclusion also applies to your other post about a vulnerabil=
ity 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 #=20
> > Author: Gabriel Menezes Nunes # Version: Squid Proxy # Tested on:=20
> > Squid Proxy 3.1.19 # CVE: CVE-2012-2213
> >
> >
> > I found a vulnerability in Squid Proxy that allows access to filtered s=
ites.
> > The software believes in the Host field of HTTP Header using CONNECT me=
thod.
> > 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=20
> > access any blocked site that allows SSL connections.
> >
> >
> > This vulnerability is different from the CONNECT Tunnel method. The=20
> > flaw is on the Host field processing. The software believes on this=20
> > field.
> >
> > So, any sites can be accessed. URL filtering in this software is=20
> > irrelevant and useless.
> > One of the most important (if not the most important) feature of=20
> > this kind of device is to protect the network in accessing specific URL=
s.
> > So, this flaw is very dangerous, and it can be implemented even in=20
> > malwares, bypassing any protection.
> > I developed a python script that acts like a proxy and it uses this=20
> > flaw to access any site.
> > This tool is just a proof of concept.
> > <proxy_bypass.py>
>
--
"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."