US-CERT Technical Cyber Security Alert TA04-111A -- Vulnerabilities in TCP  -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1    Technical Cyber Security Alert TA04-111A archive  Vulnerabilities in TCP    Original release date: April 20, 2004    Last revised: --    Source: US-CERT Systems Affected      * Systems that rely on persistent TCP connections, for example        routers supporting BGP Overview    Most implementations of the Border Gateway Protocol (BGP) rely on the    Transmission Control Protocol (TCP) to maintain persistent    unauthenticated network sessions. There is a vulnerability in TCP    which allows remote attackers to terminate network sessions. Sustained    exploitation of this vulnerability could lead to a denial of service    condition; in the case of BGP systems, portions of the Internet    community may be affected. Routing operations would recover quickly    after such attacks ended. I. Description    In 2001, the CERT Coordination Center released CA-2001-09, describing    statistical weaknesses in various TCP/IP Initial Sequence generators.    In that document (),    it was noted by Tim Newsham:      [I]f a sequence number within the receive window is known, an      attacker can inject data into the session stream or terminate the      connection. If the ISN value is known and the number of bytes sent      already sent is known, an attacker can send a simple packet to      inject data or kill the session. If these values are not known      exactly, but an attacker can guess a suitable range of values, he      can send out a number of packets with different sequence numbers in      the range until one is accepted. The attacker need not send a      packet for every sequence number, but can send packets with      sequence numbers a window-size apart. If the appropriate range of      sequence numbers is covered, one of these packets will be accepted.      The total number of packets that needs to be sent is then given by      the range to be covered divided by the fraction of the window size      that is used as an increment.    Paul Watson has performed the statistical analysis of this attack    when the ISN is not known and has pointed out that such an attack    could be viable when specifically taking into account the TCP    Window size. He has also created a proof-of-concept tool    demonstrating the practicality of the attack. The National    Infrastructure Security Co-Ordination Centre (NISCC) has published    an advisory summarizing Paul Watson's analysis in "NISCC    Vulnerability Advisory 236929," available at    .    Since TCP is an insecure protocol, it is possible to inject    transport-layer packets into sessions between hosts given the right    preconditions. The TCP/IP Initial Sequence Number vulnerability    (http://www.kb.cert.org/vuls/id/498440) referenced in CA-2001-09 is    one example of how an attacker could inject TCP packets into a    session. If an attacker were to send a Reset (RST) packet for    example, they would cause the TCP session between two endpoints to    terminate without any further communication.    The Border Gateway Protocol (BGP) is used to exchange routing    information for the Internet and is primarily used by Internet    Service Providers (ISPs). For detailed information about BGP and    some tips for securing it, please see Cisco System's documentation    (    or Team Cymru (). A vulnerable situation    arises due to the fact that BGP relies on long-lived persistent TCP    sessions with larger window sizes to function. When a BGP session    is disrupted, the BGP application restarts and attempts to    re-establish a connection to its peers. This may result in a brief    loss of service until the fresh routing tables are created.    In a TCP session, the endpoints can negotiate a TCP Window size. When    this is taken into account, instead of attempting to send a spoofed    packet with all potential sequence numbers, the attacker would only    need to calculate an valid sequence number that falls within the next    expected ISN plus or minus half the window size. Therefore, the larger    the TCP Window size, the the larger the range of sequence numbers that    will be accepted in the TCP stream. According to Paul Watson's report,    with a typical xDSL data connection (80 Kbps, upstream) capable of    sending of 250 packets per second (pps) to a session with a TCP Window    size of 65,535 bytes, it would be possible to inject a TCP packet    approximately every 5 minutes. It would take approximately 15 seconds    with a T-1 (1.544 Mbps) connection. These numbers are significant when    large numbers of compromised machines (often called "botnets" or    "zombies") can be used to generate large amounts of packets that can    be directed at a particular host.    To protect against such injections, RFC 2385 provides a method of    using MD5 signatures on the TCP Headers. If this form of verification    is supported and enabled between two peers, then an attacker would    have to obtain the key used to transmit the packet in order to    successfully inject a packet into the TCP session. Another alternative    would be to tunnel BGP over IPSec. Again, this would provide a form of    authentication between the BGP peers and the data that they transmit.    The lack of authentication when using TCP for BGP makes this type of    attack more viable.    US-CERT is tracking this issue as VU#415294. This reference number    corresponds to CVE candidate CAN-2004-0230. NISCC is tracking this    issue as Advisory 236929. II. Impact    Sustained exploitation of the TCP injection vulnerability with regard    to the BGP vulnerability could lead to a denial-of-service condition    that could affect a large segment of the Internet community. Normal    operations would most likely resume shortly after the attack stopped.    Since the TCP/IP Initial Sequence Number vulnerability (VU#498440) has    been proven more viable of an attack, any services or sites that rely    on persistent TCP sessions could also be affected by this    vulnerability. Impacts could range from data corruption or session    hijacking to a denial-of-service condition. III. Solution Apply a patch from your vendor    Please see you vendor's statement regarding the availability of    patches, updates and mitigation strategies. Workaround Deploy and Use Cryptographically Secure Protocols    TCP initial sequence numbers were not designed to provide proof    against TCP connection attacks. The lack of cryptographically-strong    security options for the TCP header itself is a deficiency that    technologies like IPSec try to address. It must be noted that in the    final analysis that if an attacker has the ability to see unencrypted    TCP traffic generated from a site, that site is vulnerable to various    TCP attacks - not just those mentioned here. A stronger measure that    would aid in protecting against such TCP attacks is end-to-end    cryptographic solutions like those outlined in various IPSec    documents.    The key idea with an end-to-end cryptographic solution is that there    is some secure verification that a given packet belongs in a    particular stream. However, the communications layer at which this    cryptography is implemented will determine its effectiveness in    repelling ISN based attacks. Solutions that operate above the    Transport Layer (OSI Layer 4), such as SSL/TLS and SSH1/SSH2, only    prevent arbitrary packets from being inserted into a session. They are    unable to prevent a connection reset (denial of service) since the    connection handling will be done by a lower level protocol (i.e.,    TCP). On the other hand, Network Layer (OSI Layer 3) cryptographic    solutions such as IPSec prevent both arbitrary packets entering a    transport-layer stream and connection resets because connection    management is directly integrated into the secure Network Layer    security model.    The solutions presented above have the desirable attribute of not    requiring any changes to the TCP protocol or implementations to be    made. Some sites may want to investigate hardening the TCP transport    layer itself. RFC2385 ("Protection of BGP Sessions via the TCP MD5    Signature Option") and other technologies provide options for adding    cryptographic protection within the TCP header at the cost of some    potential denial of service, interoperability, and performance issues. Ingress filtering    Ingress filtering manages the flow of traffic as it enters a network    under your administrative control. You can configure your BGP routers    to only accept packets on a specific network connection. Servers are    typically the only machines that need to accept inbound connections    from the public Internet. In the network usage policy of many sites,    there are few reasons for external hosts to initiate inbound    connections to machines that provide no public services. Thus, ingress    filtering should be performed at the border to prohibit externally    initiated inbound connections to non-authorized services. In this    fashion, the effectiveness of many intruder scanning techniques can be    dramatically reduced. Network Isolation    Complex networks can benefit by separating data channels and control    channels, such as BGP, into different logical or physical networks.    Technologies such as VLANs, VPNs, leased links, NAT may all be able to    contribute to separating the tranmission of control information from    the transmission of the data stream. Egress filtering    Egress filtering manages the flow of traffic as it leaves a network    under your administrative control. There is typically limited need for    machines providing public services to initiate outbound connections to    the Internet.    In the case of BGP, only your BGP routers should be establishing    connections to your peers. Other BGP traffic generated on your network    could be a sign of an attempted attack. Appendix A. Vendor Information    For vendor information, please see NISCC Vulnerability Advisory 236929    "Vulnerability Issues in TCP"    (http://www.uniras.gov.uk/vuls/2004/236929/index.htm) or Vulnerability    Note VU#415294 (http://www.kb.cert.org/vuls/id/415294#systems. As    vendors report new information to US-CERT, we will update the    vulnerability note. If a particular vendor is not listed in either the    NISCC advisory, or the vulnerability, we recommend that you contact    them for their comments.      _________________________________________________________________    US-CERT thanks Paul Watson, Cisco Systems and NISCC for notifying us    about this problem and for helping us to construct this advisory.      _________________________________________________________________    Feedback can be directed to the US-CERT Technical Staff.      _________________________________________________________________    Copyright 2004 Carnegie Mellon University. Terms of use    Revision History    April 20, 2004: Initial release    Last updated April 20, 2004  -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFAhXn2XlvNRxAkFWARAjKIAKDPl3a6RADvUASZJnIz5MAolUygqACgvUXz crcQkqHTAxSVkcKnMMYLYU0= =54p4 -----END PGP SIGNATURE-----