Software Engineering Institute

The Border Gateway Protocol (BGP) is used to exchange routing information for the Internet and is primarily used by Internet Service Providers. For details about BGP, please see Cisco System's documentation on BGP.

A vulnerable situation arises due to the fact that BGP relies on persistent TCP sessions to function. Since TCP is an insecure transmission protocol, it is possible to inject TCP packets into sessions between hosts given the appropriate information. The TCP/IP Initial Sequence Number vulnerability (VU#498440) is one example of how an attacker could inject TCP packets into a session. As an example, if an attacker were to send a reset (RST) packet, he or she would cause the TCP session between two endpoints to terminate without any further communication. In the case of a BGP/TCP session, this would cause the BGP application to restart and attempt to re-establish a connection to its peers and cause a brief denial-of-service period until the routing tables could be repopulated. The time previously thought to exploit this type of an attack would have made sustaining a denial-of-service condition unlikely. 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:

As a result, if 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 he has pointed out that such an attack could be viable when taking into account the TCP Window size. He has also generated a proof-of-concept tool.

In a TCP session, the clients can specify a TCP Window size. This window size is used to determine the packet transmission size and rate of packets that a sender can transmit before require a response from the recipient. When this is taken into account, instead of attempting to send a spoofed packet with all potential ISNs, the attacker would only need to calculate a valid ISN that falls within the next expected ISN plus or minus the window size. Therefore, the larger the TCP Window size, the easier it is to calculate a valid ISN. According to Paul Watson's report, with a typical DSL data connection capable of sending of 250 packets per second to a session with a TCP Window size of 65,535, it would be possible to inject a TCP packet approximately every 5 minutes. It would take approximately 15 seconds with a T-1 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. Since BGP automatically re-establishes connections and rebuilds routing tables, a single instance of exploitation would have very little impact on the BGP service; however, a sustained attack could prevent the BGP service from being able to re-establish its connection, and data could no longer be routed by the service.

The preconditions for exploiting this vulnerability are high, but could be overcome if an attacker were able to monitor (or sniff) the connection between BGP peers. Information could also be gathered by knowing what equipment was being used.

To protect against such injections, RFC 2385 provides a method of using MD5 signatures on the TCP Headers. If this authentication method 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.

Sustained exploitation of this vulnerability could lead to a denial-of-service condition affecting a large segment of the Internet community. Normal operations would most likely resume shortly after the attack stopped.

Please see your vendor's advisory for updates and mitigation capabilities.