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 (<http://www.cert.org/advisories/CA-2001-09.html>),
   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
   <http://www.uniras.gov.uk/vuls/2004/236929/index.htm>.

   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
   (<http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/bgp.htm>
   or Team Cymru (<http://www.cymru.com/>). 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-----

http://online.securityfocus.com/archive/1/360790/2004-04-17/2004-04-23/0

--
Regard: Joh@nnes �  :-))
"If U know neither the enemy nor yourself,U will succumb in every battle"

0 Johannes 4/20/2004 10:17:00 PM

Internet Technology Vulnerable


 Email this Story

Apr 20, 4:24 PM (ET)

By TED BRIDIS


WASHINGTON (AP) - Researchers uncovered a serious flaw in the underlying
technology for nearly all Internet traffic, a discovery that led to an
urgent and secretive international effort to prevent global disruptions of
Web surfing, e-mails and instant messages.

The British government announced the vulnerability in core Internet
technology on Tuesday. Left unaddressed, experts said, it could allow
them to knock computers offline and broadly disrupt vital
traffic-directing devices, called routers, that coordinate the flow of data
among distant groups of computers.

"Exploitation of this vulnerability could have affected the glue that holds
the Internet together," said Roger director for England's National
Infrastructure Security Coordination Centre.

The Homeland Security Department issued its own cyberalert hours later that
attacks "could affect a large segment of the Internet community." It said
normal Internet operations probably would resume after such attacks stopped.

The risk was similar to Internet users "running naked through the jungle,
which didn't matter until somebody released some tigers," said Paul Vixie of
the Internet Systems Consortium Inc.

"It's a significant risk," Vixie said. "The larger Internet providers are
jumping on this big time. It's really important this just gets fixed before
the bad guys start exploiting it for fun and recognition."

The flaw affecting the Internet's "transmission control protocol," or TCP,
was discovered late last year by a computer researcher in Milwaukee. Paul
Watson said he identified a method to reliably trick personal computers and
routers into shutting down electronic conversations by resetting the
machines remotely.

Routers continually exchange important updates about the most efficient
traffic routes between large networks. Continued successful attacks against
routers can cause them to go into a standby mode, known as "dampening," that
can persist for hours.

Experts previously said such attacks could take between four years and 142
years to succeed because they require guessing a rotating number from
roughly 4 billion possible combinations. Watson said he can guess the proper
number with as few as four attempts, which can be accomplished within
seconds.

Already in recent weeks, some U.S. government agencies and companies
operating the most important digital pipelines have fortified their own
vulnerable systems because of early warnings communicated by some security
organizations. The White House has expressed concerns especially about risks
to crucial Internet routers because attacks against them could profoundly
disrupt online traffic.

"Any flaw to a fundamental protocol would raise significant concern and
require significant attention by the folks who run the major infrastructures
of the Internet," said Amit Yoran, the government's cybersecurity chief. The
flaw has dominated discussions since last week among experts in security
circles.

The public announcement coincides with a presentation Watson expects to make
Thursday at an Internet security conference in Vancouver, British Columbia,
where Watson said he would disclose full details of his research.

Watson predicted that would understand how to begin launching
attacks "within five minutes of walking out of that meeting."

---

On the Net:

U.K. National Infrastructure Security Coordination Centre: www.niscc.gov.uk

Homeland Security cyberdivision: www.us-cert.gov

http://apnews.myway.com/article/20040420/D822OE4O0.html

--
Regard: Joh@nnes �  :-))
"If U know neither the enemy nor yourself,U will succumb in every battle"

0 Johannes 4/21/2004 12:55:00 AM