TCP with IP Spoofing, Is It Really Impossible?

Question

I was reading: IP Spoofing with real IP when TCP 3-way handshake has been made

Where the answer says:

First of all, every TCP packet has a sequential identifier, which starts at a random position. (explained briefly in this discussion) So if the attacker is spoofing (non-SYN) packets (trying to hijack an existing connection), then all of those spoofed packets will be ignored or refused (depending on the type of packet) because they will be out of sequence.

1. I understand this, but what about the case where the attacker is spoofing all packets (including the first SYN packet that was transmitted)?

   In this case, the victim can't detect the attacker, since the attacker decides the initial sequential identifier.

2. In the above answer, why the attacker can't look at the initial value of sequential identifier? let's say all packets pass though him (still from what I know sequential identifier isn't encoded) maybe it's encoded in IPSec? In other words, can we encode IP headers?

Answer 1

I understand this, but what about the case where the attacker is spoofing all packets (including the first SYN packet)?

The attacker needs to exactly acknowledge the SYN from the server in order to proceed with the TCP handshake. Since the sequence number in the servers SYN is random and since the attacker cannot observe it (since the packet gets send to the IP spoofed by the attacker), the attacker would need to correctly guess the servers sequence number.

While the attacker might send lots of packets and thus be lucky to guess it, this has to be done for all the following exchanges too since the attacker cannot observe which of the guesses was successful.

Answer 2

I understand this, but what about the case where the attacker is spoofing all packets (including the first SYN packet that was transmitted)?

That is just... opening a connection to the server yourself. That's what initiating a TCP connection is. Well, unless you put somebody else's IP address in the Source IP field... in which case you won't see the SYN+ACK response packet that specifies the server's starting sequence number, which means you can't respond with an ACK of your own to complete the handshake (and start data transmission) because you don't know what value to put in the Acknowledgement Number field. In that case, the client IP you're spoofing will ignore the invalid (SYN+ACK without an initial SYN) packet that it receives, and the server will ignore any invalid ACK (plus data) that you try to send.

Now, of course, this assumes you don't have complete ability to inspect network traffic, including traffic between the server and the spoofed client. If you do, then you can obviously spoof a valid ACK to the server and complete the handshake. But generally that's only possible if you're on the same local network as the spoofed IP (and have compromised the router/gateway or are using ARP spoofing or similar) and in such cases, the spoofing generally gets you nothing. What does it matter that the server thinks you have a different IP address than you actually do? Unless the server is using IP-based authorization, but not using any form of secure network protocol (a very unlikely combination), that's still just "opening a TCP connection" but now with extra steps. The server (in most cases) doesn't care what IP you're claiming to have, so long as you can read packets addressed to that IP.

In the above answer, why the attacker can't look at the initial value of sequential identifier?

You may be thinking that there's only one sequence number? This is wrong, there are two, one for each direction. Each direction's sequence number is chosen at random by the host who will send (not receive) packets in that direction, and sent in the SYN (for client-to-server) or SYN+ACK (for server-to-client) packets. Thus, an attacker who does not have a MitM position between server and client won't know what the server's sequence number is (and thus can't acknowledge it) because they never see the server-to-client packets.

let's say all packets pass though him (still from what I know sequential identifier isn't encoded) maybe it's encoded in IPSec? In other words, can we encode IP headers?

If all packets to or from the relevant server are passing through the attacker's host, then once again that's just complete man-in-the-middle (MitM), and the attacker can spoof being any IP that it wants. If the attacker has MitM on packets to and from a legit client but not between the server and arbitrary other clients, then the attacker can spoof that one client but not any others.

---

Note that all of this assumes the absence of any network security. TCP isn't really a secure protocol, and anybody who tries to rely on IP address alone for security is making a huge mistake. Fortunately there are many secure network protocols that can be combined with or layered on top of TCP (or used as a substitute for it), most commonly TLS but also DTLS, SSH, IPsec, and many others. Some of these protocols operate below the level of TCP or even IP and obscure the TCP/IP packets from network attackers, but the most common ones operate at higher levels and leave the TCP/IP packets themselves in plain text (you just can't read most parts of the TCP packet payloads, not without the decryption key)