The Border Gateway Protocol relies on persistent TCP sessions without specifying authentication requirements

Overview

A vulnerability exists in the reliance of the Border Gateway Protocol (BGP) on the Transmission Control Protocol (TCP) to maintain persistent sessions. 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.

Description

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.

---

Impact

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.

---

Solution

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

---

Vendor Information

415294

Filter by status: All Affected Not Affected Unknown

Filter by content: __ Additional information available

__ Sort by: Status Alphabetical

Expand all

Javascript is disabled. Click here to view vendors.

Cisco Systems, Inc. __ Affected

Updated: June 07, 2004

Status

Affected

Vendor Statement

Cisco systems is vulnerable. Please see:

<http://www.cisco.com/warp/public/707/cisco-sa-20040420-tcp-ios.shtml&gt;
<http://www.cisco.com/warp/public/707/cisco-sa-20040420-tcp-nonios.shtml&gt;
Please see Cisco’s response to the Cansecwest presentation of this vulnerability:

<http://www.cansecwest.com/csw04/csw04-Ahlawat.ppt&gt;

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23415294 Feedback>).

Nortel Networks, Inc. __ Affected

Updated: April 28, 2004

Status

Affected

Vendor Statement

Nortel Networks has evaluated this issue and testing has confirmed that it is possible to successfully exploit this vulnerability. However, the preconditions for a successful exploitation require levels of access to the network that are unlikely to be achieved in a normal network operating environment; furthermore, such levels of access would enable other forms of attack with much greater impact than that achievable by exploiting this vulnerability.

Nortel Networks is continuing to validate that this vulnerability has no serious consequences for Nortel equipment, and will update this statement periodically.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23415294 Feedback>).

Redback Networks Inc. __ Affected

Updated: June 07, 2004

Status

Affected

Vendor Statement

Redback Networks, Inc. has identified that the vulnerability described in TA04-111A may affect its products. To that end Redback has been providing security workarounds to protect existing installations and will issue software patches to provide a more robust solution to the problem. The SmartEdge Transport product line is unaffected by this vulnerability. Customers should contact Redback Networks Technical Assistance Center [Domestic TAC number (877) 733 2225; International TAC number is 31-104987777; Web: www.redback.com/support ] for more information and workarounds.

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23415294 Feedback>).

Sun Microsystems, Inc. __ Affected

Updated: May 01, 2006

Status

Affected

Vendor Statement

Sun acknowledges that this vulnerability is not new, and similar RST-based DoS attacks are old and well-known. In this particular case, likely targets are long lived TCP connections between well-known hosts using well-known ports (or a small range of known ports).

To be successful, the attacker needs to know the entire four-tuple of a TCP connection (both sides’ IP addresses and TCP ports), and the TCP connection needs to stay up long enough.

Sun is evaluating schemes to mitigate this vulnerability - including those discussed in the IETF draft on TCP Security. At present Sun believes that these conditions are not widespread in typical Internet use and is limited to protocols such as BGP.

If this evaluation determines that a software update is the best solution to this problem, Sun will provide updates to our software.

Meanwhile, please consult the advisories listed below for detailed mitigating strategies against these attacks:

<http://www.uniras.gov.uk/l1/l2/l3/alerts2004/alert-1704.txt&gt;
<http://www.us-cert.gov/cas/techalerts/TA04-111A.html&gt;

Vendor Information

The vendor has not provided us with any further information regarding this vulnerability.

Addendum

The CERT/CC has no additional comments at this time.

If you have feedback, comments, or additional information about this vulnerability, please send us [email](<mailto:[email protected]?Subject=VU%23415294 Feedback>).

CVSS Metrics

Group	Score	Vector
Base
Temporal
Environmental

References

• <http://www.uniras.gov.uk/niscc/docs/al-20040420-00199.html?lang=en&gt;
• <http://www.niscc.gov.uk/niscc/docs/re-20040420-00391.pdf&gt;
• <http://www.ietf.org/rfc/rfc3562.txt&gt;
• <http://www.ietf.org/rfc/rfc2385.txt&gt;
• <http://www.ietf.org/rfc/rfc1323.txt&gt;
• <http://www.osvdb.org/displayvuln.php?osvdb_id=4030&gt;

Acknowledgements

Thanks to Paul Watson for reporting this vulnerability and to NISCC and Cisco Systems for their coordination.

This document was written by Jason A Rafail.

Other Information

CVE IDs:	CVE-2004-0230
Severity Metric:	12.90 Date Public: