3

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?

Community
  • 1
700 Software
  • 13,807
  • 3
  • 52
  • 82
  • 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. – Shane Andrie 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. – 700 Software 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
  • Actually the context is that client has connected legitimately and received the ACK for the initial connection. Then after that, the attacker, via passive eavesdropping has managed to steal (not guess) the correct sequence number. (because guessing a 32 bit `int` would be quite unlikely) – 700 Software Oct 12 '16 at 17:59
  • Since the client & server have legitimately/fully initiated the connection without the attacker's involvement (yet), I think that [SYN cookies](https://en.wikipedia.org/wiki/SYN_cookies) (to circumvent SYN flood attacks) are not relevant to my question? – 700 Software Oct 12 '16 at 18:01
  • Eyup, SYN cookies are out of question there. But that kind of hijack is not that trivial as it sounds at first. Most TCP connection will be using window scaling, so an attacker sending a single packet will unlikely kill the connection. I also need to remind myself of what `tcp_challenge_ack_limit` does, i believe it is related to defence from such hijacks even further. – grochmal Oct 12 '16 at 18:31
  • Nope, ACK challenges are a defence against off-path injections, not someone who can eavesdrop. My bad. Anyhow, I outlined window scaling. – grochmal Oct 12 '16 at 19:14
  • 2
    I'd encourage you to try this out. [scapy](http://www.secdev.org/projects/scapy/) is handy for low-level packet crafting – paj28 Oct 12 '16 at 19:30

1 Answers1

1

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.

References

Community
  • 1
grochmal
  • 5,677
  • 2
  • 19
  • 30