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

2002-07-22T00:00:00
ID SECURITYVULNS:DOC:3247
Type securityvulns
Reporter Securityvulns
Modified 2002-07-22T00:00:00

Description

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1


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

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

URLs: This advisory http://www.aerasec.de/security/advisories/txt/ ae-200207-028-BenHur-activeFTPruleset.txt Short information in German http://www.aerasec.de/security/index.html?id=ae-200207-028&lang=de English http://www.aerasec.de/security/index.html?id=ae-200207-028&lang=en


Problem:

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

For more see details below.

Vulnerable:

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: "configuration->admin->update-host-einstellungen->url-pfad" to "updates_experimental"

Or dedicated download for customers at https://www.ben-hur.de/updates_experimental

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 issue

Details:

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

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

tcp 0 0 0.0.0.0:3128 0.0.0.0: LISTEN -> Squid protected by Squid-ACL against misuse from outside tcp 0 0 0.0.0.0:8888 0.0.0.0: LISTEN -> BenHur Webadministration not protected by IPv4-ACL, see below tcp 0 0 0.0.0.0:4557 0.0.0.0: LISTEN -> HylaFAX client server (possible access not tested) tcp 0 0 0.0.0.0:4559 0.0.0.0: LISTEN -> HylaFAX client server (possible access not tested) tcp 0 0 0.0.0.0:6105 0.0.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

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <HTML><HEAD> <TITLE>401 Authorization Required</TITLE> </HEAD><BODY> <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> </BODY></HTML>

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 packet (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) is among the most prominent reasons for security holes in a firewall configuration.

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 is 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 0.0.0.0/0 0.0.0.0/0 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 \ -i $IFACE_WWW -j ACCEPT

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

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 firewall 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 0.0.0.0/00.0.0.0/0 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 script quoted above:

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

Note1: in the original setup, the script contains a (not security related) bug 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 be 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 not 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 \ -i $IFACE_WWW -j ACCEPT

Normally this results in following ruleset chain: input ACCEPT tcp ------ 0xFF 0x00ppp0 0.0.0.0/00.0.0.0/0 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 connections 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

Exploit:

There is currently no exploit known to break into BenHur's administration web interface. One plausible version, which iterates a dictionary and brute-forces 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6-2 (MingW32)

iD8DBQE9O8r0znfbvpHmKq4RAmdIAKD+TGUh0e9Y0aBuafZZHpeKGFHkSACg2sle UUtBDBY2HuhaD7sZLDK0zKM= =6wbb -----END PGP SIGNATURE-----