Is TCP Sequence Bruteforcing dangerous nowadays?

What is the future of TCP sequence Bruteforcing?

I'll argue that it is not as dark as it may seem at first. Guessing a 32bit number is not feasible, even if you send a lot of packets with attempts. As @armani said, using a DDoS size bandwidth is most likely to make the machine not respond rather than accept the spoofed packet.

Yet, there are other ways. All of them are based on the fact that you can reduce the search space (32bit) to a more amenable amount.

1. Years ago Michal Zalewski performed a research where he made time series of the pseudo random number generators. The time series allowed to guess the next number based on a couple of previous ones. Knowing some packets allowed to make a much better guess against systems where the PRNG was somehow predictable. And guess what, most systems have a rather predictable PRNG.

2. A year later Zalewski checked if the PRNGs did improve after he reported the issues. And the improvement was not so great.

3. Even attempts to to protect from ISN guessing backfired in the past. CVE 2016-5696 happened because an RFC (RFC 5961) did not define things properly and implementations (actually the one single implementation in the Linux TCP stack) became more vulnerable. They became vulnerable because they provided sequence numbers through ACK challenge packets that could be used in determining the PRNG sequence (in techniques similar as point 1.). Once the number of allowed ACK challenge packets was reached, you not only could try guessing as normal, but had several packets to base your PRNG analysis.

We (OS developers and security analysts) keep making mistakes with ISN. And, although popular and updated systems are unlikely to be vulnerable (Linux is fixed those CVEs), not all systems are updated. Moreover, as seen in Zalewski's research, router OSes do not fare much better on PRNG predictability. And router OSes are often left not updated.

There is still future for sequence guessing, not necessarily plain brute-forcing. But the guessing, still involves some brute-forcing. You can guess a couple of ranges a PRNG can come up with, and from there you need to send several packets with different sequence numbers each based on the ranges (using all numbers in the guessed range in the best case).

It is becoming harder and harder to make viable spoofing attacks on TCP sequence numbers. But is isn't impossible.

References

• Strange Attractors and TCP/IP Sequence Number Analysis - Zalewski
• Strange Attractors and TCP/IP Sequence Number Analysis - One Year Later
• TCP “off-path” Attack (CVE-2016-5696)
• RFC 5961

Not a well-known attack

I looked into this question myself in 2015. Nobody talked about this back then, and looking for it again recently, it's still not a well known risk. You are right: with a standard gigabit connection (which was already quite standard in 2015) you can work through the couple of terabytes needed in a matter of minutes. Or, on 100mbps, in a few hours.

Limitations

The problem is that you can't do any sort of handshake. You can't spoof a TLS session, even if the server uses a self-signed certificate and a super tiny public key. Pretty much any unknown byte multiplies the amount of data you need to send. If you need to guess a single digit, the attack will need (on average) five times more data. If you need to guess more than a few digits (let alone a few bytes), it still becomes prohibitively expensive. So if you steal credentials but notice that there is an IP whitelist, you can't login a session with a spoofed TCP connection, because you'll never learn the value of the session cookie (and session cookies are designed to be impossible to guess).

Routers may additionally protect against traffic coming in on the wrong interface. If a system has an internal management interface and a public interface, you can't just send a packet to the public interface originating from the internal IP range, because "by default the Linux kernel checks to see the path a hypothetical return packet would take. If the return packet is over another interface it silently dropped. This mechanism is controlled by the rp_filter kernel parameter." (source) If you run ip route get 172.16.0.1 from 172.16.0.2 dev eno1 (where eno1 is the public interface and 172.16.0.0/24 is your internal range), you'll see that it returns an error about a cross-device link.

Finally, you may encounter trouble spoofing IP addresses outside of your ISP's network range at all, as more and more ISPs start filtering bad source IPs from their traffic (ingress filtering / BCP38). Especially the private ranges like 10.x, 192.168.x, 127.x, etc. will be very hard to route across the Internet.

Proof of concept

It is relatively easy to make your own proof of concept. Something like Scapy is not fast enough, but if you take the ready-made packets (for example from a Wireshark capture), modify them to include a variable seq/ack number, and write a few lines of socket code, you can easily test this attack on your LAN. I did so and originally described the results in this blog post: https://lgms.nl/blog-2

There is code and a pcap available, so you can look at the results and toy around with the proof of concept yourself.

Risk

It is not a huge risk. IP address-based whitelisting has fallen out a bit of style in favor of username/password or public key authentication. Circumventing IP address-based blacklists or bans with this method is a bit pointless: you'll have the aforementioned limitations and you need to transmit terabytes of data before you can do a single request. It is typically much easier to find yourself another IP address.

Nevertheless, there are totally cases where this attack circumvents hardening or, in very rare cases, circumvents security altogether. I nearly never come across it in my work as a pentester, but that might be because I mainly see networks where someone cares to keep it secure (they care enough to pay my employer's rates for an expert analysis).

Solutions

There are three possible solutions:

• Stop relying on IP addresses for security in the first place.

  People seem to be doing this already, but rather because it is harder to manage than because they know of this security risk.

• Update the TCP protocol or create a new protocol like TCPv2.

  People are having trouble introducing new protocols and speak of the ossification of the Internet. If we can hardly introduce anything alongside TCP and UDP, I doubt we can change TCP itself with broad consensus. (I think "TCPv6" would paint an accurate picture.)

• Add a layer on top of TCP that has additional random numbers.

  Encryption is popular and very effective at this. We could add TLS to everything. Even if the encryption turns out to be poor, it would prevent the attack because you almost certainly need to use some random bytes, which you can't do off-path (at least, not while also trying to guess the acknowledgement number).