This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

TCP sequence number approximation

The Last Part of 3 Medium Vulnerabilities reported by Security Space Advanced Security Audit which I would like to see how I should fix it.

Latest ASG 9.003

General: TCP sequence number approximation
Description
general/tcp

The remote host might be vulnerable to a sequence number approximation
bug, which may allow an attacker to send spoofed RST packets to the remote
host and close established connections.

This may cause problems for some dedicated services (BGP, a VPN over
TCP, etc...).

Solution : See Multiple Vendor TCP Sequence Number Approximation Vulnerability
Risk factor : Medium


CVE Description
TCP, when using a large Window Size, makes it easier for remote attackers to guess sequence numbers and cause a denial of service (connection loss) to persistent TCP connections by repeatedly injecting a TCP RST packet, especially in protocols that use long-lived connections, such as BGP


This thread was automatically locked due to age.
  • Hi Alvin,

    Isn't this caused by the same underlying issue as: https://community.sophos.com/products/unified-threat-management/astaroorg/f/54/t/40800

    I suppose you could uncheck 'Enable TCP Window scaling' and select 'Use strict TCP session handling' to deal with all three of these.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Hi Bob,

    I posted all 3 accordingly from my security space report.

    My knowledge of network is not up to this level to assume it is the same.

    Use strict TCP session handling is Enabled when the scan is conducted.
    Validate packet length is Enabled when the scan is conducted.
    Spoof protection: Strict when the scan is conducted.

    I would now Enable Enable TCP Window scaling and do another scan to see the result.
  • I emailed Sophos Support about this last week. Here is there response:

    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. 


    I think what we are going to do is document this for auditing purposes so if the HIPAA/HITECH police come and verify our security audits, this vulnerability shouldn't be a problem.