Re[2]: IPSwitch, Inc. WS_FTP Server
From: 3APA3A (3APA3A@SECURITY.NNOV.RU)Date: 10/26/02
- Previous message: Daniel Ahlberg: "GLSA: kth-krb"
- In reply to: Alun Jones: "Re: IPSwitch, Inc. WS_FTP Server"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Date: Sat, 26 Oct 2002 11:41:03 +0400 From: 3APA3A <3APA3A@SECURITY.NNOV.RU> To: Alun Jones <alun@texis.com>
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 Почтенные ископаемые! Жду от вас дальнейших писем. (Твен)
- Previous message: Daniel Ahlberg: "GLSA: kth-krb"
- In reply to: Alun Jones: "Re: IPSwitch, Inc. WS_FTP Server"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
