---------- Forwarded message ----------
Date: Thu, 19 Apr 2001 11:27:06 -0700
From: Scott Lampert <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: ip_conntrack_ftp vulnerability?
Has anyone seen this issue on Slashdot yet?
http://www.tempest.com.br/advisories/01-2001.html
Since the site is very slow due to the infamous Slashdot effect, the
text of the overview is posted below.
It would seem that allowing FTP access into your network is bad news at
the moment..
--
Scott Lampert
<[EMAIL PROTECTED]>
http://www.lampert.org
"Sing the Hare Hare, Dance the Hoochie Koo!"
##########################################################################
Systems affected: Firewalls using Linux Kernel 2.4.x with IPTables
Release date: 16 April 2001
Platforms: Linux Kernel 2.4.x
Bugtraq ID: 2602
Impact: If an attacker can establish an FTP connection passing through a
Linux 2.4.x IPTables firewall with the state options allowing "related"
connections (almost 100% do), he can insert entries into the firewall's
RELATED ruleset table allowing the FTP Server to connect to any host and
port protected by the firewalls rules, including the firewall itself.
Linux 2.4.x includes NetFilter, a raw framework for filtering and
mangling packets. IPTables, used for firewalling, is set inside the
NetFilter framework. One of the new features in this setting is
connection tracking, known to some as "stateful inspection". The four
possible states it can mantain are: ESTABLISHED, NEW, RELATED and
INVALID. We are interested here in the RELATED state -- it includes,
among other things, the FTP DATA connections, active (PORT command) and
passive (PASV command).
The module ip_conntrack_ftp is responsible for analysing FTP connections
that pass through the firewall, looking for PORT and PASV commands, and
including entries for those connections in the firewall's connection
table. There is a security flaw in the manner in which the PORT command
is interpreted and processed. Essentially, you can pass any IP/port in
an FTP PORT commmand, and the module will not validate these parameters,
adding an entry to the RELATED ruleset allowing connections from the FTP
server, any source port, to the specified destination IP and port. In
most cases, people make stringent security rules and have lax firewall
rules regarding RELATED connections, allowing the attacker to connect to
anywhere.
This can be used, for example, for the FTP server to connect to any TCP
port on the firewall, or any other node protected by the firewall. Even
though there may be rules normally denying this type of traffic, it
would pass through the firewall, because of the rule allowing RELATED.
The attacker does not even need to have a valid login in the FTP server,
as the PORT command is interpreted by the module independently of any
authentication procedures (USER and PASS).
This is a security flaw which can be exploited when an attacker is in a
position behind your firewall, i.e., "protected". For example, if your
firewall protects an FTP Server and the attacker has compromised it by
other means, he can use this to connect to other protected networks. Or,
if your attacker is behind your firewall as a client and connects to an
FTP server on the Internet, he can use it to allow this FTP server to
connect to other protected networks.
<http://www.tempest.com.br/imagens/setas2.gif> Detailed description
Most firewall setups using IPTables include the following rule, for
allowing established and related connections through:
iptables -A FORWARD -m state --state ESTABLISHED, RELATED -j ACCEPT
The "related" state includes connections such as the FTP data transfer
connections, both active and passive modes. If related connections and
FTP are allowed through the firewall, then the system is most likely
vulnerable.
The attack consists in connecting to the FTP server (passing through the
firewall) and using the PORT commands with arbitrary IP and port
parameters - the normal parameters should be the client's IP and a
random port.
To explain the process in more details, we'll outline the following
scenario:
* Client IP: 200.249.243.12, an IP on the internet
* Firewall: 200.249.137.1 (internet interface) 200.249.193.1 (DMZ
interface)
* FTP server: 200.249.193.2 (inside a DMZ network, protected by the
firewall)
In a normal ftp data transfer, the client would emit the following
command to initiate an active data transfer:
PORT 200,249,243,12,4,10
Which would insert an entry in the connection table (cat
/proc/net/ip_conntrack), of the following form:
EXPECTING: proto=6 src=200.249.193.2 dst=200.249.243.12 sport=0
dport=1034
Allowing a connection from the FTP server to the client in the specified
port. Since the module ip_conntrack_ftp doesn't check the passed IP and
ports, an attacker can pass the following parameters:
PORT 200,249,193,1,0,22
Which would insert an entry in the connection table (cat
/proc/net/ip_conntrack), of the following form:
EXPECTING: proto=6 src=200.249.193.2 dst=200.249.193.1 sport=0 dport=22
Allowing a connection from the FTP server to the firewall, on port 22,
ie, the SSH port. This will work by inserting the rule into the RELATED
ruleset, which as shown above is normally too open. The rule can be
inserted to any destination IP and port.
Of course, the FTP server will probably not accept the command (if it
has anti-bounce protection), saying "Illegal PORT command", but the
firewall will have interpreted the commands and added an "expecting
related" entry as described above to its connection table. The attacker
will then have ten seconds to establish the connection, before the entry
expires and is removed from the connection table.
It is not even necessary to have logged in the FTP server since the
module doesn't check for valid USER and PASS commands. All we have to do
is trick the code into thinking we have established a connection
(IP_CT_ESTABLISHED+IP_CT_IS_REPLY). To do that, it is only necessary to
send any string to the FTP server, which should reply with "invalid
command", and then we send the PORT command with our parameters... The
FTP server will probably be complaining that a login has not been
established yet, but the firewall will have done what we want it to:
220 tsunami FTP server ready.
xxxgarbagexxx
530 Please login with USER and PASS.
PORT 200,249,193,1,0,22
530 Please login with USER and PASS.
QUIT
221 Goodbye.
The implications should be obvious -- we outline two main scenarios of
attack:
* The FTP server is protected by the firewall: in this case, the client
(attacker) would be on the internet. If the FTP server is compromised by
the attacker using other means, the attacker can insert rules allowing
the FTP server to:
* Connect to hosts on the internet, for downloading of trojans,
tools, reverse tunnels, etc;
* Connect to the firewall itself and exploit it from there onwards;
* Connect to other hosts on networks protected by the firewall, such
as an internal network, for example;
* ... use your imagination :)
* The client (attacker) is protected by the firewall: in this case, the
client would connect to an FTP server that he controls on another
network such as the internet (as long as the connection passes through
the firewall). The attacker would insert rules allowing the FTP server
that he controls to:
* Connect to the firewall itself and attack it from there onwards;
* Connect to other hosts on networks protected by the firewall, such
as a DMZ or other networks for example;
* ... again, use your imagination :)
A few observations:
1. From my tests, the use of NAT (NAT of the FTP server, NAT of the
client and NAT of the target) doesn't stop the attack in anyway. Of
course, the attacker will only have to pay attention to which IP he is
connecting to, but the entries are inserted into the connection table
anyway.
2. By default, the ip_conntrack_ftp module only analyses FTP control
connections on port 21, so this would only work on connections to FTP
servers binding on port 21. Unless, obviously, the module were
configured to listen on another port as well.
3. This should not need to be said :) but this attack bypasses the
firewall rules by inserting an entry into the ruleset for RELATED
connections -- for the attack to work, there must be a rule allowing the
client to connect to an FTP server (through the firewall) in the first
place, and the rule allowing the RELATED state for the specified
connection. This is a very common setting, as most firewalls allow their
clients to perform FTP, and the too-open RELATED rule is also very
common -- i've seen it an lots of IPTables FAQs, guides, lists, etc.
---
Send e-mail to '[EMAIL PROTECTED]' with 'unsubscribe rlug' to
unsubscribe from this list.
