IP Spoofing with real IP when TCP 3-way handshake has been made

Question

In a situation, where the spoofed IP is a real existing remote IP and it is found that the TCP 3-way handshake has been made with a server.

The MiTM machine sends the packet with spoofed IP to the server. Does the real IP acknowledge the ACK sent back from the server to real IP and receive the response packet from the server followed by the acknowledgement?

EDIT: As the brief above was not clear, here I try to be as descriptive as possible.

Client A with real IP has connected with server S completing the TCP 3-way handshake and transferring data packets like a regular connection. Now, the attacker machine M sends a packet spoofing the IP address of A and once this packet is received by the server, it sends back the ACK flag/field to A. Please correct me if I am wrong with this part of ACK flag/field here.

Now my questions here are:

1. Will the ACK flag/field from server S be accepted by A?
2. The packet sent by M with spoofed IP of A gets a response from S to A. Will this response be accepted by A?

Answer 1

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.

So, in order for the attack to be successful, he will have to be eavesdropping on the connection so he can find out what the sequential identifier should be.

After determining the sequence. (via Passive Eavesdropping) It is easy to get the server to accept in-sequence data.

Client A with real IP has connected ... Now, the attacker machine M sends a packet spoofing the IP address of A ... Will the ACK flag/field from server S be accepted by A?

The Acknowledgement packet will have the same sequential identifier as the Data packet sent.

The client A will not accept the Acknowledgement because the Data was sent from attacker M. (so the client is not anticipating an Acknowledgement yet)

(Unless of course this were an Active (non-passive) attack which gives the attacker more options, such as true MiTM)

However, the server will still accept the data.

Even if the client does not accept Acknowledgement of spoofed data packet, the connection will remain open. The client could even send another Data packet. The server will ignore the second Data packet because it has the same sequential identifier, but will probably repeat the Acknowledgement back to the client which would be none-the-wiser. I'm not 100% sure of this so I posted a specific question on that point just to be sure.

The packet sent by M with spoofed IP of A gets a response from S to A. Will this response be accepted by A?

Yes, The Input and Output streams will increment their sequential identifiers separately.

---

Using a secure connection such as TLS will detect such TCP spoofs quite easily, so that is usually the recommended solution.

Answer 2

The question is a bit unclear yet I will try to make some assumptions and answer something.

Let's assume that A is the attacker and R is the real IP. S is the server.

Things to remember.

• TCP packets, be it handshakes or other packets, will have a sequence number and an acknowledgement number which will help the communicating parties in identifying the session.
• A three way handshake happens only in the beginning of a TCP connection, not with each data packet.

So coming to your question,

1. R has an existing connection with S
2. A sends a SYN to S with the IP of R as source address
3. S sends a SYN-ACK to R.
4. Depending on the configuration R will not respond or respond with an RST as it will not be able to match the sequence and acknowledgement number of the received packet with what is expected from any of the connections which it previously initiated.

Spoofing is possible if the system produce predictable TCP sequence numbers.

Answer 3

I am not sure if I clearly understand you but in a scenario where a legal entity Le communicates with a server S using TCP, then they establish end-to-end communication.

Now if a spoofer-attacker A, uses the IP of Le and contacts S then the packet would be handled in the context of communication between Le and S. However keep in mind that TCP maintains packet ordering and this is sth that A should take into consideration before sending the packet, thus making the effort a little harder but not impossible. So maybe the answer won't be an ACK after all..

To restrict access to the TCP connection you must use authentication e.g., at the application layer.

This is a link I found interesting: TCP description