ATTACKS USING IP SPOOFING

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.

IP-spoofing consists of several steps. First, the target host is chosen. 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.

IP-Spoofing is a ‘Blind Attack’

As far as the target knows, it is carrying on a conversation with a trusted pal. The attacker is forging packets purportedly from this trusted host while it is locked up in a denial of service battle. The IP datagram’s sent with the forged IP-address reach the target fine but the datagram’s 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 datagram’s are supposed to go. But it is discarded because the trusted host’s TCP cannot respond because it is under attack. So the attacker has to be smart and *know* what was sent, and *know* what response 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.

Patterns of Trust

After a target is chosen 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 file systems 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.
Trusted Host Disabling Using the Flood of Sins
Once the trusted host is found, it must be disabled. Since the attacker is going to impersonate it, she must make sure this host cannot receive any network traffic and foul things up. There are many ways of doing this, and one such technique is TCP SYN flooding.
A TCP connection is initiated with a client issuing a request to a server with the SYN flag on in the TCP header. Normally the server will issue a SYN/ACK back to the client identified by the 32-bit source address in the IP header. The client will then send an ACK to the server (as we saw in figure 1 above) and data transfer can commence. There is an upper limit of how many concurrent SYN requests TCP can process for a given socket, however. This limit is called the backlog, and it is the length of the queue where incoming (as yet incomplete) connections are kept. This queue limit applies to both the number of incomplete connections (the 3-way handshake is not complete) and the number of completed connections that have not been pulled from the queue by the application by way of the accept() system call. If this backlog limit is reached, TCP will silently discard all incoming SYN requests until the pending connections can be dealt with. Therein lies the attack.
The attacking host sends several SYN requests to the TCP port she desires disabled. The attacking host also must make sure that the source IP-address is spoofed to be that of another, currently unreachable host (the target TCP will be sending it’s response to this address. (IP may inform TCP that the host is unreachable, but TCP considers these errors to be transient and leaves the resolution of them up to IP (reroute the packets, etc) effectively ignoring them.) The IP-address must be unreachable because the attacker does not want any host to receive the SYN/ACKs that will be coming from the target TCP (this would result in a RST being sent to the target TCP, which would foil our attack).
Sequence Number Sampling and Prediction
Now the attacker needs to get an idea of where in the 32-bit sequence number space the target’s TCP is. The attacker connects to a TCP port on the target (SMTP is a good choice) just prior to launching the attack and completes the three-way handshake. The process is exactly the same as fig (1), except that the attacker will save the value of the ISN sent by the target host. Often times, this process is repeated several times and the final ISN sent is stored. The attacker needs to get an idea of what the RTT (round-trip time) from the target to her host is like. (The process can be repeated several times, and an average of the RTT’s is calculated.) The RTT is necessary in being able to accurately predict the next ISN. The attacker has the baseline (the last ISN sent) and knows how the sequence numbers are incremented (128,000/second and 64,000 per connect) and now has a good idea of how long it will take an IP datagram to travel across the Internet to reach the target (approximately half the RTT, as most times the routes are symmetrical). After the attacker has this information, she immediately proceeds to the next phase of the attack (if another TCP connection were to arrive on any port of the target before the attacker was able to continue the attack, the ISN predicted by the attacker would be off by 64,000 of what was predicted).
When the spoofed segment makes it’s way to the target, several different things may happen depending on the accuracy of the attacker’s prediction:
If the sequence number is EXACTLY where the receiving TCP expects it to be, the incoming data will be placed on the next available position in the receive buffer.
If the sequence number is LESS than the expected value the data byte is considered a retransmission, and is discarded.
If the sequence number is GREATER than the expected value but still within the bounds of the receive window, the data byte is considered to be a future byte, and is held by TCP, pending the arrival of the other missing bytes. If a segment arrives with a sequence number GREATER than the expected value and NOT within the bounds of the receive window the segment is dropped, and TCP will send a segment back with the *expected* sequence number.
Here is where the main thrust of the attack begins:
Fig (3)

1 Z (b) —SYN—> A

2 B <—SYN/ACK— A

3 Z (b) —ACK—> A

4 Z (b) —PSH—> A

[…]
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.. 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 Responses are sent off into oblivion.)

Article Authored by Jomon

Author, Jomon, is a Systems Engineer with SupportPRO. Jomon specializes in Cpanel  servers. SupportPRO offers 24X7 technical support services to Web hosting companies and service providers.