RE: Ambiguities in TCP/IP - firewall bypassing

["Ofir Arkin" <ofir () sys-security com>]

I would like to refer you back to a March 2000 Bugtraq post:
http://online.securityfocus.com/archive/1/52793

The flag combinations with that post relate to Linux 2.2.x and Windows
NT 4 SP6 (and not to all *nix as it states). It is also advised to read
a reply from Lamont Granquist -
http://online.securityfocus.com/archive/1/52939. 

I have also stated with that post that:
"The Filtering Device is lame:
If the firewall is just a simple packet filter that blocks incoming
SYN's than some of the combinations I have listed would elicit a reply.
If the Firewall is statefull (AND do his job as it should. I have seen
some idiotically cases were statefull was not implemented as it should)
nothing should pass it."


As a side note - although the RFCs are not specific regarding the
question on how to handle several different flag combinations, there is
also a common sense that needs to be applied. For example, sending a TCP
packet with the SYN|FIN flags on is known to be an OS fingerprinting
attempt, a fact known for several years now (even appears on several
text books :P). 

I do expect firewall manufactures to provide some kind of protection and
filtering for non-logical and non-legitimate TCP/IP traffic, but as I
noted back in March 2000, still there are some firewalls and filtering
devices that let this traffic go by.


Yours,
Ofir Arkin [ofir () sys-security com]
Founder
The Sys-Security Group
http://www.sys-security.com
PGP CC2C BE53 12C6 C9F2 87B1 B8C6 0DFA CF2D D360 43FA

-----Original Message-----
From: Paul Starzetz [mailto:paul () starzetz de] 
Sent: Friday, October 18, 2002 4:47 PM
To: bugtraq () securityfocus com
Subject: Ambiguities in TCP/IP - firewall bypassing

1. Abstract
-----------

There are ambiguities in implementations of the TCP/IP suite for various

operating systems. Even if this fact has been used since a long time in 
different software for OS fingerprinting, no real attempt has been made 
to identify the security impact of the differences in the TCP/IP 
semantics. We have done some research on the TCP/IP connection open 
semantics which is of course very important for security of networked 
systems. We believe that the flaws we have detected have a big impact on

design of firewalls and packet filters since an improper implementation 
can easily lead to serious security problems.


2. Details
----------

The TCP/IP protocol stack offers a three way handshake for connection 
oriented communication using the TCP protocol. Basically, a connection 
can be opened by sending a synchronization packet to a listening service

on a particular host. The host will respond with a synchronization 
acknowledgment packet which in turn must be acknowledged by the 
requesting host. Then, the connection is considered to be open (at least

at the transport layer) and the two hosts may exchange some data.

The three way handshake is an essential part of the communication using 
the TCP protocol. Therefore many packet filter firewalls try to prevent 
the three way handshake from completion in order to protect an 
internal/corporate network from being accessed from the outside. Of 
course, statefull firewalls may have some more sophisticated mechanism.

We have found a very ambiguous behavior of TCP/IP implementations while 
doing some research on the connection request phase. Below you will find

the findings about various OSes, however the list should not be 
considered complete. We have used the NemesisTCP tool [1] to generate 
the traffic and tcpdump to capture the responses.

* The normal behavior (of all OSes) is like this:

14:18:00.595517 192.168.1.184.12345 > 192.168.1.111.9999: S 420:420(0) 
win 512 (DF) [tos 0x18]
14:18:00.595731 192.168.1.111.9999 > 192.168.1.184.12345: S 
1679763291:1679763291(0) ack 421 win 5840 <mss 1460> (DF)

The first host sends a SYN packet from port 12345 to a service on port 
9999 and receives a SYN,ACK


* Linux 2.4.19

The examination of the source code of the TCP engine reveals that a TCP 
connection can be opened by any combination of the TCP flags having the 
SYN bit set and the ACK bit reset. For example we can open a TCP 
connection by sending an obviously bogus SYN,RST packet:

14:25:43.888897 192.168.1.184.12345 > 192.168.1.111.9999: SR 420:420(0) 
win 512 (DF) [tos 0x18]
14:25:43.889143 192.168.1.111.9999 > 192.168.1.184.12345: S 
2168208394:2168208394(0) ack 421 win 5840 <mss 1460> (DF)

or something called 'Christmas packet' having mostly every TCP flag set 
(except the ACK flag of course):

14:30:46.341732 192.168.1.184.12345 > 192.168.1.111.9999: SFRP 
420:420(0) win 512 urg 8 (DF) [tos 0x18]
14:30:46.342444 192.168.1.111.9999 > 192.168.1.184.12345: S 
2492223280:2492223280(0) ack 421 win 5840 <mss 1460> (DF)

Also SYN,FIN packets works well...


* Solaris 5.8

Here we have success by sending SYN,FIN packets:

14:33:24.549246 192.168.1.184.12345 > 192.168.1.84.9999: SF 420:420(0) 
win 512 (DF) [tos 0x18]
14:33:24.549757 192.168.1.84.9999 > 192.168.1.184.12345: S 
913533039:913533039(0) ack 421 win 24656 <mss 1460> (DF)

or SYN,FIN,PSH packets with no payload

14:35:14.398346 192.168.1.184.12345 > 192.168.1.84.9999: SFP 420:420(0) 
win 512 (DF) [tos 0x18]
14:35:14.398801 192.168.1.84.9999 > 192.168.1.184.12345: S 
940377913:940377913(0) ack 421 win 24656 <mss 1460> (DF)

other combinations don't seem to induce the SynSent state in the TCP/IP 
stack


* FreeBSD 4.5

Here we also have luck with SYN,FIN packets:

14:47:21.558541 192.168.1.184.12345 > 192.168.1.104.9999: SF 420:420(0) 
win 512 (DF) [tos 0x18]
14:47:21.558719 192.168.1.104.9999 > 192.168.1.184.12345: S 
1333327436:1333327436(0) ack 421 win 65535 <mss 1460>

as well as with other combinations which don't combine the RST and/or 
ACK flag with SYN:

14:48:11.678246 192.168.1.184.12345 > 192.168.1.104.9999: SP 420:420(0) 
win 512 (DF) [tos 0x18]
14:48:11.678366 192.168.1.104.9999 > 192.168.1.184.12345: S 
1714046856:1714046856(0) ack 421 win 65535 <mss 1460>


* Windows NT 4.0

As in the case of BSD we can open connections using any combination of 
TCP flags as long as we do not set the RST and/or ACK flag (where did 
they take the code from...hm...):

14:59:46.315126 192.168.1.184.12345 > 192.168.1.17.9999: SF 420:420(0) 
win 512 (DF) [tos 0x18]
14:59:46.315566 192.168.1.17.9999 > 192.168.1.184.12345: S 
15062452:15062452(0) ack 421 win 8576 <mss 1460> (DF)


Other OSes than those tested above are expected to behave in a similar 
manner after obtaining such a discouraging result...


3. Impact
---------

The ambiguities can be used to bypass/tunnel firewalls filtering TCP 
packets according to the TCP flags set. Especially stateless firewalls 
simply comparing the flags field with some expected value(s) to 
distinguish between synchronization packets and packet from an already 
open connection can be easily bypassed just by sending a bogus 
synchronization packet to a listening port. The currently deployed TCP 
stacks seem to be highly bogus and lazy implemented.

Administrators of firewall devices should set up some filtering rules to

drop bogus TCP packets as mentioned above. For example on systems using 
iptables to filter packets bogus packets can be easily distinguished by 
following rules:

iptables -A INPUT -p tcp -d HOST/MASK --tcp-flags SYN,FIN SYN,FIN -j LOG

-m limit --limit 10/m --log-level "LOGLEVEL" --log-prefix="bogus packet"
$IP -A INPUT -p tcp -d HOST/MASK --tcp-flags SYN,FIN SYN,FIN -j DROP

and so on for other flag combinations.


4. References
-------------

[1] NemesisTCP: http://online.securityfocus.com/tools/1278
[2] Packet normalization: 
http://www.icir.org/vern/papers/norm-usenix-sec-01-html