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

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.