said by MSNBC:

---

Researchers found a serious security flaw that left core Internet technology vulnerable to hackers, prompting a secretive effort by international governments and industry experts in recent weeks to prevent global disruptions of Web surfing, e-mails and instant messages.
...
Watson, who runs the www.terrorist.net Web site, predicted that hackers will understand how to begin launching attacks "within five minutes of walking out of that meeting."

---

said by Daemon :

---

it appears the designers didn't anticipate the maliciousness of the people who would eventually be using the internet.

---

Vulnerability Issues in TCP - Updated; SANS Top-20 Call for Experts
The UK National Infrastructure Security Co-Ordination Centre (NISCC) released a vulnerability advisory today on issues in the TCP protocol.
The full advisory is available at »www.uniras.gov.uk/vuls/2004/236929/index.htm

According to NISCC, The Border Gateway Protocol (BGP) is judged to be potentially most affected by this vulnerability. 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. Route flapping may result in route dampening (suppression) if the route flaps occur frequently within a short time interval. The overall impact on BGP is likely to be moderate based on the likelihood of successful attack. If the TCP MD5 Signature Option and anti-spoofing measures are used then the impact will be low as these measures will successfully mitigate the vulnerability.

Cisco and Juniper are scheduled to publish announcements about vulnerabilities in the implementation of the BGP code in their respective routers this week. The problem is unauthenticated resets of BGP sessions; a full fix requires replacing the router operating system. The respective advisories will include details on where to get updated operating system images.

A temporary workaround to the problem is to enable MD5 checksums on BGP sessions so that BGP peers can authenticate each other's packets and ignore spoofed TCP resets.

TCP resets can be sent without knowing the exact sequence number used on the TCP connection; by simply landing somewhere in the current TCP window, the RST will succeed.

The SANS Internet Storm Center encourages all BGP enabled Juniper or Cisco router administrators to turn on MD5 checksums as soon as possible while testing the patch supplied by router vendors. A widespread attack on BGP sessions and routing tables has the potential to destabilize the Internet, however most ISP's have already applied the appropriate patches and reduced the probability of such an attack.

Below are instructions on how to enable MD5 checksums for several router platforms, additional details on Unix platforms and routing daemons, and reference links with more information on BGP MD5 checksums.

Cisco IOS configuration:

To enable MD5 checksums between BGP peers, enter the following commands from global configuration mode:

router bgp {your_AS_number}
neighbor A.B.C.D password {long_password_value}

So for example, to configure a router that is part of AS 64512 to peer with the router at 10.1.1.2 using the password "a1b2c3d4e5f6g7h8", you would enter:

router bgp 64512
neighbor 10.1.1.2 password a1b2c3d4e5f6g7h8

Please note that the router at 10.1.1.2 would also have to be configured to use the password a1b2c3d4e5f6g7h8 during the peering session as well.

The specific commands to use, including a directive to log when a neighbor joins or leaves a peering arrangement would be:

rtr1#! router 1, local peering address is 10.1.1.1
rtr1#conf term
Enter configuration commands, one per line. End with CNTL/Z.
rtr1(config)#router bgp 64512
rtr1(config-router)#neighbor 10.1.1.2 password a1b2c3d4e5f6g7h8
rtr1(config-router)#bgp log-neighbor-changes
rtr1(config-router)#end
rtr1#copy running-config startup-config

The step of copying the running-config to the startup-config needs to be performed at some point. You may wish to wait until the connection is confirmed to be stable before performing this step, which makes the change persist even when the router is powered off.

Juniper router configuration:

On Juniper routers, the

authentication-key a1b2c3d4e5f6g7h8

statement can be used globally, on a particular group, or for an individual BGP peer, using one of the following choices:

edit protocols bgp
edit protocols bgp group {groupname}
edit protocols bgp group {groupname} neighbor {address}

respectively.

Other platforms:

General-purpose Unix platforms also include BGP peering software in the Zebra and Quagga cross-platform daemons and OpenBSD's bgpd. The MD5 checksum checks need to occur in the operating system kernel, so support for MD5 checksums depends on the operating system kernel as well as on the routing software.

Zebra routing daemon (»www.zebra.org ):

This routing package for Linux, FreeBSD, NetBSD, and OpenBSD does not appear to support RFC2385 MD5 checksums.

Quagga routing daemon (»www.quagga.net ):

According to the documentation, this routing package for Linux, FreeBSD, NetBSD, OpenBSD, and Solaris does not appear to natively support RFC 2385 MD5 checksums. Please see FreeBSD for some patches for that operating system and Quagga.

Bgpd routing daemon:

OpenBSD's bgpd routing daemon supports rfc 2385 checksums.

Tcpdump packet sniffer (»www.tcpdump.org ):

The CVS repository for the tcpdump package includes support for RFC 2385 MD5 checksums via the "-M" command line parameter.

Linux operating system (»www.kernel.org ):

The Linux kernel does not support RFC 2385 MD5 checksums natively. There is support in the form of a kernel patch and additional library at
»webchat.webchat.org/~jk/securebgp/

FreeBSD (»www.freebsd.org ):

FreeBSD contains output-only support for RFC 2385. This allows it to connect to a router over a signed connection, but does not accept incoming RFC 2385 connections.

»people.freebsd.org/~bms/dump/quagga-tcpmd5/
»people.freebsd.org/~bms/dump/tcp···rfc2385/

OpenBSD (»www.openbsd.org ):

The OpenBSD kernel in OpenBSD 2.6 and above contains RFC 2385 support.

NetBSD (»www.netbsd.org ):

The NetBSD operating system does not appear to have RFC 2385 support.

Solaris (»www.sun.com ):

The Solaris operating system does not appear to have RFC 2385 support.

General:

Because Cisco implementations only allow 80 character passwords, we recommend you stay under that limit if you either use or peer with any Cisco routers. Juniper routers will go up to 255 characters. The RFC recommends 12 to 24 character passwords. Remember that the password needs to be applied to _both_ peers in a BGP session. If one of the peers does not support RFC 2385, MD5 checksums must be left off for the BGP session between them.

BGP passwords are case sensitive and should not include spaces.

References:

NISCC advisory: »www.uniras.gov.uk/vuls/2004/236929/index.htm

Cisco announcement (none yet, will be updated when available):
»www.cisco.com/

Juniper announcement (none yet, will be updated when available):
»www.juniper.net/

CERT advisory (none yet, will be updated when available):
»www.cert.org/advisories/ »www.us-cert.gov/

CVE entry: »cve.mitre.org/cgi-bin/cvename.cg···004-0230

Configuring BGP on Cisco:
»www.cisco.com/univercd/cc/td/doc···p1019545 »www.bind.com/cisco/1cbgp.htm#xtocid2382854

Configuring BGP authentication on Juniper:
»www.juniper.net/techpubs/softwar···g20.html
»www.qorbit.net/documents/junos-b···late.pdf
»www.qorbit.net/documents/junos-b···note.pdf

Global Instability Index, a measure of change in BGP routing tables:
»people.ists.dartmouth.edu/~dmcgrath/gii/

Protect BGP sessions with the TCP MD5 option:
»bgphints.ruud.org/articles/bgp-md5.html
»www.cymru.com/Documents/secure-b···ate.html

RFC 2385, Protection of BGP Sessions via the TCP MD5 Signature Option
»www.ietf.org/rfc/rfc2385.txt

Restricting BGP sessions to specific AS numbers on Cisco:
»www.cisco.com/en/US/tech/tk365/t···92.shtml

BGP vulnerability discussion:»www.nanog.org/mtg-0306/pdf/franz.pdf

Permanent location for this advisory:
»isc.sans.org/diary.php?date=2004-04-20

Credits:
- Bill Stearns, the SANS Institute
- Marcus Sachs, the SANS Institute
- Chris Brenton
- Josh Wright, the SANS Institute
- Thanks to the SANS incident handlers for additional notes and assistance.
- Thanks also to the authors of the above web resources.

(Version 0.3.2, 4/20/2004)

========

Call For Experts, SANS Top 20 List for 2004
SANS is looking for experts to participate in the development of the 2004 list of Top 20 Vulnerabilities. If you are interested in helping drive and develop the 2004 research please contact the Editor, Mr. Ross Patel (rpatel@sans.org), with the following details:
• your name
• organisation you represent
• contact details (inc. email and phone)
• a very brief synopsis of your sphere of specialism

=========

Marcus H. Sachs
The SANS Institute

said by Daemon :

---

The flaw is in TCP. Since TCP over IPv4 is the same as TCP over IPv6, it wouldn't make much of a difference....

---