RE: McAfee Web Gateway URL Filtering Bypass

[Jim Harrison <Jim@xxxxxxxxxxxx>]

??

I'm unclear - exactly how does an ICMP echo cycle have anything to do with the 
apparent disparity between the host portion of the CONNECT URI and the contents 
of the host header?
I can see the logic in :
1. comparing the HOST header to the host portion of the CONNECT URI 
2. resolving either to a name or IP address (depending on its original state) 
3. comparing the resolved results to each other (DNS RR records will be an 
interesting case)

The thing to bear in mind is that reverse resolution (IP-to-name) on the 
Internet tends to be flaky to the point of completely useless.
There are two main problems:
1. many people don't know that they should or don't know how to build PTR 
records
2. hosting or cloud services frequently deploy multiple Web services on a 
single IP, making reverse lookups extremely noisy - when they work at all

Jim

-----Original Message-----
From: Vikram Dhillon [mailto:dhillonv10@xxxxxxxxx] 
Sent: Saturday, April 21, 2012 05:40
To: Gabriel Menezes Nunes
Cc: bugtraq
Subject: Re: McAfee Web Gateway URL Filtering Bypass

Hello,

We might be able to fix this by simply doing a ping to the website before 
connecting, so that the IP of the host specified matches the connect field. In 
any case, the consistency of the host and connect is indeed a big design flaw.

- Vikram

On Mon, Apr 16, 2012 at 6:12 PM, Gabriel Menezes Nunes <gab.mnunes@xxxxxxxxx> 
wrote:
> # Exploit Title: McAfee Web Gateway URL Filtering Bypass # Date: 
> 16/04/2012 # Author: Gabriel Menezes Nunes # Version: McAfee Web 
> Gateway # Tested on: McAfee Web Gateway 7.0 # CVE: CVE-2012-2212
>
>
> I found a vulnerability in McAfee Web Gateway 7 that allows access to 
> filtered sites.
> The appliance 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.
> Others test that I did is convert GET methods in CONNECT methods.
>
> GET http://www.facebook.com HTTP/1.1
> Host: www.facebook.com
>
> in
>
> CONNECT 66.220.147.44:80 HTTP/1.1
> Host: www.uol.com.br
>
> It will connect.
>
> and after it is possible to send the GET packets. It will work!
>
> This vulnerability is different from the CONNECT Tunnel method. The 
> flaw is on the Host field processing. The appliance believes on this 
> field.
>
> So, any sites can be accessed. URL filtering in this device/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.



--
Regards,
Vikram Dhillon

~~~
To perceive is to suffer.