Re[2]: IPSwitch, Inc. WS_FTP Server

[3APA3A <3APA3A () SECURITY NNOV RU>]

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
Почтенные ископаемые! Жду от вас дальнейших писем.  (Твен)