Home page logo

fulldisclosure logo Full Disclosure mailing list archives

Pyramid BenHur Firewall active FTP portfilter ruleset results in a firewall leak
From: full-disclosure () lists netsys com (Dr. Peter Bieringer)
Date: Mon, 22 Jul 2002 11:05:56 +0200

Hash: SHA1

- --------------------------------------------------------------------
Title: Pyramid BenHur Firewall active FTP portfilter ruleset
        results in a firewall leak

Advisory-ID: ae-200207-028
Published: 22 Jul 2002

 This advisory
 Short information in
- --------------------------------------------------------------------

Source port 20 on a client can be used to connect to services on ports
 1024 and 65096 (release "Update 066 fix 2")
 1024 and 65535 (initial installed release)

For more see details below.

Product:  BenHur Firewall
Hardware: Release 3
Software: Update 066 fix 2 (1 Jul 2002) (tested)
           and sure earlier releases (initial release tested)

Not Vulnerable:
Software: at the moment only experimental update 067 (19 Jul 2002)

Update hints: select experimental updates by change of setting:
  to "updates_experimental"

Or dedicated download for customers at

Product Description:
BenHur is a firewall appliance based on Debian Linux using Linux
kernel 2.2.x built-in ipchains firewalling capabilites.

Vendor URL:
Pyramid Solutions, Germany  URL: http://www.pyramid.de/

Vendor response:
09 Jul 2002: E-mail to <support.solutions (at) pyramid.de> and <support
(at) pyramid.de>
10 Jul 2002: Human response via e-mail by Lars Degenhardt <lars.degenhardt
(at) pyramid.de>
19 Jul 2002: Received information that experimental update 067 fixes this

One can connect to the ports using e.g. netcat: "nc -p 20 $benhur

This makes it possible to connect to several active TCP ports on BenHur:

tcp        0      0  *               LISTEN
 -> Squid
     protected by Squid-ACL against misuse from outside
tcp        0      0  *               LISTEN
 -> BenHur Webadministration
     not protected by IPv4-ACL, see below
tcp        0      0  *               LISTEN
 -> HylaFAX client server
     (possible access not tested)
tcp        0      0  *               LISTEN
 -> HylaFAX client server
     (possible access not tested)
tcp        0      0  *               LISTEN
 -> ISDN client server monitor and connection trigger program
     (possible access not tested)

Especially the BenHur Web administration port is interesting:

# nc -p 20 ***.***.***.*** 8888
GET / HTTP/1.0

HTTP/1.1 401 Authorization Required
Date: Tue, 09 Jul 2002 09:53:51 GMT
Server: Apache/1.3.0 (Unix) Debian/GNU
WWW-Authenticate: Basic realm="Ben-Hur Administration"
Connection: close
Content-Type: text/html

<TITLE>401 Authorization Required</TITLE>
<H1>Authorization Required</H1>
This server could not verify that you
are authorized to access the document you
requested.  Either you supplied the wrong
credentials (e.g., bad password), or your
browser doesn't understand how to supply
the credentials required.<P>

Two issues:
  a) Information disclosure about Apache Version, OS and Firewall software.
  b) Dictionary or brute-force attack on password is possible.

About FTP and stateless packet filters:
As known, ipchains is (in contrast to iptables of 2.4.x) a stateless packet
filter and is only able to make decisions based on the data of a single
(e.g. Source IP, or the status of the TCP-specific SYN flag).

A good firewall ruleset built for a stateless packet filter is more
complicated than the equivalent ruleset for a stateful packet filter.
Especially the rules controlling active FTP (client inside, server outside)
among the most prominent reasons for security holes in a firewall

If a firewall allows active FTP from the inside to the outside, the
administrator has to allow everyone outside to establish a TCP session from
source port 20 to a port on or beyond the firewall numbered 1024 or above.
This port is specified either by the FTP client directly (after asking the
local system for a free port), or by the masquerading engine (if FTP client
on an internal network behind the firewall, not on the firewall itself).

Both port ranges are known:
 a) see /proc/sys/net/ipv4/ip_local_port_range, which is normally 1024-4999
    (see also net/ipv4/tcp_ipv4.c)
 b) 61000-65095 (see kernel sources ip_masq.[hc])

Problems in the BenHur configuration:
There are more than one reason why BenHur is vulnerable:

1) BenHur is currently using the following dangerous ruleset for active FTP:

chain: input
ACCEPT  tcp ------ 0xFF 0x00 ppp0   20 ->   1024:65096

Therefore, any incoming TCP connection requests to ports between 1024 and
65096 are permitted.

This rule is set by script /etc/init.d/ben-hur.ipchains in following lines:

$IPCHAINS -A input  --source-port 20 -d $WORLD 1024:65096 -p tcp \

$IPCHAINS -A output --source-port 20 -d $HOME  1024:65096 -p tcp \

2) All daemons listening on ports >=1024 bind to IPv4 "any" and not e.g. to
   internal IPv4 address only.

3) Not all daemons have an ACL which denies a request from outside on higher
   level, e.g. using tcp_wrappers or a built-in ACL system (c.f. Squid).

How to prevent this vulnerability:
There are several solutions to close such holes in general:

1) For masqueraded active FTP connection, the destination port on the
   is always mapped to a port in the range 61000-65095 by the module
   "ip_masq_ftp". Therefore a rule like

chain: input
ACCEPT  tcp ------ 0xFF 0x00ppp0   20 -> 61000:65095

would be more appropriate. The above translates to the following lines
replacing the corresponding lines in the /etc/init.d/ben-hur.ipchains in
quoted above:

$IPCHAINS -A input  --source-port 20 -d $WORLD 61000:65095 -p tcp \
$IPCHAINS -A output --source-port 20 -d $HOME  1024:65535  -p tcp \

Note1: in the original setup, the script contains a (not security related)
in the port range for the output chain on the internal interface.

Note2: this improvement is also done in BenHur software update 067.

2) If the firewall itself uses active FTP, then the local portrange should
   generally moved to a less dangerous region, e.g. 32768-60999 by using:

  sysctl -w net.ipv4.ip_local_port_range="32768 60099"
    or equivalently:
  echo "32768 60099" >/proc/sys/net/ipv4/ip_local_port_range

You are advised to ensure that the range used for ip_local_port_range does
conflict with any LISTENING ports on the firewall itself

If not able to move the local port range for now, you should at least
reduce the
impact by a second more selective rule for the input chain:

LOCALPORTRANGE="`cat /proc/sys/net/ipv4/ip_local_port_range | awk '{ print
$1 ":" $2 }'`"
$IPCHAINS -A input  --source-port 20 -d $WORLD $LOCALPORTRANGE -p tcp \

Normally this results in following ruleset
chain: input
ACCEPT  tcp ------ 0xFF 0x00ppp0   20 -> 1024:4999

BTW: RPC services (using portmapper for registration) always uses dynamic
ports, which are requested by asking the kernel for a free port out of local
port range first. Therefore, modifying the ip_local_port_range parameter
does not ensure a protection of RPC services behind the firewall.

Note: BenHur firewall don't need filter rules for outgoing active FTP in
general, software update 067 doesn't contain such rule.

3) Restrict the LISTENING socket bindings of the daemons as much as possible
   (making them listen only on the local interface and thus making
   from the outside impossible), and/or employ an ACL system:
     * Daemon-built-in-ACLs
     * tcp_wrapper (if possible)
     * creating dedicated block rules for active server ports >= 1024

There is currently no exploit known to break into BenHur's administration
interface. One plausible version, which iterates a dictionary and
passwords, seems rather trivial to implement.

History of this advisory:
10 Jul 2002: First internal release
22 Jul 2002: Review before publishing

Author: Dr. Peter Bieringer <pbieringer (at) aerasec.de>
(C) 2002 by AERAsec Network Services and Security GmbH
 URL: http://www.aerasec.de/   E-Mail: info (at) aerasec.de
Version: GnuPG v1.0.6-2 (MingW32)


  By Date           By Thread  

Current thread:
  • Pyramid BenHur Firewall active FTP portfilter ruleset results in a firewall leak Dr. Peter Bieringer (Jul 22)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]