A simple TCP spoofing attack – Over the past few years TCP sequence number prediction attacks have become a real threat against unprotected networks, taking advantage of the inherent trust relationships present in many network installations. TCP sequence
number prediction attacks have most commonly been implemented by opening a series of connections to the target host, and attempting to predict the sequence number which will be used next. Many operating systems have
therefore attempted to solve this problem by implementing a method of generating sequence numbers in unpredictable fashions. This method does not solve the problem.

This advisory introduces an alternative method of obtaining the initial sequence number from some common trusted services. The attack presented here does not require the attacker to open multiple connections, or flood a port on the trusted host to complete the attack. The only requirement is that source routed packets can be injected into the target network with fake source addresses.

This advisory assumes that the reader already has an understanding of how TCP sequence number prediction attacks are implemented. The impact of this advisory is greatly diminished due to the large number of

organizations which block source routed packets and packets with addresses inside of their networks. Therefore we present the information as more of a ‘heads up’ message for the technically inclined, and to re-iterate that
the randomization of TCP sequence numbers is not an effective solution against this attack.

The problem occurs when particular network daemons accept connections with source routing enabled, and proceed to disable any source routing options on the connection. The connection is allowed to continue, however the reverse route is no longer used. An example attack can launched against the in.rshd daemon, which on most systems will retrieve the socket options via getsockopt() and then turn off any dangerous options via setsockopt().

Host C spoofing Host A <SYN> –> Host B in.rshd

Host B receives the initial SYN packet, creates a new PCB (protocol
control block) and associates the route with the PCB. Host B responds,
using the reverse route, sending back a SYN/ACK with the sequence number.

Host C spoofing Host A <– <SYN/ACK> Host B in.rshd

Host C responds, still spoofing host A, acknowledging the sequence number.
Source routing options are not required on this packet.

We now have an established connection, the accept() call completes, and control is now passed to the in.rshd daemon. The daemon now does IP options checking and determines that we have initiated a source routed

connection. The daemon now turns off this option, and any packets sent thereafter will be sent to the real host A, no longer using the reverse route which we have specified. Normally this would be safe, however the attacking host now knows what the next sequence number will be. Knowing this sequence number, we can now send a spoofed packet without the source routing options enabled, pretending to originate from Host A, and our command will be executed.

It should be noted that the sequence number is obtained before accept() has returned and that this cannot be prevented without turning off source routing in the kernel.

As a side note, we’re very lucky that TCP only associates a source route with a PCB when the initial SYN is received. If it accepted and changed the ip options at any point during a connection, more exotic attacks may be possible.
These could include hijacking connections across the internet without playing a man in the middle attack and being able to bypass IP options checking imposed by daemons using getsockopt(). Luckily *BSD based TCP/IP stacks will
not do this, however it would be interesting to examine other implementations.

The impact of this attack is similar to the more complex TCP sequence number prediction attack, yet it involves fewer steps, and does not require us to ‘guess’ the sequence number. This allows an attacker to execute
arbitrary commands as root, depending on the configuration of the target system. It is required that trust is present here, as an example, the use of .rhosts or hosts.equiv files.

The ideal solution to this problem is to have any services which rely on
IP based authentication drop the connection completely when initially
detecting that source routed options are present. Network administrators
and users can take precautions to prevent users outside of their network
from taking advantage of this problem. The solutions are hopefully already
either implemented or being implemented. A simple TCP spoofing attack1. Block any source routed connections into your networks
2. Block any packets with internal based address from entering your network.Network administrators should be aware that these attacks can easily be
launched from behind filtering routers and firewalls. Internet service
providers and corporations should ensure that internal users cannot launch
the described attacks. The precautions suggested above should be implemented
to protect internal networks. A simple TCP spoofing attack

Example code to correctly process source routed packets is presented here
as an example. Please let us know if there are any problems with it.
This code has been tested on BSD based operating systems.

u_char optbuf[BUFSIZ/3];
int optsize = sizeof(optbuf), ipproto, i;
struct protoent *ip;

ipproto = ip->p_proto; A simple TCP spoofing attack
else
ipproto = IPPROTO_IP;
if (!getsockopt(0, ipproto, IP_OPTIONS, (char *)optbuf, &optsize) &&
optsize != 0) {
for (i = 0; i < optsize; ) { A simple TCP spoofing attack
u_char c = optbuf;
if (c == IPOPT_LSRR || c == IPOPT_SSRR)
exit(1);
if (c == IPOPT_EOL)
break;
i += (c == IPOPT_NOP) ? 1 : optbuf[i+1];
}
}

We believe the following information to be accurate, however it is not
guaranteed.— CiscoTo have the router discard any datagram containing an IP source route option
issue the following command:

no ip source-route

This is a global configuration option.

Versions of NetBSD prior to 1.2 did not provide the capability for disabling
source routing. Other versions ship with source routing ENABLED by default.
We do not know of a way to prevent NetBSD from accepting source routed packets.
NetBSD systems, however, can be configured to prevent the forwarding of packets
when acting as a gateway.To determine whether forwarding of source routed packets is enabled,
issue the following command:# sysctl net.inet.ip.forwarding
# sysctl net.inet.ip.forwsrcrt

The response will be either 0 or 1, 0 meaning off, and 1 meaning it is on.

Forwarding of source routed packets can be turned off via:

# sysctl -w net.inet.ip.forwsrcrt=0

Forwarding of all packets in general can turned off via:

# sysctl -w net.inet.ip.forwarding=0

BSDI has made a patch available for rshd, rlogind, tcpd and nfsd. This
patch is available at:ftp://ftp.bsdi.com/bsdi/patches/patches-2.1OR via their patches email server <patches@bsdi.com>

The patch number is
U210-037 (normal version)
D210-037 (domestic version for sites running kerberized version)

Previous versions ship with source routing ENABLED by default. As far as
we know, BSD/OS cannot be configured to drop source routed packets destined
for itself, however can be configured to prevent the forwarding of such
packets when acting as a gateway.To determine whether forwarding of source routed packets is enabled,
issue the following command:# sysctl net.inet.ip.forwarding
# sysctl net.inet.ip.forwsrcrt

The response will be either 0 or 1, 0 meaning off, and 1 meaning it is on.

Forwarding of source routed packets can be turned off via:

# sysctl -w net.inet.ip.forwsrcrt=0

Forwarding of all packets in general can turned off via:

# sysctl -w net.inet.ip.forwarding=0

Ships with source routing turned off by default. To determine whether source
routing is enabled, the following command can be issued:# sysctl net.inet.ip.sourcerouteThe response will be either 0 or 1, 0 meaning that source routing is off,
and 1 meaning it is on. If source routing has been turned on, turn off via:

# sysctl -w net.inet.ip.sourceroute=0

This will prevent OpenBSD from forwarding and accepting any source routed
packets.

Ships with source routing turned off by default. To determine whether source
routing is enabled, the following command can be issued:# sysctl net.inet.ip.sourcerouteThe response will be either 0 or 1, 0 meaning that source routing is off,
and 1 meaning it is on. If source routing has been turned on, turn off via:

# sysctl -w net.inet.ip.sourceroute=0

— Linux

Linux by default has source routing disabled in the kernel.

— Solaris 2.x

Ships with source routing enabled by default. Solaris 2.5.1 is one of the
few commercial operating systems that does have unpredictable sequence
numbers, which does not help in this attack.

We know of no method to prevent Solaris from accepting source routed
connections, however, Solaris systems acting as gateways can be prevented
from forwarding any source routed packets via the following commands:

# ndd -set /dev/ip ip_forward_src_routed 0

You can prevent forwarding of all packets via:

# ndd -set /dev/ip ip_forwarding 0

These commands can be added to /etc/rc2.d/S69inet to take effect at bootup.

We know of no method to prevent SunOS from accepting source routed
connections, however a patch is available to prevent SunOS systems from
forwarding source routed packets.This patch is available at:ftp://ftp.secnet.com/pub/patches/source-routing-patch.tar.gz

To configure SunOS to prevent forwarding of all packets, the following
command can be issued:

# echo “ip_forwarding/w 0” | adb -k -w /vmunix /dev/mem
# echo “ip_forwarding?w 0” | adb -k -w /vmunix /dev/mem

The first command turns off packet forwarding in /dev/mem, the second in
/vmunix.

— HP-UX

HP-UX does not appear to have options for configuring an HP-UX system to
prevent accepting or forwarding of source routed packets. HP-UX has IP
forwarding turned on by default and should be turned off if acting as a
firewall. To determine whether IP forwarding is currently on, the following
command can be issued:

# adb /hp-ux
ipforwarding?X <- user input
ipforwarding:
ipforwarding: 1
#

A response of 1 indicates IP forwarding is ON, 0 indicates off. HP-UX can
be configured to prevent the forwarding of any packets via the following
commands:

# adb -w /hp-ux /dev/kmem
ipforwarding/W 0
ipforwarding?W 0
^D
#

AIX cannot be configured to discard source routed packets destined for itself,
however can be configured to prevent the forwarding of source routed packets.
IP forwarding and forwarding of source routed packets specifically can be
turned off under AIX via the following commands:To turn off forwarding of all packets:# /usr/sbin/no -o ipforwarding=0

To turn off forwarding of source routed packets:

# /usr/sbin/no -o nonlocsrcroute=0

Note that these commands should be added to /etc/rc.net

If shutting off source routing is not possible and you are still using
services which rely on IP address authentication, they should be disabled
immediately (in.rshd, in.rlogind). in.rlogind is safe if .rhosts and
/etc/hosts.equiv are not used.

Thanks to Niels Provos <provos@physnet.uni-hamburg.de> for providing
the information and details of this attack. You can view his web
site at http://www.physnet.uni-hamburg.de/provosThanks to Theo de Raadt, the maintainer of OpenBSD for forwarding this
information to us. More information on OpenBSD can be found at
http://www.openbsd.org A simple TCP spoofing attackThanks to Keith Bostic <bostic@bsdi.com> for discussion and a quick
solution for BSD/OS.

Thanks to Brad Powell <brad.powell@west.sun.com> for providing information
for Solaris 2.x and SunOS 4.x operating systems.

Thanks go to CERT and AUSCERT for recommendations in this advisory.

You can contact the author of this advisory at oliver@secnet.com

The contents of this advisory are Copyright (C) 1997 Secure Networks Inc,
and may be distributed freely provided that no fee is charged for
distribution, and that proper credit is given. You can find Secure Networks papers at ftp://ftp.secnet.com/pub/papers
and advisories at ftp://ftp.secnet.com/advisoriesYou can browse web site at http://www.secnet.com

You can subscribe to our security advisory mailing list by sending mail to
majordomo@secnet.com with the line “subscribe sni-advisories”

A simple TCP spoofing attack