Re: FireWall-1 FTP Server Vulnerability

[pjb1008 () CAM AC UK (Peter Benie)]

monti writes ("Re: FireWall-1 FTP Server Vulnerability"):
> STAT -1
> 213-status of -1:
> .
> ..
> 227 Entering Passive Mode (xxx,xxx,xxx,xxx,0,139)
> [snip]
> 213 End of Status

Strictly speaking, the ftp server is breaking the FTP protocol.
The server is required to pad the beginning of '227 ' to prevent it
from being interpreted as a reply code (rfc959, section 4.2). This is
the case even if the digits don't match the first line ('213-').

Since the firewall depends on having an accurate model of the internal
state of the FTP server, it is difficult to construct a firewall to
protect a server that doesn't follow the standard. In the above text,
the firewall potentially could detect the bogus response by comparing
the numbers, but it's likely that a '213 ' could be inserted in the
response before the '227 ' without much difficulty.

> I dont really think the issue is with 'how' the PASV response and packet
> appears on the wire, but with the Firewall's logic in creating a hole for
> PASV ftp data connections. I think the firewall should probably be a bit
> more strict about how it makes the decision to open the PASV hole and
> follow rules like the following:
>
> First watch for:
> client -> ftp-server "PASV"
>
> which triggers the firewall to look for this immediately afterwards:
> client <- ftp-server "227 Entering Passive Mode (xxx,xxx,xxx,xxx,prt,prt)
>
> If any other statement is seen from client or server, before the presence
> of the 227 port declaration, the attempt is ignored.

That might not work. Using the technique you describe above for
getting the server to send the '227 ' response, and by adjusting the
length of the directory listing, you can arrange for '227 ' to be at
the start of a packet. By arranging for a PASV request to the sent to
the server at the right time, the firewall will see 'PASV' in one
direction followed by a '227 ' in the other direction. Unless the
firewall is keeping careful track of when a response is complete, it
will be fooled by this.

A small problem with this is that the ftp server will eventually
process the PASV request itself, which will change which port is
opened in the firewall. There are a couple of workarounds. You could
make the directory list after the '227 ' response very long indeed, or
you could sobotage the CRLF sequence that precedes the PASV by doing
invalid telnet option negotiation (the ftp server and firewall
probably interpret these differently, though the firewall may well
filter out such negotiation).

Even with the best firewall in the world, I'm pretty convinced that
you need an ftp server that implements the FTP protocol correctly
before you have a hope of handling PASV correctly.

Peter