-----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-----
