Vulnerability Development: Re: FTP Passive Connection Hijacking Script

[Tomasz Grabowski <cadence () APOLLO ACI COM PL>]

> > From the home page:
> This PERL script is a proof-of-concept exploit for downloading other
> user's files
> from FTP servers without needing thier authentication. It works against
> servers
> that use passive connections for data transfers and fail to check the
> incoming address of the data connection.
It is also pissible to hijack active connections. But this time You have
to connect to the client port.
Checking the incoming address of the data connection is not enough.
Attacker can be on the same server that the victim is (on the client or
server). AFAIK there is no 100% way to stop that kinds of attacks even
with properly configured firewall.

I think that the only way to stop these attacks is to add an feature to
communication between client and server.

Let's look at the usual communication between client and server.
In this scenario the server will make active open:



client                                  server

the client is opening port 10700 in this point

---PORT 10700 ---- >
                          <---- PORT 10700 OK -----
   ---LIST ---------- >
                          <---- LIST ok -----------

// in this point the server will start active open

                          <----- TCP SYN 10700
   ----- TCP ACK ----->
                          <----- sending data

[...]


I made an beta versions of FTP server and client that works this way:



client                          server

---PORT 10700 ---- >
                          <---- PORT 10700 OK -----

   ---CODE random1 -- >
                          <---- CODE OK -----------
   ---LIST ---------- >
                          <---- LIST ok -----------

the client is opening port 10700 in this point

// the server will start active connection in this point

                          <----- TCP SYN 10700
   ----- TCP ACK ----->
                          <----- CODE random1
   ----- CODE OK ----->

AFTER that client will receive data

                          <----- sending data

[...]


What it is all about?
The client is generating random code "random1" (it can do this the same
way that the SYN number is generated).
When the server will connect to clients port, he must send him that
"random1" number. After that the clinet will accept data.

That's all.
It's easy to implement I think.
ANother important think is that "new" clients can easly communicate with
"old" servers and "old" clients with "new" servers.
In case the CODE will not been sent by client, the server will not go
into "secure mode".
If client will send CODE command, and the server will return "command
unrecognized", the client will not enter into "secure mode".


Opinions are wolcome.



___
[Tomasz Grabowski] {Akademickie Centrum Informatyki}
(cadence () apollo aci com pl)



Below is the translation of my description of such attacks.
Anyone who can't understand why such attacks are possible should read it.



> Author:
> Tomasz Grabowski (Network Security Analyst at the Academic Centre of
> Computer Science - Technical University of Szczecin, Poland)
> Translation:
> Dominik Miklaszewski (WAN Security Analyst)
>
> Intro
> -----
>
> For last two days I've been busy of studying FTP core functionalities.
> What I have noticed
> seems to me at least troublesome. Generally speaking it shouldn't be
> used for anything, but anonymous
> transfers from public FTP sites. From security standpoint using such
> tools like SSH/sftp is a must.
> Below I explained the issue with details why the FTP transfers are
> dangerous and virtually useless if we take  security of our network
> seriously (that includes client side).
>
> How does a standart FTP session look like?
> ------------------------------------------
>
> A client initiate a session from port >1023 to port 21 on a remote
> server. This one provides control functions.
> When the client has released a command that implies with any sort of
> data transfer (LIST, DIR, GET, PUT..)
> there is a need of other channel to be set up. The initialization od
> data-channel can done passively or actively.
>
> Active Mode
> -----------
>
> 1. The client machine opens up a local port with >1023 (i.e. 4010) and
> starts listening for the
> transmission from the server.
> 2. Then the client sends out PORT command to the server with a hostname
> and port number as the server
> has to know where the data (i.e. results of issuing LIST command) is to
> be sent.
> 3. The server sends out a confirmation on PORT command and sends out the
> data from port 20.
>
> Passive Mode
> ------------
> 1. The client sends out information to the server that the incoming
> session is going to be in the PASSIVE mode.
> 2. The server opens up a port (randomly above 1023) ans starts listening
> over.
> 3. The server sends out the information about the opened port to the
> client.
> 4. The clients starts sending out commands.
>
> Where are those damn holes?
> ---------------------------
>
> At first place we'll talk about ACTIVE mode.
> The client opens up a port for the server BEFORE the PORT command is
> issued.
> It is OK according to the RFC specification. Anyways, it gives an
> attacker an opportunity to
> connect to that initialized port with i.e. telnet and then wait until
> the remote server sends
> out a confirmation on the received PORT command. Since then on regarding
> to what data command is issued anything that the attacker sends to the
> client's port will be taken as a legal transmission from the server.
>
> The very example can be the RETR command:
> The attacker can shuffle off it's own "trojanized" version of a binary
> in place of the legal binary
> being downloaded from the server. Moreover if the trojanized version
> fits to the TCP outbound buffer
> the server will take is for its own file that has been downloaded
> shortly.
>
> The other example is the STOR command:
> In this case will get what the client is willing to upload the server
> with.
> This may result in obvious security problems.
>
> A proof of concept
> ------------------
>
> The client sits on rubycon
> The server is on phobos
>
> > rubycon:~$ ftp -d
> > ftp> open phobos
> > Connected to phobos.
> > 220 ProFTPD 1.2.0pre10 Server (csdsd) [phobos]
> > Name (phobos:cad): cad
> > ---> USER cadence
> > 331 Password required for cad.
> > Password:
> > ---> PASS XXXX
> > 230 User cadence logged in.
> > ---> SYST
> > 215 UNIX Type: L8
> > Remote system type is UNIX.
> > Using binary mode to transfer files.
> > ftp> cd stevens
> Now we're on the server in the subfolder named "stevens", we'd like to
> see what's in there:
> (in the meantime to
>
> > ftp> dir
> > ftp: setsockopt (ignored): Permission denied
> > ---> PORT xxx,xxx,xxx,xxx,16,219
> (the port number is 16:256+219 = 4316) -> it's easy to obtain that
> information by a careful portscan
>
> (in the meantime I have connected to that port from the other machine)
> > telnet rubycon 4316
> > Trying xxx.xxx.xxx.xxx...
> > Connected to rubycon.
> > Escape character is '^]'.
> (now, get back to rubycon and let's issue the LIST command)
> > 200 PORT command successful.
> > ---> LIST
> > 150 Opening ASCII mode data connection for file list.
> (at this time the remote FTP server (phobos) is trying to get to the
> opened port on rubycon
>  and it fails as there is already established connection from the other
> host, nonetheless the FTP server
>  doesn't care as long as it successfully can send out data for the
> issued LIST command.
>  Now, let's check out what happens when we input some trash in the
> existing telnet session:)
>
> > dfgdfg
> > dfgdfgdfgdfg
> > dfgdfgdfgdfgdfgdfgd
> (here is what we get on our ftp session on rubycon as a result of issued
> LIST command:)
>
> > 150 Opening ASCII mode data connection for file list.
> > dfgdfg
> > dfgdfgdfgdfg
> > dfgdfgdfgdfgdfgdfgd
> > e226 Transfer complete.
> > ftp>
> Everything looks fine at both client's and server's side..
>
> How to attack PASSIVE mode transmission? The method is exactly the same,
> the oonly change is that
> a one connects to a port on the server.
>
> ----- the end of the article -------------------