When it rains, it pours. Earlier today we saw the public release of vulnerabilities in the implementation of BGP with respect to TCP reset attacks. This evening Cisco published an advisory concerning vulnerabilities in their implementation of SNMP in some versions of the 12.x IOS. The impact of any successful attacks against the vulnerability might result in a denial of service condition. Because of the popularity of Cisco devices and the widespread use of this version of their IOS, the Storm Center urges all Cisco router and switch administrators to check their IOS version and patch if needed by following the instructions on the Cisco web site at
http://www.cisco.com/warp/public/707/cisco-sa-20040420-snmp.shtml
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 http://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 ( http://www.zebra.org ):

This routing package for Linux, FreeBSD, NetBSD, and OpenBSD does not appear to support RFC2385 MD5 checksums.
Quagga routing daemon ( http://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 ( http://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 ( http://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

http://webchat.webchat.org/~jk/securebgp/
FreeBSD ( http://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.

http://people.freebsd.org/~bms/dump/quagga-tcpmd5/
http://people.freebsd.org/~bms/dump/tcpdump-rfc2385/
OpenBSD ( http://www.openbsd.org ):

The OpenBSD kernel in OpenBSD 2.6 and above contains RFC 2385 support.
NetBSD ( http://www.netbsd.org ):

The NetBSD operating system does not appear to have RFC 2385 support.
Solaris ( http://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: http://www.uniras.gov.uk/vuls/2004/236929/index.htm


Cisco announcement:

http://www.cisco.com/warp/public/707/cisco-sa-20040420-tcp-ios.shtml


Juniper announcement (none yet, will be updated when available):

http://www.juniper.net/


CERT advisory:

http://www.us-cert.gov/cas/techalerts/TA04-111A.html


CVE entry: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2004-0230


Configuring BGP on Cisco:

http://www.cisco.com/univercd/cc/td/doc/product/software/ios120/12cgcr/np1_r/1rprt1/1rbgp.htm#wp1019545
http://www.bind.com/cisco/1cbgp.htm#xtocid2382854


Configuring BGP authentication on Juniper:

http://www.juniper.net/techpubs/software/junos/junos60/swconfig60-routing/html/bgp-config20.html

http://www.qorbit.net/documents/junos-bgp-template.pdf

http://www.qorbit.net/documents/junos-bgp-appnote.pdf


Global Instability Index, a measure of change in BGP routing tables:

http://people.ists.dartmouth.edu/~dmcgrath/gii/


Protect BGP sessions with the TCP MD5 option:

http://bgphints.ruud.org/articles/bgp-md5.html

http://www.cymru.com/Documents/secure-bgp-template.html


RFC 2385, Protection of BGP Sessions via the TCP MD5 Signature Option

http://www.ietf.org/rfc/rfc2385.txt


Restricting BGP sessions to specific AS numbers on Cisco:

http://www.cisco.com/en/US/tech/tk365/tk80/technologies_tech_note09186a0080094a92.shtml


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


Permanent location for this advisory:

http://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