# 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. – armani Oct 18 '16 at 16:51
• @armani OVH has been able to handle 1 TB/s in the recent DDOS. – Xavier59 Oct 18 '16 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. – ThoriumBR Oct 18 '16 at 17:03

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.