Last updated: Wednesday, 24-Mar-1999 23:06:09 EET
The vulnerability was analyzed by:
The data transfer in FTP protocol is realized by creating new TCP connection for each file to be transported. To do this the client (or the server in passive mode) creates listening socket to wait for connections. The other end then connects to this socket. A malicious attacker can then connect to this socket if he makes it before the server (or client) does.
If we succeed to steal connection (to make connection to before the server-client data connection is established) we can either unauthorized learn data or we can replace data with some malicious information. This attack is possible even if the command channel is encrypted.
To be successful, we must have some estimate of port number used. Tested clients and servers did allocate port numbers sequently. To find out the current port number at we can make connect to the server (possibly anonymously) and issue PASV command. Ports used for other connections are around that area. The client side is a bit trickier, but it can be estimated that most operating systems and applications use ports just above 1024 or 32000.
The other precondition for successful attack is enough latency between client and server and small latency between attacker and target machine. On local area network we can reach port scanning around 2000-4000 ports/s but on long distances and lower-bandwidth connections the figure is much lower.
Also the server or client program must be enough ignorant for errors.
The attack can be launced from any location where we can make connections either to client or to the server depending which we want to attack to. The attack is quite time critical and spotting the right connection can be tricky.
As the essential part of this attack is port scanning, this attack can be detected using those tools which detect connect() style port scanning. The attacking system must use it's own IP address so it can be traced.
The client can note this by two means: the server informs about successful file transfer even if the client has failed to connect to the server, or the server informs about failed transfer even if the client has made successfull transfer.
The best protection against this attack is to make both ftp server and client to check where the incoming data connection originates. If it is not the client (server) who is command channel peer, the connection should be rejected. This, however, on server end breaks the third-party initiated transfers.
The another protection is that the client carefully checks return codes from the server and detects any missmatch between those. In some cases, however, the disaster may be happened.
The attack was tested on customized port scanning tool which after finding listening port waited for few seconds to detect if it should write or read from connection.
The port number sequences were tested on servers by opening two simultaneous connections and checking for port numbers in PASV command. On the client side the port number sequences were checked with netstat.
As the experimental network had too little latency, actual connection steal experiments were done on Internet by connecting remote (Australian) locations. This was only aimed for the client end.
The first tested system was a machine running Solaris 2.6. The command line ftp tool reported error conditions but saved or displayed the malicious content. The success rate depened on latency, with around 400 ms latency and scanning area of about 100 ports we archieved nearly 100 % success. The Netscape 4.5 browser used passive mode for ftp connections so it was not vulnerable.
The second system was Windows 95. The WS-FTP acted properly on error codes from the server and didn't save malicious content. Of course, this caused big problems using software as it couldn't get directory listings. Also on Windows the Netscape 4.5 used passive mode. The difficulty in this testing was that Windows crashed after port scanning was carried on for some time.
The servers were tested on experimental network and all servers accepted connections also from other hosts than where the contol connection originated.