Message-ID: <6130FAF67D15D411BF7100E01899071F95D5F2@STORK>
From: david.vincent at mightyoaks.com (David Vincent)
Subject: Core Internet Vulnerable - News at 11:00

> Does anyone know WTF they are trying to say in this AP article,
> "Core Internet Technology Is Vulnerable,"
> 
>   
> http://story.news.yahoo.com/news?tmpl=story&cid=562&ncid=738&e
> =1&u=/ap/20040420/ap_on_hi_te/internet_threat
> 
> It sounds like they are talking about a sequence number guessing
> attack on TCP BGP sessions? Sequence number prediction isn't really
> a new attack, but the story says,
> 
>   "Experts previously maintained 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."

Check this out:

-d 

-----Original Message-----
From: Opscen (OCIPEP / GEOCC) [mailto:Opscen@...PC-SPPCC.GC.CA] 
Sent: Tuesday April 20, 2004 9:40 AM
To: _PSEP/SPPC DISTRIBUTION
Subject: PSEPC AV04-019 SPPCC - TCP 

La version fran?aise suit


PUBLIC SAFETY AND EMERGENCY PREPAREDNESS CANADA

*****************
    ADVISORY 
*****************

Number: AV04-019
Date:  20 April 2004

********************************************
Potential Reliability Issue in TCP
********************************************

PURPOSE
The purpose of this advisory is to bring attention to a possible
vulnerability affecting the implementation of the Transmission Control
Protocol (TCP).  

TCP is a core network protocol used in the majority of networked computer
systems today. Many vendors include support for this protocol in their
products and may be impacted to varying degrees. Furthermore, any network
service or application that relies on a TCP connection could be impacted,
the severity depending primarily on the duration of the TCP session.  


ASSESSMENT
The issue described in this advisory is the practicability of resetting an
established TCP connection by sending suitable TCP packets with the Reset
(RST) or Synchronize (SYN) flags set. 

The packets need to have source and destination IP addresses that match the
established connection as well as the same source and destination TCP ports.
The fact that TCP sessions can be reset by sending suitable RST and SYN
packets is a design feature of TCP according to RFC 793. Although a denial
of service vulnerability using crafted TCP packets is a well known weakness
of TCP, until recently it was believed that a successful denial of service
attack was not achievable in practice. The reason for this is that the
receiving TCP implementation checks the sequence number of the RST or SYN
packet, which is a 32 bit number, giving a chance of 1/2^32 of guessing the
sequence number correctly (assuming a random distribution). It was
discovered that the probability of guessing an acceptable sequence number is
much higher than 1/2^32 because the receiving TCP implementation will accept
any sequence number in a certain range of the expected sequence number.

The impact of this vulnerability varies by vendor and application, but in
some deployment scenarios it is rated critical.   If exploited, the
vulnerability could allow an attacker to create a Denial of Service (DoS)
condition against existing TCP connections, resulting in a premature session
termination. 

The following application layer protocol is judged to be potentially most
affected by this vulnerability: 

Border Gateway Protocol (BGP) 

BGP relies on a persistent TCP session between BGP peers. Resetting the
connection can result in medium term unavailability due to the need to
rebuild routing tables and route flapping dampening if the connection is
lost several times in succession. The overall impact on BGP is likely to be
moderate based on the likelihood of successful attack. If the TCP MD5
Signature Option is used then the impact will be low as this measure will
successfully mitigate the vulnerability. 

There is a potential impact on other application protocols such as DNS
(Domain Name System) and SSL (Secure Sockets Layer) in the case of zone
transfers and e-commerce transactions, the duration of the sessions is
relatively short and the sessions can be restarted without medium term
unavailability problems. In the case of SSL it may be difficult to guess the
source IP address. Data injection may be possible. However, this has not
been demonstrated and appears to be problematic. 


SUGGESTED ACTION
PSEPC recommends security administrators work with vendors for the
workaround most appropriate for the product in question.  In the absence of
vendor patching of the TCP implementation, the following are general
mitigating steps: 

1) Implement IP Security (IPSEC) which will encrypt traffic at the network
layer, so TCP information will not be visible 
2) Reduce the TCP window size (although this could increase traffic loss and
subsequent retransmission). 
3) Do not publish TCP source port information. 

To change the TCP window size, in some Unix variants you can set a value of
the default TCP windows size by using the sysctl program (ndd -set) in the
case of Sun Solaris. In the case of Microsoft Windows NT/2000/XP/2003, the
default window size can be changed by modifying the value of the
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters key.
As noted above, great care should be exercised when altering the default TCP
window size as network performance could be adversely affected. 

In the case of BGP, the following may counter the issue: 

Implement ingress and egress filtering to check that the traffic entering or
leaving the network has a source IP address that is expected on the
router/firewall interface that receives the traffic. Implement the TCP MD5
Signature Option to checksum the TCP packet carrying the BGP application
data (see RFC 2385, http://www.ietf.org/rfc/rfc2385.txt). 

Additional informaiton: http://www.uniras.gov.uk/vuls/2004/236929/index.htm


Note to Readers

Public Safety and Emergency Preparedness Canada (PSEPC) collects information
related to cyber and physical threats to, and incidents involving, Canadian
critical infrastructure. This allows us to monitor and analyse threats and
to issue alerts, advisories and other information products to our partners.
To report threats or incidents, please contact the PSEPC operations
coordination centre at (613) 991-7000 or opscen@...pep-bpiepc.gc.ca by
e-mail.

Unauthorized use of computer systems and mischief in relation to data are
serious Criminal Code offences in Canada. Any suspected criminal activity
should be reported to local law enforcement organizations. The RCMP National
Operations Centre (NOC) provides a 24/7 service to receive such reports or
to redirect callers to local law enforcement organizations. The NOC can be
reached at (613) 993-4460. National security concerns should be reported to
the Canadian Security Intelligence Service (CSIS) at (613) 993-9620.

For general information on critical infrastructure protection and emergency
preparedness, please contact our Public Affairs division at:

Telephone: (613) 944-4875 or 1-800-830-3118
Fax: (613) 998-9589
E-mail: communications@...pep-bpiepc.gc.ca
Web: www.ocipep-bpiepc.gc.ca 

....

Powered by blists - more mailing lists