bugtraq - Re: Squid URL Filtering Bypass

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Wed, 18 Apr 2012 14:57:48 -0400
From: Gabriel Menezes Nunes <gab.mnunes@...il.com>
To: Richard Barrett <r.barrett@...ninfo.co.uk>
Cc: bugtraq <bugtraq@...urityfocus.com>
Subject: Re: Squid URL Filtering Bypass

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.barrett@...ninfo.co.uk>:
> 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>
>