31

Little time ago, me and my friends argued if TCP handshake can be passed with a spoofed IP address.

Assume I have a web server that allows only certain IP addresses. Can anyone connect that web server by IP spoof?

ibrahim
  • 571
  • 3
  • 7
  • 13

4 Answers4

25

Short answer: no.

Longer answer: yes, if you control a router device close to the target device (it has to be on the path between the the real source IP address and the target, and on the path between the faked IP address and the target) or if the target network/host accepts source-routed packets.

MultiplyByZer0
  • 105
  • 4
symcbean
  • 18,278
  • 39
  • 73
  • 4
    You should also include historical attacks on deterministic TCP sequence numbers, which in the past have been used to great effect. – Anorov Jun 15 '13 at 18:39
  • 2
    @symcbean, So in other words **yes if your internet service provider goes rogue and wants to hack you?** – Pacerier Dec 26 '16 at 22:53
20

Short answer: Yes, but not as possible as it used to be, and dependent upon how literally one takes your question.

Long answer:

I notice that you did not ask "Is it possible to carry on a TCP conversation with a spoofed IP address" - that question was ably answered by @symcbean. You specifically asked "Is it possible to pass TCP handshake with spoofed IP address". So there's a difference between the question you asked - "Can you spoof SYN->SYN/ACK->ACK in such a way that the server believes a connection has been successfully nailed up" - and the question you probably meant - "Can you carry on a TCP conversation with a spoofed client address".

So let's look at the literal question you asked. In that case, the answer is "Yes, if the initial TCP sequence number included in the SYN/ACK by the server is predictable." That's why ISN (Initial Sequence Number) predictability is something tested by vulnerability scanners, and something which is far more widely implemented correctly today than it was 10 or 15 years ago. To quote a 2001 Cisco advisory relating to this vulnerability, "The general case of this vulnerability in TCP is well-known to the information system security community." Most famously, Mitnick abused this feature in his attack upon Shimomura.

Unless source routing or access to a router in the network path is available, this is not a sustainable setup. The client may be able to guess the ISN, but later sequence numbers are incremented by the size of the packets being sent, which the attacker won't see and can't reliably predict. So they should be able to get at least one packet in after the three-way handshake, but not a conversation. And sometimes one packet is enough.

ISN prediction is a specific subset of TCP sequence prediction attacks. While I can't quote good numbers, my experience suggests that it's a vulnerability that lingered far longer than it should have; you still run across devices failing scans because of it. It's hard to get everybody to just fix their TCP stacks, especially when the fix involves robust random number generation, which is somewhat hard on limited, cheap hardware (the kind that gets thrown into network devices all the time).

Russ
  • 103
  • 3
gowenfawr
  • 71,975
  • 17
  • 161
  • 198
5

Without access to the network behind one of the allowed IP addresses or access to a machine behind one of the allowed IP addresses, you can not pass a TCP 3-way handshake with a spoofed IP address.

Adi
  • 43,808
  • 16
  • 135
  • 167
2

It is easy to send a TCP packet with any IP address. On Linux you can open a raw socket and send anything you want. The problem is receiving the SYN/ACK (or any other response), which will be routed to the original IP.

Routers between your client may have firewall rules to reject the request, but often they will assume that your client is just routing a packet from another host.

user87121
  • 21
  • 1