(A User Provides Configuration Guidance) Re: Network Associates Gauntlet Firewall Proxy Bug Lets Remote Users Bypass Some Access Controls and Connect to Arbitrary Ports on Internal/Protected Hosts
|
|
SecurityTracker Alert ID: 1003703 |
|
SecurityTracker URL: http://securitytracker.com/id/1003703
|
|
CVE Reference:
GENERIC-MAP-NOMATCH
(Links to External Site)
|
Date: Mar 1 2002
|
Impact:
Host/resource access via network
|
Fix Available: Yes
|
Version(s): 5.5
|
Description:
An access control vulnerability was reported in the Gauntlet firewall. A remote user can bypass access controls and connect to arbitrary ports on servers located behind the firewall via the HTTP Proxy.
A remote user can reportedly initiate a connection to an IP addresses and web port located behind the firewall. Then, the remote user can apparenly apply the CONNECT method to connect to another server, different from the IP address originally specified in the connection.
For example, a remote user can use "telnet [webserver_address] 80" to attempt to connect to a protected webserver. At the HTTP proxy menu, the remote user can reportedly enter the following to connect to a different protected server that the user is not authorized to connect to:
CONNECT [other_server]:[arbitrary_port] / HTTP/1.0
|
Impact:
A remote user can bypass access controls and access arbitrary ports on protected servers that the user is not authorized to connect to.
|
Solution:
No vendor solution was available at the time of this entry.
A user has advised that an http-gw in the Gauntlet firewall (and the TIS firewall toolkit [fwtk]) should never be configured to listen on the external address. On a Gauntlet system, an administrator can reportedly use the bind-address directive to make sure the http-gw doesn't listen. To be doubly sure, the administrator can set up the appropriate packet filters to stop incoming connections. If a "reverse proxy" function is required, the plug-gw proxy function can be used or a standalone proxy server can be placed outside of the firewall and plugged through the firewall to the real server.
|
Vendor URL: www.pgp.com/products/gauntlet/default.asp (Links to External Site)
|
Cause:
Access control error, State error
|
Underlying OS:
Windows (NT)
|
|
Message History:
This archive entry is a follow-up to the message listed below.
|
Source Message Contents
|
Date: Fri, 1 Mar 2002 12:57:48 +1000 (EST)
Subject: Re: NAI Gauntlet Firewall 5.5 for NT (Multiple Vendor HTTP CONNECT
|
Hi,
It is (or at least I thought it was) well known that an http-gw in both
Gauntlet and the fwtk should NEVER listen on the external address. On a
Gauntlet system use the bind-address directive to make sure it doesn't
listen. To be doubly sure set up the appropriate packet filters to stop
incoming connections. On a fwtk system I don't recall the bind-address
directive being present so I always used packet filters to block incoming
connections.
If you must "reverse proxy", use plug-gw. Better still put a proxy outside
the firewall and plug it through the firewall to the real server.
On Thu, 28 Feb 2002, Rashed Alabbar wrote:
> Hi all,
>
> I found some vulnerabilities on the NAI Gauntlet Firewall 5.5 on NT
> 4. These vulnerabilities were found in other firewalls, specifically
> proxy firewalls, and I tried them on the Gauntlet, it worked.
>
Colin
|
|
