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.
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.
Download: the source code | the pcap shown above.
How is this new?
Two reasons:
-
it's not a prediction attack that can just be solved, we have to change the protocol or use workarounds; and
- times changed and network connections got faster and cheaper. In 2016, we should consider this a viable path of attack.
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.
So 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), there is plenty of software where this attack can be used to circumvent hardening or security-in-depth. A weak password plus IP restrictions might suddenly not be enough anymore. Mail servers, ssh servers, file servers, firewalls, content management systems... almost every piece of software in these categories has the option to limit logins to certain IP addresses.
How to solve it?
Change the TCP protocol. But that's not very feasible.
An easier 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 application layer protocol and being able to do damage.
Before all this can happen, though, we need to acknowledge that the issue is different from old (and solved) prediction vulnerabilities. When peple are aware, they know not to rely on it.