Vulnerability Development mailing list archives
Re: FTP Passive Connection Hijacking Script
From: Tomasz Grabowski <cadence () APOLLO ACI COM PL>
Date: Tue, 25 Jul 2000 22:33:08 +0200
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 phobosrubycon:~$ 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 stevensNow we're on the server in the subfolder named "stevens", we'd like to see what's in there: (in the meantime toftp> 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 -------------------
Current thread:
- FTP Passive Connection Hijacking Script H D Moore (Jul 24)
- <Possible follow-ups>
- Re: FTP Passive Connection Hijacking Script Tomasz Grabowski (Jul 27)
- Re: FTP Passive Connection Hijacking Script Michael Wojcik (Jul 28)
- Re: FTP Passive Connection Hijacking Script Bluefish (Jul 30)