Full Disclosure mailing list archives
RE: Core Internet Vulnerable - News at 11:00
From: David Vincent <david.vincent () mightyoaks com>
Date: Tue, 20 Apr 2004 12:31:21 -0700
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 () PSEPC-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 () ocipep-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 () ocipep-bpiepc gc ca Web: www.ocipep-bpiepc.gc.ca .... _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.netsys.com/full-disclosure-charter.html
Current thread:
- Re: Core Internet Vulnerable - News at 11:00, (continued)
- Re: Core Internet Vulnerable - News at 11:00 Exibar (Apr 20)
- RE: Core Internet Vulnerable - News at 11:00 Alerta Redsegura (Apr 20)
- RE: Core Internet Vulnerable - News at 11:00 Jade E. Deane (Apr 20)
- Re: Core Internet Vulnerable - News at 11:00 Alexander Bochmann (Apr 21)
- Re: Core Internet Vulnerable - News at 11:00 Pavel Kankovsky (Apr 20)
- Re: Core Internet Vulnerable - News at 11:00 Exibar (Apr 20)
- Re: Core Internet Vulnerable - News at 11:00 james (Apr 20)
- Re: Core Internet Vulnerable - News at 11:00 Michael Schaefer (Apr 20)
- NISCC Vulnerability Advisory 236929: Vulnerability Issues in TCP (was Re: [Full-Disclosure] Core Internet Vulnerable - News at 11:00) Chris McCulloh (Apr 20)
- Re: Core Internet Vulnerable - News at 11:00 Gregory A. Gilliss (Apr 20)
- RE: Core Internet Vulnerable - News at 11:00 David Vincent (Apr 20)
- RE: Core Internet Vulnerable - News at 11:00 Compton, Rich (Apr 20)
- RE: Core Internet Vulnerable - News at 11:00 SturmM (Apr 20)
- RE: Core Internet Vulnerable - News at 11:00 Jos Osborne (Apr 21)