When I first saw this article it looked like the old man in the middle
attack. That has been around for a very long time, in fact it is the attack
used by Kevin Mitnick. It was always a very difficult attack to carry out
since you had to guess sequence numbers and do a lot of other strange
things. However, it seems someone has found a much easier, more reliable
way to do it and that is what all the fuss is about.
Still seems like it would be a tough thing to carry out.
Jim Edwards
-----Original Message-----
From: Hal Dorsman [mailto:hdorsman AT RMEF DOT ORG]
Sent: Wednesday, April 21, 2004 8:48 AM
To: FW-1-MAILINGLIST AT AMADEUS.US.CHECKPOINT DOT COM
Subject: Re: [FW-1] Serious vulnerability found that could affect all
Internet
Here is the CERT alert on this issue.
Hal
-----Original Message-----
From: Christian ALT [mailto:calt AT TLA DOT CH]
Sent: Tue 4/20/2004 3:59 PM
To: FW-1-MAILINGLIST AT AMADEUS.US.CHECKPOINT DOT COM
Cc:
Subject: [FW-1] Serious vulnerability found that could affect all
Internet
-----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-----
=================================================
To set vacation, Out-Of-Office, or away messages,
send an email to LISTSERV AT amadeus.us.checkpoint DOT com
in the BODY of the email add:
set fw-1-mailinglist nomail
=================================================
To unsubscribe from this mailing list,
please see the instructions at
http://www.checkpoint.com/services/mailing.html
=================================================
If you have any questions on how to change your
subscription options, email
fw-1-owner AT ts.checkpoint DOT com
=================================================
=================================================
To set vacation, Out-Of-Office, or away messages,
send an email to LISTSERV AT amadeus.us.checkpoint DOT com
in the BODY of the email add:
set fw-1-mailinglist nomail
=================================================
To unsubscribe from this mailing list,
please see the instructions at
http://www.checkpoint.com/services/mailing.html
=================================================
If you have any questions on how to change your
subscription options, email
fw-1-owner AT ts.checkpoint DOT com
=================================================
|
