Home page logo
/

bugtraq logo Bugtraq mailing list archives

RE: McAfee Web Gateway URL Filtering Bypass
From: Jim Harrison <Jim () isatools org>
Date: Tue, 24 Apr 2012 14:16:28 +0000

??

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 () gmail com] 
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 () gmail com> 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.


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]