Luc Gommans/ blog

Spoofing TCP connections without sequence number prediction

Written on 2016-08-16

It's commonly known among security people that predicting sequence numbers is an old attack which we prevent by using a CSPRNG. Problem solved, right?

Not if you don't need to predict them in the first place.

I learned of old TCP sequence number vulnerabilities some years ago but always wondered: isn't a 32-bit integer bruteforceable anyway, regardless of whether you can predict it? A subject in school allowed for us to earn credits for a small research project and I thought this was a good fit.

The initial calculations seemed promising. It seems that spoofing a fully acknowledged TCP connection, without using a man in the middle attack, would take take 20 minutes on a 1gbps internet connection. Getting a gigabit connection is cheap, for example on DigitalOcean the hourly price is 0.7 cents. Yes, less than one cent.

Source code snippet, see download below

Together with Raoul Houkes I wrote a proof of concept that we would run overnight on school's virtual network environment (it's meant for security testing). After spending some time on creating ethernet, IP and TCP headers from scratch (since existing tools like Scapy aren't fast enough), we set it to run that night.

The software would record all network traffic in a looping buffer, throwing away old traffic and stopping as soon as we got a valid connection (so it wouldn't be overwritten).

The following morning there was a match; it worked! It took a few hours because the virtual infrastructure and CPUs are very slow, putting through only around 300mbps, and we weren't very lucky (it took 4 times longer than it should, something which happens about 13% of the time). But eventually we got a match, and the SSH server that we were testing sent its hello message.

Wireshark screenshot of the SSH server's response to a valid connection

Download: the source code | the pcap shown above.

How is this new?

Two reasons:

Programmers and sysadmins are, in most security experts' minds, notoriously unaware of security issues. In this case, even most security people are not aware of the issue because they know about the prediction issues, not brute force issues.

Did this idea never cross nobody's mind before? I doubt it, but I couldn't find anyone mentioning this attack anywhere. When I wrote about this attack before, lots of people linked me to old (often pre-2000) blog posts and magazines that supposedly talked about this, but they're all about predicting sequence numbers.

What are the implications?

IP-based authentication, where having the right IP address is enough to be granted access, is a thing of the past. Still, lots of software has the option to use IP addresses as part of the authentication process.

Example of IP-based security measure in Drupal

While there is not much software left that can be exploited using this technique alone (though I'm sure it's still out there somewhere, particularly in mail servers), there is plenty of software where this attack can be used to circumvent hardening or security-in-depth.

Mail servers, ssh servers, file servers, firewalls, content management systems... the list of categories is large and the list of individual software products is even larger.

How to solve it?

Change the TCP protocol. That's the solution, but it's not very feasible.

A feasible workaround is using additional layers on top of TCP such as TLS, where it's necessary to send more data back and forth before reaching the layer 7 protocol and being able to do damage.

Before all this can happen, though, we need to take this seriously and acknowledge that the issue is different from old (and solved) prediction vulnerabilities.