TCP sequence number approximation

I've had a chance to talk to our Senior Product Specialist for the UTM regarding this.

Mitigation of this attack is easy. Disable TCP window scaling - but I would recommend against that. It can notably improve network performance in some cases, and this threat is long on hype, and short on execution. It’s nearly impossible to exploit in any practical way.

Keep in mind that it was reported in 2004, and no vendor has done anything to resolve it. Guessing the TCP session number is only one of five pieces of info necessary to shut down a TCP session. The source and destination IPs, as well as source and destination port numbers also need to be known before a valid, forged RST packet could be sent. If you can get that information reliably, you likely would not have to guess at the sequence numbers either – making exploitation instantly viable with little or no guessing necessary.

If we assume for a moment, that an attacker CAN get that information, and still needs to guess the 32 bit sequence number, that normally would mean over 4 billion possibilities. Sequence numbers are randomized these days, so there’s no simple shortcuts. Under regular circumstances, TCP sessions would likely finish normally before the correct sequence number is guessed. This attack can realistically only work with TCP window scaling enabled, which allows the receiving system will then accept a larger range of sequence numbers. If the receive window was a typical 32k size, then it would only take about 130k possibilities, so much more doable, and for a long lasting TCP session, even possible – provided you KNOW the rest of the necessary info, in addition to the sequence number.

So, if the stars align, and you know the first four pieces of info, and then can guess the sequence number, you are then able to kill a SINGLE TCP session. The impact of this is almost nothing.

Many examples cite BGP as a potential target, since a) sessions are typically long lasting, and b) the impact could be slightly more severe, since peer routing tables would assume a router has gone down, and would remove announcements from that peer, until the session is re-established, and routes are re-announced. This is the one example that might be significant – but only on an internet infrastructure level. UTMs running BGP are typically using it internally, and not facing the internet, so there is no exposure to this consequence in the vast majority of cases. Furthermore, ISP level ingress filtering has increased, making this, or any other spoofed sender attacks impossible against customers of any ISP employing perimeter level ingress filtering.