Vulnerabilities in TCP

• Systems that rely on persistent TCP connections, for example
  routers supporting BGP

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.

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 Analysis 236929.

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 (VU#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 a 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 Vulnerability Advisory 236929.

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.

Solution

Apply a patch from your vendor

Please see your 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, and 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
or US-CERT Vulnerability Note VU#415294. 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.

Revision History

• April 20, 2004: Initial release
  
  September 9, 2005: Updated NISCC references
  

  Last updated