McAfee Web Gateway URL Filtering Bypass Apr 16 2012 10:12PM
Gabriel Menezes Nunes (gab mnunes gmail com) (1 replies)
Re: McAfee Web Gateway URL Filtering Bypass Apr 21 2012 12:40PM
Vikram Dhillon (dhillonv10 gmail com) (1 replies)
RE: McAfee Web Gateway URL Filtering Bypass Apr 24 2012 02:16PM
Jim Harrison (Jim isatools org)

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


-----Original Message-----

From: Vikram Dhillon [mailto:dhillonv10 (at) gmail (dot) com [email concealed]]

Sent: Saturday, April 21, 2012 05:40

To: Gabriel Menezes Nunes

Cc: bugtraq

Subject: Re: McAfee Web Gateway URL Filtering Bypass


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 (at) gmail (dot) com [email concealed]> 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



> Host: www.facebook.com



> It is blocked.


> CONNECT HTTP/1.1 (without host field)


> It is blocked.


> But:



> 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



> 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.



Vikram Dhillon


To perceive is to suffer.

[ reply ]


Privacy Statement
Copyright 2010, SecurityFocus