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
