OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
From: Paul Starzetz (paul_at_starzetz.de)
Date: Fri Oct 18 2002 - 09:46:55 CDT

  • Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

    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

    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