On 1997-12-10 at 16:47:35, Aleph One posted CERT's words: > In some implementations of FTP daemons, the PORT command can be > misused to open a connection to a port of the attacker's choosing on > a machine that the attacker could not have accessed directly. There > have been ongoing discussions about this problem (called "FTP > bounce") for several years, and some vendors have developed solutions > for this problem. The keyword is "for several years", and CERT now has acted. But back to non-organizational problems to be ahead of them as usual. A similar weakness in the FTP protocol involves the passive transfer mode, which is the opposite of the active one, about which the above advisory was. Let's examine a hypothetical FTP session: $ telnet ftp ftp Trying 127.0.0.3... Connected to ftp. Escape character is '^]'. 220 you have to log in. user someuser 331 i need your password. pass pass 230 you seem to be welcome. pasv 227 Passive mode OK (127,0,0,3,197,9) list ... And the server is now waiting for a connection to port 50441, and (about the same vein than with the PORT insecurity) it accepts mostly any client connecting to it and sends the data to it. The problem is that this is all after authenticating the user, so anyone could have anyones data, even if it needs one time passwords, and so on. The only hope to avoid this is just hoping that's a too small chance to get to the server before the attacker, since there is a time window, and the port number is also a secret. (Un)fortunately, there are only 65536 ports, and many servers schedule port numbers sequentially. Now, one only needs to be so lucky to race someone with a passive connection. The other part of the problem is that most of the browsers (maybe recognizing the insecurity of the active ftp, and the easeness of implementation, and for the sake of working through firewalls) uses passive ftp, so it's not that hard to find a passive connection. Theoretically, this attack is much harder to exploit, but the consequences are pretty serious. It's possible to fetch anyones file if she's using passive ftp connections (i.e. most browsers), even if she used strong authentication like one time passwords with plain old ftp. The trick is simply to telnet randomserver.isp randomport, and you have a chance of getting someones sensitive data. You'll have higher chances if the server is more busy, is farther from the client, or you tried a passive connection to fetch the current port number. Also with unix ftp clients, the attacked person simply sees this success as an empty directory, nothing suspicious. Sometimes, the server logs do not even show the attackers IP address, just as if the client fetched the file successfully. Avoidance: it might be fruitful to reduce the chances of success by randomizing the port numbers used by the server, but that's pretty unuseful in itself. The other is a similar check for the data connection's client ip address, it needs to be the same as the control connections client. And, of course, never use ftp for anything private. -- Janos - Don't worry, my address is real. I'm just bored of spam.
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 13:35:30 PDT