GroupStudy.com GroupStudy.com - A virtual community of network engineers
 Home  BookStore  StudyNotes  Links  Archives  StudyRooms  HelpWanted  Discounts  Login
RE: Experts Report Major Internet Vulnerability [7:87498] posted 04/21/2004
[Chronological Index] [Thread Index] [Top] [Date Prev][Date Next] [Thread Prev][Thread Next]


You know what, just ignore the below message.
I need to lay off the tea.

	-----Original Message----- 
	From: Patrick Aland 
	Sent: Tue 4/20/2004 8:02 PM 
	To: cisco@xxxxxxxxxxxxxx 
	Cc: 
	Subject: RE: Experts Report Major Internet Vulnerability [7:87498]
	
	

	Won't the "RST check" occur at layer 3 while the MD5 check won't occur
until
	layer 4?
	
	        -----Original Message-----
	        From: Jim Devane [mailto:jim@xxxxxxxxxxxxx]
	        Sent: Tue 4/20/2004 7:42 PM
	        To: cisco@xxxxxxxxxxxxxx
	        Cc:
	        Subject: RE: Experts Report Major Internet Vulnerability [7:87498]
	       
	       
	
	        The vulnerability is based on spoofed packets that purport to be
part of
	the
	        host-to-host communication. MD5 helps mitigate since is tries to
verify who
	        the other side of the conversation is with. Spoofing becomes very
difficult
	        at that point.
	       
	        Said a different way, TCP has no method to verify the validity of a
packet.
	        MD5, being hashing a password, helps verify the end point of the
	        conversation.
	       
	        Or... I want to try to wake you up in the middle of the night by
calling
	        your house. But I know you won't answer unless the caller-id shows
your
	        friends house. So I spoof the caller-id and start guessing your
phone
	        number. Eventually, I might get it.. and you will look at the
callerid and
	        answer the phone. ( attack successful )
	       
	        MD5 says that you have to have a caller-id of the friend and then
give me a
	        secret password that only the two phones have. For a hacker is it
is not
	        worth my time at that point.
	       
	        There are easier ways to get your attention..
	       
	        I will just get Jurassic on you and send 10 Mb/s to the router
itself
	       
	        OR
	       
	        I will send a bunch of MD5 packets for you router to hash
	       
	        OR
	       
	        I will .... you get the idea.
	       
	       
	        -----Original Message-----
	        From: nobody@xxxxxxxxxxxxxx [mailto:nobody@xxxxxxxxxxxxxx] On
Behalf Of
	        Patrick Greene
	        Sent: Tuesday, April 20, 2004 4:26 PM
	        To: cisco@xxxxxxxxxxxxxx
	        Subject: RE: Experts Report Major Internet Vulnerability [7:87498]
	       
	        The Juniper alert indicates one of the mitigation steps is to
enable BGP
	        with MD5 auth.  I don't understand how this would mitigate an
attack at
	        the TCP layer itself.  Am I missing something?
	       
	        Thx,
	        Patrick
	       
	        -----Original Message-----
	        From: nobody@xxxxxxxxxxxxxx [mailto:nobody@xxxxxxxxxxxxxx] On
Behalf Of
	        Howard C. Berkowitz
	        Sent: Tuesday, April 20, 2004 5:05 PM
	        To: cisco@xxxxxxxxxxxxxx
	        Subject: Re: Experts Report Major Internet Vulnerability [7:87498]
	       
	        At 8:16 PM +0000 4/20/04, Fares.Nabil@xxxxxxxxxxxxxxx wrote:
	       
	        At 3:33 PM -0400 4/20/04, CERT Advisory wrote:
	        >-----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-----
	        **Please support GroupStudy by purchasing from the GroupStudy
Store:
	        http://shop.groupstudy.com
	        FAQ, list archives, and subscription info:
	        http://www.groupstudy.com/list/cisco.html
	        **Please support GroupStudy by purchasing from the GroupStudy
Store:
	        http://shop.groupstudy.com
	        FAQ, list archives, and subscription info:
	        http://www.groupstudy.com/list/cisco.html
	        **Please support GroupStudy by purchasing from the GroupStudy
Store:
	        http://shop.groupstudy.com
	        FAQ, list archives, and subscription info:
	http://www.groupstudy.com/list/cisco.html
	**Please support GroupStudy by purchasing from the GroupStudy Store:
	http://shop.groupstudy.com
	FAQ, list archives, and subscription info:
http://www.groupstudy.com/list/cisco.html




Message Posted at:
http://www.groupstudy.com/form/read.php?f=7&i=87523&t=87498
--------------------------------------------------
**Please support GroupStudy by purchasing from the GroupStudy Store:
http://shop.groupstudy.com
FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html