A simple TCP spoofing attack__warning this is just for information!!!

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

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

Host C spoofing Host A             -->  Host 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