Bugtraq mailing list archives

Re: [rapt] RE: Raptor 6.5 http vulnerability


From: William Aguilar <WAguilar () SYMANTEC COM>
Date: Tue, 27 Mar 2001 17:23:41 -0500

To our Valued Customers,

We would like to take this opportunity to respond to the Raptor Firewall
6.5 HTTP issue recently reported on
http://www.securiteam.com/securitynews/Raptor_Firewall_HTTP_Forwarding_Vulnerability.html.



The first point we would like to make is that although we do agree with the
authors as it relates to the security implication of the described HTTP
functionality we do not accept the assertion that this is a product related
issue with the Raptor Firewall (HTTP proxy).  Rather, our Raptor  Firewall
HTTP proxy is RFC-compliant, and as such it is behaving consistently with
the specification as described in RFC 2616.  From a pure protocol
perspective, this is a valid HTTP connection and thus the traffic is being
allowed through the firewall with a proper rule.  However, recognizing the
security impact of this configuration, the Raptor Firewall provides you
with the capability to shut down this functionality by setting a
configuration option (http.noproxy) through our configuration files or the
RMC.  The online documentation states:

"To Prevent the Raptor System from being used as a Proxy

If you're using service redirection on the Raptor system (for example, for
connections to your Web server) and you don't want to allow users
connecting through the Raptor system to be able to use it as a proxy,
create a Rule and enter the following into the Advanced Services tab:

http.noproxy"

This provides you with more security protection, in addition to the added
flexibility (vs. a packet filter or stateful inspection product) since it
eliminates the need for completely shutting down the proxy capability of
your internal Web servers.

Additionally, in an effort to provide the highest level of managability and
security to our customers, we will introduce an enhancement to our
Management Console (GUI) whereby the HTTP.NOPROXY functionality will be
permanently exposed.  We also intend to change the default to disable the
HTTP proxy capability on all external interfaces, and leave it enabled on
all internal interfaces.  This will provide your security administrator the
option to manage the default behavior as desired while defaulting to a more
secure initial state "out-of-the-box".

In summary the recommendation to shutdown the HTTP proxy and replace it
with a TCP GSP is the wrong approach.  This solution relegates your Web
servers to the mercy of application-level attacks and it is comparable to
protecting your servers with a packet filter or stateful inspection
firewall, something we do not recommend.

Sincerely,

William J. Aguilar and Tasha van Es
Symantec Corp.
Technical Product Managers




                                                                                                              
                    Lysel                                                                                     
                    Christian            To:     Alexander Bochmann <ab () gxis de>@SMTP@Exchange, Lysel         
                    Emre                 Christian Emre <chlys () wmdata com>@SMTP@Exchange                      
                    <chlys@wmdata        cc:     BUGTRAQ () SECURITYFOCUS COM@SMTP@Exchange,                     
                    .com>                raptor-list () firetower com@SMTP@Exchange                              
                                         Subject:     [rapt] RE: Raptor 6.5 http vulnerability                
                    03/26/2001                                                                                
                    03:34 PM                                                                                  
                    Please                                                                                    
                    respond to                                                                                
                    Lysel                                                                                     
                    Christian                                                                                 
                    Emre                                                                                      
                    <chlys@wmdata                                                                             
                    .com>                                                                                     
                                                                                                              
                                                                                                              



Note, the patch can be downloaded from (for the international version):

ftp://ftp.axent.com/pub/RaptorFirewall/International/Patches/NT6.5/

From: Alexander Bochmann [mailto:ab () gxis de]
 > 1. Problem Description
 >      The Raptor firewall is vulnerability for forwarding http
 >      request on other port numbers than 80, if a rule allows http
 >      traffic.
 >      When an extern or internal client, configures itself to use
 >      the nearest interface as proxy, it's possible to access other
 >      ports that 80 on the target host.
 >
 > 2.1 Non Vulnerable Versions
 >      Raptor firewall 6.0.2.

Depending on the configuration and on how you try it, 6.0.2
also seems to be vulnerable.

We have not noticed this.

I already noticed some months ago that the Raptor (6.0.2)
firewall's http gateway possibly leaks information about an
internal network with the method you described, if redirected
services are used.

It does not leaks information about the internal network. The apache
webserver can leak information from error pages:

.....
Internal Server Error
The server encountered an internal error or misconfiguration and was unable
to complete your request.
Please contact the server administrator, <email of webmaster> and inform
them of the time the error occurred, and anything you might have done that
may have caused the error.

More information about this error may be available in the server error log.



----------------------------------------------------------------------------
----

Apache/1.3.9 Server at <hostname> Port <port>
.......

It's possible to brute-force IP addresses used on a DMZ
network: If you use the http gateway on the external
interface as proxy, you can access internal IPs (and
internal DNS names) directly - just try them all ;)

This should generate some logs!

And can also be blocked by: http.urlpattern

Example:

setenv http_proxy http://external.firewall.name:80/


Now go on with something like...

lynx -mime_header http://192.168.95.1:80/


...you will either get 403 or 503 errors from the gateway
(depending on it's configuration) for the destination:

lynx -mime_header http://192.168.95.2:80/

This is the internal interface for the firewall, right?

HTTP/1.1 503 Service Unavailable
MIME-Version: 1.0
Server: Simple, Secure Web Server 1.1
Date: Mon, 26 Mar 2001 14:59:29 GMT
Connection: close
Content-Type: text/html
[.. etc ..]

...or, if you are lucky, an answer from a web server:

% lynx -mime_header http://192.168.95.74:80/

And this is a request to the webserver?

http.remove-header, should remove the headers :)


HTTP/1.1 200 OK
Date: Mon, 26 Mar 2001 14:43:19 GMT
Server: Apache/1.3.17 (Unix) mod_perl/1.24_01 PHP/3.0.18
Last-Modified: Thu, 15 Feb 2001 08:23:04 GMT
Accept-Ranges: bytes
Content-Length: 2490
Connection: close
Content-Type: text/html

<!doctype html public "-//IETF//DTD HTML//EN">
[.. etc ..]
* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
* Sponsored by FireTower, Inc. - Internet Security Consulting & Sales
*
* Before posting, please check the following resources:
*    Patches/Hotfixes... http://www.symantec.com/techsupp/files/
raptor_firewall/raptor_firewall.html
*    Raptor FAQs........ http://websupport.axent.com/
*    FireTower FAQs..... http://www.firetower.com/faqs/
*    List Archives...... http://firetower.com/archives.html
* - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -



Current thread: