I'm trying to verify an answer I posted to a recent question:

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

For passive attacks the answer is no. The client will not accept the Acknowledgement (from the Server) for a data packet which it did not send. (the attacker sent it instead)

However, would the connection be able to continue? The client will eventually send another Data packet with the same sequential identifier (that the attacker used) which the Server just Acknowledged.

I assume the server does not log previously acknowledged data, and would simply repeat the acknowledgement, dropping the new Data packet (on the basis of the duplicated sequential identifier) without realizing that the new data is different. Is this correct? Or, is this implementation-dependent?

  • 1
    I would agree, as the system is designed with ignoring duplicate packets. I don't know if payload size would affect that or not. Your checksum would probably be off as well. Oct 12 '16 at 16:34
  • Repeated data packets could be several incremental steps back. That would be an unwanted overhead were the OS to try comparing checksum or packet size to history. Oct 12 '16 at 16:57
  • You are assuming that the attacker managed to guess the correct TCP sequence number to send the SYN+ACK, correct? I'm just making sure. In other words, by saying "Client A with real IP has connected" you mean the client sent a SYN packet and nothing else.
    – grochmal
    Oct 12 '16 at 17:57
  • Also, are we considering the existence of SYN cookies? That makes some difference.
    – grochmal
    Oct 12 '16 at 17:58
  • 2
    I'd encourage you to try this out. scapy is handy for low-level packet crafting
    – paj28
    Oct 12 '16 at 19:30

OK, I'll argue that that statement is not quite right. The statement is correct if we assume that no TCP options are being sent. In theory, an attacker that can eavesdrop packets can inject a correctly crafted packet into the server, and confuse the connection.

In practice pretty much all TCP connections today are tuned and use window scaling. They define a window size to receive data faster, and not need to acknowledge every packet.

Now, this is dependent on implementation but all data in a window must be kept in a buffer instead of being passed to the application because it may happen that the entire window fails to acknowledge correctly.

If an attacker M eavesdropping the connection send only a single packet to the server S with less data than the window size (most likely since windows are often a handful of megabytes), that packet data will end in the buffer with its location defined by the sequence number.

The client A now sends a packet to the server S continuing the connection, the packet contents are likely to be blindly dumped into the buffer holding the window. And the attacker fails to confuse the connection.

The above is not strictly true either. An ACK can be sent at any time during the collection of the packets for the window, not only when the window size is reached. In practical terms this (most likely) means that:

  • The attacker M can succeed submitting a single packet to interfere with a slow moving connection (a lot of time for the server S to send ACKs).
  • The attacker M will have trouble to interfere with a fast paced connection where the server S decides to wait for the window to fill instead of sending ACKs.

On a fast paced connection the attacker M will need to fill the window with his data before client data arrives. That is still feasible if the attacker M is closer to server S than client A.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.