ISA 2006 Firewall's FTP Filter by default blocks the FTP Clients behind it from connecting to a different IP address returned in the FTP server's response for the PASV Request command

When a FTP client issues the PASV Request command, the FTP server supporting passive mode returns a response, 227 Entering Passive Mode, response which contains an IP address and a TCP port to which the FTP client will connect back in order to open a data connection.
That opens the possibility for an attacker to modify the server's response and enter another IP address(from the original IP address of the FTP server) to which the FTP client to connect. Doing that, the attacker may easily obtain an open TCP connection to another server from the client for various purposes.
For further reading, refer to this paper: Manipulating FTP Clients Using The PASV Command. A summary of this paper can be found here.
As said there, some clients will connect to whatever would be the IP address specified in the FTP server's response for the FTP PASV request command.

So what happens when such a FTP client(in this test Firefox 2.0) is behind the ISA 2006 Firewall, and uses FTP passive mode ?
As you may know, ISA 2006 includes a FTP filter(an application filter), for inspecting FTP traffic, and allowing the needed connections in respect with the PASV response of the FTP server.

First, let's test when the FTP client is not behind ISA. A Wireshark capture shows us what's happening.

client_not_behind_isa_ftp_firefox_pasv

As you can see, the FTP client connects to the 192.168.220.74 FTP server. However, in the response for PASV Request command, the server specifies the 192.168.220.73 IP address to which the FTP client to connect. And the FTP client does that. Note that there aren’t any Passive IP address, Passive Port or Passive IP NAT: True fields in the server’s response, these fields are shown by Wireshark to help us understand easier the FTP conversation. For example, if I select the Passive IP NAT: True field, we can see that no corresponding data in the hex area is selected(because there isn’t any) and Wireshark tells us that NAT is active because the server’s IP address and the IP address from server’s 227 Entering Passive Mode response are different. See Wireshark’s online help for Display Filter Reference: File Transfer Protocol (FTP).

client_not_behind_isa_ftp_pasv_firefox_wr_fields

Let's now put this FTP client behind ISA.
I'm going to start a Wireshark capture on the FTP client and one on the FTP server.

If we look at the one taken on the FTP server, we will see that the server gave the "expected" response for the PASV Request command, however, now, the client terminates the TCP connection(the packet with the FIN flag).

client_behind_isa_ftp_pasv_on server_firefox

If we look at the one taken on the FTP client, we will see that instead of the "expected" response for the PASV Request command, there is a different message, containing the reply code "Syntax error, command unrecognized (500)" and a "500 the server returned invalid response for PASV command" argument, which causes the FTP client to terminate the FTP connection.

client_behind_isa_ftp_pasv_on client_firefox

And Firefox will display the "500 the server returned invalid response for PASV command" message too.

firefox_warning_ftp

So ISA blocked the possible dangerous response. Note that RFC 959 FILE TRANSFER PROTOCOL (FTP), does not mention that the return of a different IP address in the PASV response message is illegal or so. Also ISA 2006's FTP filter does not support the EPSV command. With EPSV(Extended Passive Mode), the FTP server's response will contain only the port number, and the client will assume that it will connect to the same IP address that was originally connected to.

If we repeat the scenario, this time using Opera 9.10 as the FTP client, the same thing can be observed, this time however, the FTP client sends the Quit command too.

Wireshark capture on the FTP server:

client_behind_isa_ftp_pasv_on server_opera

Wireshark capture on the FTP client:

client_behind_isa_ftp_pasv_on client_opera

Other FTP clients may attempt to use active mode if passive mode fails.

So ISA can help mitigate the security issues of such a behavior of the FTP client(assuming there is no real world application for it).

Note: You can publish with ISA 2006 without problems an internal or DMZ located passive FTP server with a FTP server publishing rule(when ISA is doing NAT from Internal to External, or respectively from DMZ to External). Just make sure the FTP server is not configured to return in the 227 Entering Passive Mode response, ISA's external IP address(the public IP address used on ISA to publish that FTP server). Some FTP servers, for example the Filezilla FTP Server, when located behind NAT devices(which cannot understand the FTP traffic), allow you to specify this IP address, see for example Filezilla FTP Server's help file. You do not need to do that with ISA, as ISA's FTP filter will modify on the fly server's 227 Entering Passive Mode response, replacing the internal IP address of the FTP server with ISA's external IP address(the public IP address used on ISA to publish that FTP server, which is the original IP address used to start the FTP connection by the external FTP client). If you do that, ISA will block the server's response, sending to the client the message we saw above, containing the reply code "Syntax error, command unrecognized (500)" and a "500 the server returned invalid response for PASV command" argument, which will cause the external FTP client to terminate the FTP connection. ISA's FTP filter expects in the FTP server's 227 Entering Passive Mode response, the original internal IP address of the FTP server.

Comments are closed