The Maginot Line and the TCP Sequence Number Inference Attack

In the recently posted research paper “Off-Path TCP Sequence Number Inference Attack: How Firewall Middleboxes Reduce Security“, Zhiyun Qian and Z. Morley Mao from the University of Michigan discuss a method to try to infer the sequence numbers in use by a TCP connection – and if successful, how to try to hijack the connection and inject data on it in order to, as an example, steal credentials to web sites (banking, social networking, etc.)

Before talking further about their research, I would like to talk a bit about the Maginot Line. The Maginot Line was a line of fortifications located in France, established after World War I, and roughly following France’s borders with Germany and Italy. The idea behind it: in case of another war with Germany, the line would hold the enemy attacks, giving the French Army the chance to regroup and counterattack. The problem: the line only extended so far up North. So during World War II, and instead of attacking the line from the East, the German army completely bypassed it – by attacking Belgium first and then flanking the line.

So a lot of resources were allocated to set-up defenses for a very specific attack scenario – but that scenario never happened, as an easier way was found to bypass the defenses. And the mere fact of allocating so many resources to counter a specific threat significantly reduced the number of resources available to protect against other threats.

The method posited by Qian and Mao on their research paper strongly reminds me of the assumptions made by the French while building the Maginot Line.

As we were saying before, the paper discusses a method to try to infer the TCP sequence numbers for a connection. The process of inferring those sequence numbers is partially based on the behavior of many stateful packet filtering devices – TCP packets for a given session are allowed to traverse the device if their sequence number is within a range of values, while packets with a sequence number outside that range are dropped. They discuss multiple attack scenarios – on top of this behavior on the device, each scenario also has a set of additional prerequisites that have to be true before they can attempt to infer the TCP sequence numbers in use. Some scenarios require the client to have a coarsely predictable TCP initial sequence number. Some require a firewall to be deployed in front of the server that the client is communicating with. Some require the attacker to be “closer” to the host under attack than the legitimate server. Some require multiple firewall devices to be deployed between the TCP connection endpoints.

While the set of prerequisites vary between attack scenarios, one prerequisite remains constant for all the attacks they call “On-site TCP hijacking” – an unprivileged malware application has to be installed on the client under attack. The purpose of this unprivileged malware is to provide the attacker with information required to attempt the TCP sequence number inference process – the first step before attempting to hijack the TCP connection.

And the ability to install unprivileged malware on the target machine brings with it a world of attack possibilities – not the least of which is the ability to infer TCP sequence numbers. But we will talk more about this later.

Since the paper was made public, the Cisco PSIRT has been working with the appropriate product teams analyzing its impact on Cisco’s stateful firewall products. Our investigation isn’t finished yet, but we have tentatively identified features and behaviors on our products that would make some of those scenarios either unfeasible or very unlikely to be successful. We will be publishing a more detailed technical explanation once we’re done with our analysis. But in the meantime, we would like to bring up some points that we think have to be kept in mind when performing the risk assessment for this new research:

We do not consider this a vulnerability of any Cisco product. We consider this a clever use of a combination of behaviors that are enforced by design, and that are actually desirable and beneficial – as an example, the TCP sequence number checking. The device is performing as expected. It has to be clear that the published research cannot be used to subvert the security of the device itself.

We do not consider this to be a vulnerability of the TCP protocol itself either

The requirement to have a “helper” malware application installed on the client under attack should be carefully considered. We completely understand that users may install applications without considering their true origin or ultimate purpose – there is little we can do at the firewall to prevent this behavior.

But if we start from the assumptions that “applications that users install on their device may have hidden malware components” and “users may install applications without considering their security impact” – can we not then come up with a different attack scenario? One with far better chances of being successful?

Let’s say an attacker wants to obtain the user credentials to a certain service. The attacker can then either distribute malware that would provide him with the information required to try to perform a TCP sequence number inference attack. Or the attacker can distribute for free an application with hidden malware that while pretending to “keep your passwords safely encrypted in a secure vault, ready for access when you need them” – it is actually sending those credentials to a server under the attacker’s control.

By going with the second option, we achieve the desired result of obtaining the credentials, but avoid the convoluted (and far from assured success) process of trying to infer the TCP sequence number of a connection, attempting a TCP session hijack, and then injecting data to steal the credentials.

As I said before: we are still investigating the feasibility of this methodology against our firewall devices. But as in the case of the Maginot Line: let’s make sure that we perform the appropriate risk assessment, we understand that those attacks require a significant number of prerequisites, that attack success isn’t guaranteed, and that, at the end of the day, there may be “easier” and “faster” ways to achieve similar (or better!) results.

While we certainly love to discuss the intricacies of the TCP state diagram, side channels and blind injection attacks – we think that, all things being equal, an attacker will go with the alternative that is easier, faster, and with higher chance of success than trying to implement a TCP Sequence Inference Attack.

We'd love to hear from you! To earn points and badges for participating in the conversation, join Cisco Social Rewards. Your comment(s) will appear instantly on the live site. Spam, promotional and derogatory comments will be removed.

All comments in this blog are held for moderation. Your comment will not display until it has been approved

Some of the individuals posting to this site, including the moderators, work for Cisco Systems. Opinions expressed here and in any corresponding comments are the personal opinions of the original authors, not of Cisco. The content is provided for informational purposes only and is not meant to be an endorsement or representation by Cisco or any other party. This site is available to the public. No information you consider confidential should be posted to this site. By posting you agree to be solely responsible for the content of all information you contribute, link to, or otherwise upload to the Website and release Cisco from any liability related to your use of the Website. You also grant to Cisco a worldwide, perpetual, irrevocable, royalty-free and fully-paid, transferable (including rights to sublicense) right to exercise all copyright, publicity, and moral rights with respect to any original content you provide. The comments are moderated. Comments will appear as soon as they are approved by the moderator.