A simple TCP spoofing attack

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.

Technical Details

~~~~~~~~~~~~~~~~~

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

An example attack follows.

Host A is the trusted host

Host B is the target host

Host C is the attacker

Host C initiates a source routed connection to in.rshd on host B, pretending

to be host A.

Host C spoofing Host A-->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 AHost B in.rshd

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.

In some conditions the flooding of a port on the real host A is required

if larger ammounts of data are sent, to prevent the real host A from

responding with an RST.This is not required in most cases when performing

this attack against in.rshd due to the small ammount of data transmitted.

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.

Impact

~~~~~~

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.

Solutions

~~~~~~~~~

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.

1. 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.

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 optbufBUFSIZ/3;

int optsize = sizeof(optbuf), ipproto, i;

struct protoent *ip;

if ((ip = getprotobyname("ip")) != NULL)

ipproto = ip->p_proto;

else

ipproto = IPPROTO_IP;

if (!getsockopt(0, ipproto, IP_OPTIONS, (char *)optbuf,