Dear Alun Jones, --Friday, October 25, 2002, 9:38:29 PM, you wrote to bugtraq@securityfocus.com: I can't agree with you. 4 years ago I did some researches on this problem with updates on http://www.kb.cert.org/vuls/id/2558. The article which is a result of this researches is in Russian (it also describes file upload attacks and attacks against FTP client). There is short advisory in English. It describes why protection implemented in few well known FTP servers was ineffective. You can find it on http://www.security.nnov.ru/advisories/ftplisten.asp (please don't be too hard on it, it was written 3 years ago). AJ> At 09:06 AM 10/25/2002, dev-null@no-id.com wrote: >>{ Overview } >> >> WS_FTP v3.13 by IPSwitch, Inc., is vulnerable to the classic FTP >> bounce attack as well as PASV connection hijacking. AJ> This start makes me sceptical from the first. A report of old AJ> vulnerabilities known to exist in a protocol, and with existing workarounds AJ> and solutions. Why is this news? There is nothing new in a fact FTP protocol has some dangerous features. New is WS_FTP doesn't prevents this features. >> >> The FTP bounce vulnerability allows a remote attacker to cause the AJ> definition). The server should have a feature to require that all AJ> PORT commands be on the same IP address that connected to the server AJ> in the first place, but there's plenty of people who view this as an AJ> overly restrictive setting, so it might not be the default. Does AJ> WS_FTP Server fail in this regard? Sure. FTP RFC doesn't limit data connection to be on same IP as control connection because of only one reason: for support for direct transmission of file between 2 servers. This is quite dangerous feature used by nobody and it definitely should be disabled by default. It will never cause problems on FTP client (even located on multihomed computers) since any FTP client uses getsockname() for PORT command. >> The PASV connection hijacking vulnerability allows a remote attacker >> to intercept directory listings and file downloads from other users; file >> uploads may also be spoofed. No authentication is necessary to execute >> this attack. More information on this vulnerability can be found here: >> http://www.kb.cert.org/vuls/id/2558. AJ> This is, contrary to the assertion at the web site listed above, a AJ> vulnerability in the _client_. There are several FTP clients that will AJ> send a PASV command followed immediately by a LIST, RETR, STOR, or whatever AJ> command, when they should be first connecting to the PASV port, and AJ> verifying that the connection was accepted before they send the AJ> command. As your example shows, if it is possible to guess the port that a AJ> server will be listening on, it's possible to make a connection to that AJ> port ahead of the client. A client that doesn't bother to consider this AJ> possibility (particularly since it's such a widely-known attack) is AJ> fundamentally flawed. Client you say? Client has no way to know if someone is already connected to DATA port, because even if you do listen(s,1) it will actually listen for more than 1 connection on almost any operation system. So, even if server closes listening socket situation with 2 connections already pending is quite possible. In this case real client feels just like it got empty file. And solutions are: 1. Allocate ports for PASV connection randomly. It will prevent data hijacking in most cases. Note, that if ports for passive connection are allocated one-by-one PASV may be used to portscan FTP host itself. 2. Close listen()ing socket _immediately_ after first connection received. 3. Accept DATA connections only from same IP with CONTROL connection. 4. Pause for some time (10-100ms) before beginning of data transmission. If second connection is received during that period - close both. 5. Close data connection immediately if some input received on control connection. Good security practice is also to implement pause after each "PASV" command. PASV may be used by attacker to predict victim's port for passive FTP connection (one of exploits in advisory above codes demonstrates this technique). -- ~/ZARAZA Почтенные ископаемые! Жду от вас дальнейших писем. (Твен)
