# Is TCP Sequence Bruteforcing dangerous nowadays?

I was reading about TCP sequence prediction which is described as almost impossible on all updated Operating System nowadays. The total amount of possible sequence numbers is `2^32-1` which, if we try to brute force it, will be guessed after an average of `(2^32-1)/2 = 2 147 483 647.5` try.

So now, what is necessary to a good IP spoofing attack

`SYN`+`ACK`+at least one `PSH` packet to perform the attack. `20B + 20B + ~30B = 70B`

It takes then approximatly `(2^32-1)/2*70 ~= 150TB` to perform an IP spoofing attack.

We've seen the biggest DDOS attack, with over 1TB/s few weeks ago (source). So if I understand, this camera botnet is able to perform IP spoofing attack in 150 seconds.

What is the future of TCP sequence Bruteforcing ? With the constant increase of bandwith and computer's power, will this become an important attack vector to deal with ? Should the TCP protocoles be updated to deal with 64 bits sequence ?

• Using DDOS for TCP sequence bruteforce might be ineffective since the system you're hoping to get a positive hit on is the target of a DDOS so may not reply. Commented Oct 18, 2016 at 16:51
• @armani OVH has been able to handle 1 TB/s in the recent DDOS. Commented Oct 18, 2016 at 16:53
• @Xavier59 OVH's network has been able to do that, not a virtual/physical machine inside their network. I doubt any discrete server in the planet can handle 1TB/s single handed. The camera botnet would not be able to perform a IP Spoofing attack, it would DDoS the target way before the attack succeeding. Commented Oct 18, 2016 at 17:03

## 2 Answers

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

• "Guessing a 32bit number is not feasible, even if you send a lot of packets with attempts." I actually tested this and found it easily feasible: lgms.nl/blog-2 This was in 2015 (nearly a year before your answer) and back then, the attack was calculated do be doable in an average of 20 minutes on a (then cheap) gigabit connection.
– Luc
Commented Sep 25, 2019 at 13:58

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).

• It is a nice catch (+1), thanks. Given that one can perform a brute force prediction on gigabit, it finally makes some sense in using short session timeouts. The common (and super short) 15 minutes session timeout finally has a justification :) Commented Sep 25, 2019 at 17:28
• @grochmal How does a session timeout help? You can't guess a session token (unless it was previously stolen and it's IP-bound, not something I would recommend anyway in this age of CGNAT and mobile devices that move networks)
– Luc
Commented Sep 25, 2019 at 17:30
• Heh, it was meant to be a semi-joke; not very clear sorry for that. But yes, it is assuming the silly idea that someone has both authentication and IP whitelisting at the same time. Commented Sep 25, 2019 at 17:39
• @grochmal Ah :). Well, it's not as common nowadays, but I did see plenty of advice for adding IP whitelisting to admin logins. For SSH it is still somewhat regularly recommended, or at least to blacklist the largest countries outside of Europe and North America because that's where all the hackers are (don't tell them about vpn or about absolute versus relative numbers).
– Luc
Commented Sep 26, 2019 at 7:29
• Thank you @Luc for the very interesting answer ! Commented Sep 26, 2019 at 22:15