IP spoofing: Demystified

I would have preferred to just post the links but the instructions on the page could be abused. I deliberately left out some parts and my apologies to the Guild Corporation who provided the grant for the paper.

The purpose is to explain IP-spoofing and preventive measures to the members. It assumes little more than a working knowledge of Unix and TCP/IP. Oh, and that you are not a moron... IP-spoofing is complex technical attack that is made up of several components. (In actuality, IP-spoofing is not the attack, but a step in the attack. The attack is actually trust-relationship exploitation. However, in this article, IP-spoofing will refer to the whole attack.) It will explain the attack in detail, including the relevant operating system and networking information.

IP-spoofing consists of several steps, which is briefly outlined, then explained in detail. First, the target host is choosen. Next, a pattern of trust is discovered, along with a trusted host. The trusted host is then disabled, and the target's TCP sequence numbers are sampled. The trusted host is impersonated, the sequence numbers guessed, and a connection attempt is made to a service that only requires address-based authentication. If successful, the attacker executes a simple command to leave a backdoor.

There are a couple of things one needs to wage an attack:

(1) brain, mind, or other thinking device
(1) target host
(1) trusted host
(1) attacking host (with root access)
(1) IP-spoofing software

Generally the attack is made from the root account on the attacking host against the root account on the target. If the attacker is going to all this trouble, it would be stupid not to go for root. (Since root access is needed to wage the attack, this should not be an issue.)

One often overlooked, but critical factor in IP-spoofing is the fact that the attack is blind. The attacker is going to be taking over the identity of a trusted host in order to subvert the security of the target host. The trusted host is disabled using the method described below. As far as the target knows, it is carrying on a conversation with a trusted pal. In reality, the attacker is sitting off in some dark corner of the Internet, forging packets puportedly from this trusted host while it is locked up in a denial of service battle. The IP datagrams sent with the forged IP-address reach the target fine (recall that IP is a connectionless-oriented protocol-- each datagram is sent without regard for the other end) but the datagrams the target sends back (destined for the trusted host) end up in the bit-bucket. The attacker never sees them. The intervening routers know where the datagrams are supposed to go. They are supposed to go the trusted host. As far as the network layer is concerned, this is where they originally came from, and this is where responses should go. Of course once the datagrams are routed there, and the information is demultiplexed up the protocol stack, and reaches TCP, it is discarded (the trusted host's TCP cannot respond-- see below). So the attacker has to be smart and *know* what was sent, and *know* what reponse the server is looking for. The attacker cannot see what the target host sends, but she can *predict* what it will send; that coupled with the knowledge of what it *will* send, allows the attacker to work around this blindness.

After a target is choosen the attacker must determine the patterns of trust (for the sake of argument, we are going to assume the target host *does* in fact trust somebody. If it didn't, the attack would end here). Figuring out who a host trusts may or may not be easy. A 'showmount -e' may show where filesystems are exported, and rpcinfo can give out valuable information as well. If enough background information is known about the host, it should not be too difficult. If all else fails, trying neighboring IP addresses in a brute force effort may be a viable option.

Once the trusted host is found, it must be disabled. (TCP SYN flooding)

The attacking host spoofs her IP address to be that of the trusted host (which should still be in the death-throes of the D.O.S. attack) and sends it's connection request to port 513 on the target (1). At (2), the target responds to the spoofed connection request with a SYN/ACK, which will make it's way to the trusted host (which, if it *could* process the incoming TCP segment, it would consider it an error, and immediately send a RST to the target). If everything goes according to plan, the SYN/ACK will be dropped by the gagged trusted host. After (1), the attacker must back off for a bit to give the target ample time to send the SYN/ACK (the attacker cannot see this segment). Then, at (3) the attacker sends an ACK to the target with the predicted sequence number (plus one, because we're ACKing it). If the attacker is correct in her prediction, the target will accept the ACK. The target is compromised and data transfer can commence (4). Generally, after compromise, the attacker will insert a backdoor into the system that will allow a simpler way of intrusion. (Often a `cat + + >> ~/.rhosts` is done. This is a good idea for several reasons: it is quick, allows for simple re-entry, and is not interactive. Remember the attacker cannot see any traffic coming from the target, so any reponses are sent off into oblivion.)

IP-Spoofing works because trusted services only rely on network address based authentication. Since IP is easily duped, address forgery is not difficult. The hardest part of the attck is in the sequence number prediction, because that is where the guesswork comes into play. Reduce unknowns and guesswork to a minimum, and the attack has a better chance of suceeding. Even a machine that wraps all it's incoming TCP bound connections with Wietse Venema's TCP wrappers, is still vulnerable to the attack. TCP wrappers rely on a hostname or an IP address for authentication...

PREVENTITIVE MEASURES

One easy solution to prevent this attack is not to rely on address-based authentication. Disable all the r* commands, remove all .rhosts files and empty out the /etc/hosts.equiv file. This will force all users to use other means of remote access (telnet, ssh, skey, etc).

If your site has a direct connect to the Internet, you can use your router to help you out. First make sure only hosts on your internal LAN can particpate in trust-relationships (no internal host should trust a host outside the LAN). Then simply filter out *all* traffic from the outside (the Internet) that puports to come from the inside (the LAN).

An obvious method to deter IP-spoofing is to require all network traffic to be encrypted and/or authenticated. While several solutions exist, it will be a while before such measures are deployed as defacto standards.

Since the sequence numbers are not choosen randomly (or incremented randomly) this attack works. Bellovin describes a fix for TCP that involves partitioning the sequence number space. Each connection would have it's own seperate sequence number space. The sequence numbers would still be incremented as before, however, there would be no obvious or implied relationship between the numbering in these spaces. Suggested is the following formula:

ISN=M+F(localhost,localport,remotehost,remoteport)

Where M is the 4 microsecond timer and F is a cryptographic hash. F must not be computable from the outside or the attacker could still guess sequence numbers. Bellovin suggests F be a hash of the connection-id and a secret vector (a random number, or a host related secret combined with the machine's boot time).