- Test - lists.nanog.org

RE: Winstar says there is no TCP/BGP vulnerability
by Michel Py 21 Apr '04

21 Apr '04

Patrick / Christopher, >> Michel Py wrote: >> Please forgive me if I'm naive and/or ask a stupid question, >> but is there any reason (besides your platform not supporting >> it) _not_ to MD5 your BGP sessions? Geez, on my _home_ router >> all my v4 BGP sessions are MD5ed (v6 not there yet). > Patrick W.Gilmore wrote: > There is serious operational overhead in maintaining sync'ed > passwords between separate organizations. IOW: Eventually > someone will screw up and lose the password. > [large snip] Thanks for the insight. I have an even dumber question: Context: set aside the MD5, the way I configure BGP sessions/traffic from/to peers is as follows: a) A generic (configured in the peer-group) route-map to filter the routes I announce to the peer to be only my blocks. b) A specific-to-the-peer route-map to filter the routes I receive from the peer to the peer's blocks, as agreed in the beer drinking meeting ^H^H^H^H BLPA. This route map is not entirely specific, as I also put in stuff such as deny RFC1918 routes ;-) c) A generic access-list filtering ingress traffic from the peer to me to allow only traffic which DA is mine. (cracks me up if the peer sets a default to me :-) d) A generic access-list filtering egress traffic from me to the peer to allow only traffic which SA is mine. Now, the dumb question: Given: 1) The context above especially item b 2) Christopher Morrow's comments below Explain me what having or not having the MD5 password changes. Either you're small and/or stupid and do it manually, or you have an automated system that does it for you. > Christopher L. Morrow wrote: > there is the issue of changing the keys during operations > without impacting the network, eh? Having to bounce every > bgp session in your network can be pretty darned painful... > if you change the key(s) of course. See above: Changing the route-map is equally painful. > If you don't you might as well not have keys, since adding > the 3 lines of C code required to Paul Watsons' program > making it do the hashing certainly won't be a big deal, eh? I'm weak with C. Besides adding "neighbor x.x.x.x password 7 " below "enable-password 7 " for each peer (which requires recompiling, how annoying) would you care sharing the 3 said lines for the code below :-) Michel. #include <stdio.h> #include <ctype.h> char xlat[] = { 0x64, 0x73, 0x66, 0x64, 0x3b, 0x6b, 0x66, 0x6f, 0x41, 0x2c, 0x2e, 0x69, 0x79, 0x65, 0x77, 0x72, 0x6b, 0x6c, 0x64, 0x4a, 0x4b, 0x44 }; char pw_str1[] = "password 7 "; char pw_str2[] = "enable-password 7 "; char *pname; cdecrypt(enc_pw, dec_pw) char *enc_pw; char *dec_pw; { unsigned int seed, i, val = 0; if(strlen(enc_pw) & 1) return(-1); seed = (enc_pw[0] - '0') * 10 + enc_pw[1] - '0'; if (seed > 15 || !isdigit(enc_pw[0]) || !isdigit(enc_pw[1])) return(-1); for (i = 2 ; i <= strlen(enc_pw); i++) { if(i !=2 && !(i & 1)) { dec_pw[i / 2 - 2] = val ^ xlat[seed++]; val = 0; } val *= 16; if(isdigit(enc_pw[i] = toupper(enc_pw[i]))) { val += enc_pw[i] - '0'; continue; } if(enc_pw[i] >= 'A' && enc_pw[i] <= 'F') { val += enc_pw[i] - 'A' + 10; continue; } if(strlen(enc_pw) != i) return(-1); } dec_pw[++i / 2] = 0; return(0); } usage() { fprintf(stdout, "Usage: %s -p <encrypted password>\n", pname); fprintf(stdout, " %s <router config file> <output file>\n", pname); return(0); } main(argc,argv) int argc; char **argv; { FILE *in = stdin, *out = stdout; char line[257]; char passwd[65]; unsigned int i, pw_pos; pname = argv[0]; if(argc > 1) { if(argc > 3) { usage(); exit(1); } if(argv[1][0] == '-') { switch(argv[1][1]) { case 'h': usage(); break; case 'p': if(cdecrypt(argv[2], passwd)) { fprintf(stderr, "Error.\n"); exit(1); } fprintf(stdout, "password: %s\n", passwd); break; default: fprintf(stderr, "%s: unknow option.", pname); } return(0); } if((in = fopen(argv[1], "rt")) == NULL) exit(1); if(argc > 2) if((out = fopen(argv[2], "wt")) == NULL) exit(1); } while(1) { for(i = 0; i < 256; i++) { if((line[i] = fgetc(in)) == EOF) { if(i) break; fclose(in); fclose(out); return(0); } if(line[i] == '\r') i--; if(line[i] == '\n') break; } pw_pos = 0; line[i] = 0; if(!strncmp(line, pw_str1, strlen(pw_str1))) pw_pos = strlen(pw_str1); if(!strncmp(line, pw_str2, strlen(pw_str2))) pw_pos = strlen(pw_str2); if(!pw_pos) { fprintf(stdout, "%s\n", line); continue; } if(cdecrypt(&line[pw_pos], passwd)) { fprintf(stderr, "Error.\n"); exit(1); } else { if(pw_pos == strlen(pw_str1)) fprintf(out, "%s", pw_str1); else fprintf(out, "%s", pw_str2); fprintf(out, "%s\n", passwd); } } }

3 2

RE: Winstar says there is no TCP/BGP vulnerability
by Michel Py 21 Apr '04

21 Apr '04

> Rob Thomas wrote: > We manage well over 150 peering sessions with MD5 passwords > in place. This includes bogon peering, route-server peering, > and production traffic peering. This has grown over the past > three years. The total number of MD5-related outages: zero. I have to complain about this: MD5 peering with Team Cymru is boring. I have has some scheduled (and announced prior-to-happening) maintenance outages, but if one has (I do) redundant peering with them, it never goes down and nothing interesting ever happens. Rob, screw up the config from time to time, would you? If nothing ever goes down, half of the readers will be out of a job soon. Michel.

1 0

Nmap to print out the MAC addresses of scanned hosts
by Cemil Degirmenci 20 Apr '04

20 Apr '04

Hello There, maybe Offtopic, but i thought this could be interesting for some of you. Nmap 3.51-TEST3 is released with some nice new features for local networks. Nmap now uses the system interface table (as shown by ifconfig) to determine whether a system is on the same network. A database derived from the one distributed by the IEEE is then consulted to report the manufacturer. Here are examples from normal and XML output: MAC Address: 08:00:20:8F:6B:2F (SUN Microsystems Inc.) <address addr="00:A0:CC:63:85:4B" vendor="Lite-on Communications, Inc." addrtype="mac" /> This will maybe helpful for network administrators to track down problem machines (worm-infected, spammers, etc.) This also helps track changes on DHCP networks where the IP addresses can change frequently. its still in development but seems to work well. -- Mit freundlichen Gruessen / kind regards, Cemil Degirmenci wavecon.de

1 0

Cisco Security Advisory: Vulnerabilities in SNMP Message Processing
by Cisco Systems Product Security Incident Response Team 20 Apr '04

20 Apr '04

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Vulnerabilities in SNMP Message Processing Revision 1.0 INTERIM For Public Release 2004 April 20 UTC 2100 - ----------------------------------------------------------------------- Contents ======== Summary Affected Products Details Impact Software Versions and Fixes Obtaining Fixed Software Workarounds Exploitation and Public Announcements Status of This Notice: INTERIM Distribution Revision History Cisco Security Procedures - ----------------------------------------------------------------------- Summary ======= Cisco Internetwork Operating System (IOS) Software releases trains 12.0S, 12.1E, 12.2, 12.2S, 12.3, 12.3B and 12.3T may contain a vulnerability in processing SNMP requests which, if exploited, could cause the device to reload. The vulnerability is only present in certain IOS releases on Cisco routers and switches. This behavior was introduced via a code change and is resolved with CSCed68575. This vulnerability can be remotely triggered. A successful exploitation of this vulnerability may cause a reload of the device and could be exploited repeatedly to produce a Denial of Service (DoS). This advisory is available at: http://www.cisco.com/warp/public/707/cisco-sa-20040420-snmp.shtml Affected Products ================= This vulnerability was introduced by a code change for CSCeb22276. This change was committed to the following releases, causing these releases to be vulnerable. Note: The list below is not comprehensive; it is provided to help quickly identify some commonly used releases. Please see the Software Versions and Fixes section of this advisory for the complete IOS upgrade table. * 12.0(23)S4, 12.0(23)S5 * 12.0(24)S4, 12.0(24)S5 * 12.0(26)S1 * 12.0(27)S * 12.0(27)SV, 12.0(27)SV1 * 12.1(20)E, 12.1(20)E1, 12.1(20)E2 * 12.1(20)EA1 * 12.1(20)EW, 12.1(20)EW1 * 12.1(20)EC, 12.1(20)EC1 * 12.2(12g), 12.2(12h) * 12.2(20)S, 12.2(20)S1 * 12.2(21), 12.2(21a) * 12.2(23) * 12.3(2)XC1, 12.3(2)XC2 * 12.3(5), 12.3(5a), 12.3(5b) * 12.3(6) * 12.3(4)T, 12.3(4)T1, 12.3(4)T2, 12.3(4)T3 * 12.3(5a)B * 12.3(4)XD, 12.3(4)XD1 To determine the software running on a Cisco product, log in to the device and issue the show version command to display the system banner. Cisco IOS software will identify itself as "Internetwork Operating System Software" or simply "IOS". On the next line of output, the image name will be displayed between parentheses, followed by "Version" and the IOS release name. Other Cisco devices will not have the show version command or will give different output. The following example identifies a Cisco product running IOS release 12.0(3) with an installed image name of C2500-IS-L: Cisco Internetwork Operating System Software IOS (TM) 2500 Software (C2500-IS-L), Version 12.0(3), RELEASE SOFTWARE The release train label is "12.0". The next example shows a product running IOS release 12.0(2a)T1 with an image name of C2600-JS-MZ: Cisco Internetwork Operating System Software IOS (tm) C2600 Software (C2600-JS-MZ), Version 12.0(2a)T1, RELEASE SOFTWARE (fc1) Additional information about Cisco IOS release naming can be found at http://www.cisco.com/warp/public/620/1.html. Details ======= The Simple Network Management Protocol (SNMP) defines a standard mechanism for remote management and monitoring of devices in an Internet Protocol (IP) network. A device or host that supports SNMP is an SNMP entity. There are two classes of SNMP entities: SNMP managers that request information and receive unsolicited messages and SNMP agents that respond to requests and send unsolicited messages. SNMP entities that support SNMP proxy functions combine the functions of both SNMP manager and SNMP agent. There are two classes of SNMP operations: solicited operations such as 'get' or 'set', with which the SNMP manager requests or changes the value of a managed object on an SNMP agent; and unsolicited operations such as 'trap' or 'inform' messages with which the SNMP agent provides an unsolicited notification or alarm message to the SNMP manager. The 'inform' operation is essentially an acknowledged 'trap'. All SNMP operations are transported over the User Datagram Protocol (UDP). Solicited operations are sent by the SNMP manager to the UDP destination port 161 on the agent. Unsolicited operations are sent by the SNMP agent to the UDP destination port 162. In IOS, The acknowledgement sent by the SNMP manager to an SNMP agent in reply to an 'inform' operation is sent to a randomly chosen high port that is chosen when the SNMP process is started. As IOS implements both an SNMP agent and SNMP proxy functionality, the SNMP process in IOS starts listening for SNMP operations on UDP ports 161, 162 and the random UDP port at the time it is initialized. The SNMP process is started either at the time the device boots, or when SNMP is configured. The high port is chosen via the following series of steps: 1. A random number between 49152 and 59152 is generated. 2. IOS checks to see if that UDP port is already being used. If not, that UDP port is selected to receive SNMP 'inform' acknowledge messages. 3. If the port is already in use, IOS increments the port number by 1, and checks again, incrementing until an open port is found. Therefore, the port chosen may be higher than 59152 although this is considered unlikely. In this vulnerability, the IOS SNMP process is incorrectly attempting to process SNMP solicited operations on UDP port 162 and the random UDP port. Upon attempting to process a solicited SNMP operation on one of those ports, the device can experience memory corruption and may reload. SNMPv1 and SNMPv2c solicited operations to the vulnerable ports will perform an authentication check against the SNMP community string, which may be used to mitigate attacks. Through best practices of hard to guess community strings and community string ACLs, this vulnerability may be mitigated for both SNMPv1 and SNMPv2c. However, any SNMPv3 solicited operation to the vulnerable ports will reset the device. If configured for SNMP, all affected versions will process SNMP version 1, 2c and 3 operations. This vulnerability was introduced by DDTS CSCeb22276 and has been corrected with DDTS CSCed68575. Impact ====== Successful exploitation of this vulnerability results in a reload of the device. Repeated exploitation could result in a sustained DoS attack. Software Versions and Fixes =========================== Be advised that Cisco released multiple advisories on 2004-April-20. When considering software upgrades, please also consult http://www.cisco.com/warp/public/707/advisory.html and any subsequent advisories to determine exposure and a complete upgrade solution. Each row of the Cisco IOS software table (below) describes a release train. If a given release train is vulnerable, then the earliest possible releases that contain the fix (the "First Fixed Release") and the anticipated date of availability for each are listed in the "Rebuild," "Interim," and "Maintenance" columns. A device running a release in the given train that is earlier than the release in a specific column (less than the First Fixed Release) is known to be vulnerable. The release should be upgraded at least to the indicated release or a later version (greater than or equal to the First Fixed Release label). When selecting a release, keep in mind the following definitions: * Maintenance - Most heavily tested, stable, and highly recommended release of a release train in any given row of the table. * Rebuild - Constructed from the previous maintenance or major release in the same train, it contains the fix for a specific defect. Although it receives less testing, it contains only the minimal changes necessary to repair the vulnerability. * Interim - Built at regular intervals between maintenance releases and receives less testing. Interims should be selected only if there is no other suitable release that addresses the vulnerability. Interim images should be upgraded to the next available maintenance release as soon as possible. Interim releases are not available through manufacturing, and usually they are not available for customer download from CCO without prior arrangement with the Cisco TAC. To find the information for a given IOS release, compare the release number as reported by the show version command to the major releases in the first column below. For example, if your device reports that it is running 12.3(5), find the row in the table for "12.3". Reading across to the right, you find 12.3(5c) in the Rebuild column, indicating that 12.3(5) through 12.3(5b) are vulnerable. Since 12.3(5c) is already available for download from CCO, you could upgrade to it as soon as possible. If a release train is labeled "Vulnerable", then migration to another release train should be considered. Except where a release label in a different release train is explicitly identified in the table below, customers should contact the Cisco TAC for assistance to identify the appropriate migration path. If migration is not possible, then workarounds may be the only alternative. In all cases, customers should exercise caution to confirm that the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new software release. If the information is not clear, contact the Cisco TAC for assistance as shown in the "Obtaining Fixed Software" section below. More information on Cisco IOS software release names and abbreviations is available at http://www.cisco.com/warp/public/620/1.html. The fixes will be available at the Software Center located at http://www.cisco.com/public/sw-center/. +-------------------------------------------------------------------+ | Major Release | Availability of Repaired Releases | |-------------------+-----------------------------------------------| | Affected 12.0 | Rebuild | Interim | Maintenance | | -Based Release | | | | |-------------------+---------------+---------------+---------------| | | 12.0(23)S6 | | | | |---------------+---------------+---------------| | | 12.0(24)S6 - | | | | | Due on CCO | | | | 12.0S | mid-May, | | | | | 2004. | | | | |---------------+---------------+---------------| | | 12.0(26)S2 | | | | |---------------+---------------+---------------| | | 12.0(27)S1 | | | |-------------------+---------------+---------------+---------------| | | 12.0(27)SV2 - | | | | 12.0SV | contact TAC. | | | | | Available | | | | | upon request. | | | |-------------------+---------------+---------------+---------------| | Affected 12.1 | Rebuild | Interim | Maintenance | | -Based Release | | | | |-------------------+---------------+---------------+---------------| | | 12.1(20)E3 - | | | | | Due on CCO | | | | | April 20, | | | | | 2004. | | | | 12.1E |---------------+---------------+---------------| | | 12.1(22)E1 - | | | | | Due on CCO | | | | | April 20, | | | | | 2004. | | | |-------------------+---------------+---------------+---------------| | | 12.1(20)EA1a | | | | 12.1EA | - Due on CCO | | | | | April 21, | | | | | 2004. | | | |-------------------+---------------+---------------+---------------| | | 12.1(20)EC2 - | | | | 12.1EC | contact TAC. | | | | | Available | | | | | upon request. | | | |-------------------+---------------+---------------+---------------| | | 12.1(20)EW2 - | | | | 12.1EW | Due on CCO | | | | | April 21, | | | | | 2004. | | | |-------------------+---------------+---------------+---------------| | Affected 12.2 | Rebuild | Interim | Maintenance | | -Based Release | | | | |-------------------+---------------+---------------+---------------| | | 12.2(12i) | | | | |---------------+---------------+---------------| | | 12.2(21b) | | | | |---------------+---------------+---------------| | 12.2 | | 12.2(23.6) - | 12.2(24) - | | | | available | Due on CCO | | | | upon request. | mid-May, | | | | | 2004. | | |---------------+---------------+---------------| | | 12.2(23a) | | | |-------------------+---------------+---------------+---------------| | | 12.2(20)S2 | | | | 12.2S |---------------+---------------+---------------| | | 12.2(22)S | | | |-------------------+---------------+---------------+---------------| | Affected 12.3 | Rebuild | Interim | Maintenance | | -Based Release | | | | |-------------------+---------------+---------------+---------------| | | 12.3(5c) | | | | |---------------+---------------+---------------| | | 12.3(6a) | | | | 12.3 |---------------+---------------+---------------| | | | 12.3(7.7) - | 12.3(9) - Due | | | | available | on CCO | | | | upon request. | mid-May, | | | | | 2004. | |-------------------+---------------+---------------+---------------| | | 12.3(5)B1 - | | | | 12.3B | Due on CCO | | | | | mid-June | | | | | 2004. | | | |-------------------+---------------+---------------+---------------| | | 12.3(4)T4 | | | | 12.3T |---------------+---------------+---------------| | | 12.3(7)T | | | |-------------------+---------------+---------------+---------------| | | 12.3(2)XC3 - | | | | 12.3XC | contact TAC | | | | | Available | | | | | upon request. | | | |-------------------+---------------+---------------+---------------| | 12.3XD | 12.3(4)XD2 | | | |-------------------+---------------+---------------+---------------| | 12.3XH | 12.3(4)XH | | | |-------------------+---------------+---------------+---------------| | 12.3XK | 12.3(4)XK | | | |-------------------+---------------+---------------+---------------| | 12.3XQ | 12.3(4)XQ | | | +-------------------------------------------------------------------+ Obtaining Fixed Software ======================== Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com/. Customers whose Cisco products are provided or maintained through prior or existing agreement with third-party support organizations such as Cisco Partners, authorized resellers, or service providers should contact that support organization for assistance with the upgrade, which is free of charge. Customers who purchase direct from Cisco but who do not hold a Cisco service contract and customers who purchase through third-party vendors but are unsuccessful at obtaining fixed software through their point of sale should get their free of charge upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac(a)cisco.com Please have your product serial number available and give the URL of this notice as evidence of your entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Please do not contact either "psirt(a)cisco.com" or "security-alert(a)cisco.com" for software upgrades. Workarounds =========== The effectiveness of any workarounds is dependent on specific customer situations such as product mix, network topology, traffic behavior and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround is the most appropriate for use in the intended network before it is deployed. The following workarounds should only be considered as a long term solution if anti-spoofing methods consistently prevent spoofed source attacks from entering the network and access-lists provided below are configured on every potentially affected device. * It is possible to disable SNMP processing on the device running IOS by issuing the following command: no snmp-server Removing the public community string with the configure command 'no snmp-server community <string> ro' is not sufficient as the SNMP server will still be running and the device will be vulnerable. The command no snmp-server must be used instead. Verify SNMP server status by using the enable command show snmp. You should see a response of "%SNMP agent not enabled". * Access Control Lists (ACLs) can be used to deny traffic tot he affected ports. As there can be no guarantee that the random high port will fall in the range of 49152 to 59152 (possibly as high as 65535), the example access-lists below show how to block all UDP ports in the range 49152 to 65535. Care should be taken to understand the potential side effects noted later in this section. Although Cisco IOS devices have community-string access lists which check the source address of SNMP requests per community string, they will not be sufficient to mitigate this vulnerability due to the SNMPv3 exploitation vector. On platforms that do not have the option to use rACLs, it is possible to permit UDP traffic to the router from trusted IP addresses with interface ACLs. Note: Because SNMP is based on UDP, it is possible to spoof the sender's IP address, which may defeat ACLs that permit communication to these ports from trusted IP addresses. The following extended access-list can be adapted to your network. This example assumes that the router has IP addresses 192.168.10.1 and 172.16.1.1 configured on its interfaces, that all SNMP access is to be restricted to a management station with the IP address of 10.1.1.1, and that the management station need only communicate with IP address 192.168.10.1: access-list 101 permit udp host 10.1.1.1 host 192.168.10.1 range 161 162 access-list 101 permit udp host 10.1.1.1 host 192.168.10.1 range 49152 65535 access-list 101 deny udp any host 192.168.10.1 range 161 162 access-list 101 deny udp any host 192.168.10.1 range 49152 65535 access-list 101 deny udp any host 172.16.1.1 range 161 162 access-list 101 deny udp any host 172.16.1.1 range 49152 65535 access-list 101 permit ip any any The access-list must then be applied to all interfaces using the following configuration commands: interface ethernet 0/0 ip access-group 101 in Note that UDP traffic in the ranges specified above must be explicitly blocked to each IP address on the router to prevent the router from accepting and processing the SNMP packets. Additionally, while blocking traffic to port 161 from unknown hosts is a best practice, in this case, port 161 is not affected and need not be blocked to prevent exploitation. All devices that communicate directly with the router on those UDP ports will need to be specifically listed in the above access list. Cisco IOS uses ports in the range 49152 to 65535 as the source port for outbound sessions such as DNS queries. For devices that have many IP addresses configured, or many hosts that need to communicate with the router, this may not be a scalable solution. IMPORTANT NOTE: Cisco IOS uses the same source port range when upgrading via TFTP. If your upgrade process includes downloading from a TFTP server, be sure to permit UDP traffic in the range 49152 to 65535 between the router and the TFTP server. Alternative download methods that do not rely on UDP, such as FTP, may also be used. Besides TFTP, other potentially affected services include Network Time Protocol (NTP), Remote Authentication Dial In User Service (RADIUS) and Domain Name Service (DNS). To minimize the impact of this workaround, you may want to explicitly permit access between your IOS device and the servers providing the service(s). It is critically important that you understand the impact to your network before deploying the above workaround. * Blocking Individual Ports The high port number chosen by the IOS device can be determined by using the command show ip sockets. UDP traffic to that individual port can be blocked, rather than the entire port range. This approach is not ideal because the high port is chosen at random when the router is rebooted or the SNMP service is stopped and restarted. This may, however, be a short term solution for customers that want to protect themselves from the vulnerability as they prepare to upgrade, for example. Output of the show ip sockets command: Router#sh ip sockets Proto Remote Port Local Port In Out Stat TTY OutputIF [snip] 17 --listen-- 192.168.10.72 161 0 0 1 0 17 --listen-- 192.168.10.72 162 0 0 11 0 17 --listen-- 192.168.10.72 49212 0 0 11 0 The above example shows that there are 3 SNMP-related ports listening, and the high port is bound to 49212. Rather than blocking the entire port range from 49152 to 65535, port 49212 can be blocked (in addition to port 162) as a temporary workaround. * Receive ACLs (rACL) For distributed platforms, rACLs may be an option starting in Cisco IOS Software Versions 12.0(21)S2 for the 12000 series GSR and 12.0 (24)S for the 7500 series. The receive access lists protect the device from harmful traffic before the traffic can impact the route processor. Receive path ACLs are considered a network security best practice, and should be considered as a long-term addition to good network security, as well as a workaround for this specific vulnerability. The CPU load is distributed to the line card processors and helps mitigate load on the main route processor. The white paper entitled "GSR: Receive Access Control Lists" will help identify and allow legitimate traffic to your device and deny all unwanted packets: http://www.cisco.com/warp/public/707/racl.html * Infrastructure ACLs (iACL) Although it is often difficult to block traffic transiting your network, it is possible to identify traffic which should never be allowed to target your infrastructure devices and block that traffic at the border of your network. Infrastructure ACLs are considered a network security best practice and should be considered as a long-term addition to good network security as well as a workaround for this specific vulnerability. The white paper entitled "Protecting Your Core: Infrastructure Protection Access Control Lists" presents guidelines and recommended deployment techniques for iACLs: http://www.cisco.com/warp/public/707/iacl.html Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory. Status of This Notice: INTERIM ============================== This is a INTERIM advisory. Although Cisco cannot guarantee the accuracy of all statements in this advisory, all of the facts have been checked to the best of our ability. Cisco may issue updated versions of this advisory A stand-alone copy or paraphrase of the text of this security advisory that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory will be posted on Cisco's worldwide website at http://www.cisco.com/warp/public/707/cisco-sa-20040420-snmp.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce(a)cisco.com * bugtraq(a)securityfocus.com * first-teams(a)first.org (includes CERT/CC) * cisco(a)spot.colorado.edu * cisco-nsp(a)puck.nether.net * full-disclosure(a)lists.netsys.com * vulnwatch(a)vulnwatch.org * comp.dcom.sys.cisco * Various other mailing lists Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +----------------------------------------+ | Revision | | Initial | | 1.0 | 2004-April-20 | Public | | | | Release. | +----------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/warp/public/707/sec_incident_response.shtml. This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.3 (SunOS) iD8DBQFAhZdvezGozzK2tZARAoj8AJsGfguxTnZ7P1KbzBdvVdtIizBYvQCeOOE2 jCByoWAz5y72MveH0NMXwXs= =Nfq3 -----END PGP SIGNATURE-----

1 0

Re: TCP vulnerability
by Aviva Garrett 20 Apr '04

20 Apr '04

In message <1386.64.235.224.55.1082482608.squirrel(a)mail.mzima.net>you write: > > Since no one's mentioned it yet, apparently there was a change in plans. > It was just released a day early. This is because of the story at http://www.washingtonpost.com/, in the Technology section. Thanks, ..Aviva > > http://story.news.yahoo.com/news?tmpl=story&cid=528&e=1&u=/ap/20040420/ap_o… > hi_te/internet_threat > > And the official one: > > http://www.uniras.gov.uk/vuls/2004/236929/index.htm > > Grant > > -- > Grant A. Kirkwood - grant(at)tnarg.org > Fingerprint = D337 48C4 4D00 232D 3444 1D5D 27F6 055A BF0C 4AED

5 5

RE: Winstar says there is no TCP/BGP vulnerability
by McBurnett, Jim 20 Apr '04

20 Apr '04

Well, CERT thought it was Jim -----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-----

1 0

RE: Backbone IP network Economics - peering and transit
by Gary Hale 20 Apr '04

20 Apr '04

I disagree ... but sure do appreciate your tone ... :) Regards, Gary -----Original Message----- From: Daniel Golding [mailto:dgolding@burtongroup.com] Sent: Tuesday, April 20, 2004 4:32 PM To: Gary Hale; Michel Py; Gordon Cook; nanog(a)merit.edu Subject: Re: Backbone IP network Economics - peering and transit Cynical? Gee, I hope so. Anyone who reads that sort of fluff needs to be cynical. Lack of appropriate cynicism led, in part, to the "recent unpleasantness" in the telecommunications industry. Words like "enabling", "leveraging", "mindshare", "b2b", "e-*", "i-*", et al, are considered harmful to fruitful operational discussion :) -- Daniel Golding Network and Telecommunications Strategies Burton Group On 4/20/04 2:17 PM, "Gary Hale" <ghale(a)globalinternetworking.com> wrote: > Daniel, > > That is way too cynical ... and does not address the question of whether > building your own transport ever runs counter to the Internet as a > consortium. > > There are business justifications that underpin peering relationships > ... and they are based on understanding (or ... "philosophy") .... > > Gary > > -----Original Message----- > From: Daniel Golding [mailto:dgolding@burtongroup.com] > Sent: Tuesday, April 20, 2004 10:36 AM > To: Gary Hale; Michel Py; Gordon Cook; nanog(a)merit.edu > Subject: Re: Backbone IP network Economics - peering and transit > > On 4/20/04 8:45 AM, "Gary Hale" <ghale(a)globalinternetworking.com> wrote: > >> >> The question is too simplistic ... It is not (simply) a matter of > small >> vs. big or being on your own network from source-to-destination. > Peering >> is an enabler ... and gives all an opportunity to share content > globally >> ... kinda' fundamental to the Internet consortium. >> >> Is your question, 'Since fiber is so cheap, why doesn't everyone build >> an autonomous, facilities-based, global "Internet" network that > competes >> for narrowband/broadband "pullers" of data and hosting/data > centers/etc. >> for content providers ("pulled-fromers" or "pushers" of data)? >> >> Gary >> >> -----Original Message----- >> From: Michel Py [mailto:michel@arneill-py.sacramento.ca.us] >> Sent: Monday, April 19, 2004 10:46 PM >> To: Gordon Cook; nanog(a)merit.edu >> Subject: RE: Backbone IP network Economics - peering and transit >> >> >>> Peering? Who needs peering if transit can be >>> had for $20 per megabit per second? >> >> The smaller guys that don't buy transit buy the gigabit. >> >> Michel. >> >> >> > Gary, > > "Peering is an enabler" > "gives all an opportunity to share content globally" > "fundamental to the Internet consortium" > > This is like the "greatest hits" compendium collected from various > failed > 1990's service provider business plans :) > > People should be careful. Peering is a business/networking arrangement > that > can save them money (or not). Those who try to imbue it with > philosophical > significance must be viewed with skepticism. > > > Daniel Golding > Network and Telecommunications Strategies > Burton Group > > > >

1 0

tcp bgp vulnerability looking glass and route server issues.
by Smith, Donald 20 Apr '04

20 Apr '04

John Fraizer author of MRLG one of the looking glass implementations has updated his code to fix a flaw that provided too much information. MRLG-4.3.0 is available at: Available here: ftp://ftp.enterzone.net/looking-glass/CURRENT/ Some route servers also provide too much info. This audit was performed yesterday so if you have already fixed this issue please ignore:-) Part of this issue is the fact that some router servers provide too much information. Without knowing the source/destination ports and IP's this is still a difficult vulnerability to exploit. >From this URL I did a quick audit. http://www.traceroute.org/#Route%20Servers I did NOT look at the looking glass URLs just the route servers. This is the list of open route servers I did a quick audit on. No connection means I was unable to connect to it. Not misconfigured meant sho ip bgp nei did NOT work. Sho ip bgp nei gives full ports/ips means what you think it means. You have may want to see if any of them are yours of if you peer / are the upstream for any of them. "Route Servers" "telnet://ner-routes.bbnplanet.net" BBN Planet NER route monitor No connection "telnet://route-server.belwue.de" BelWue (AS553) Sho ip bgp nei gives full ports/ips. "telnet://route-views.on.bb.telus.com">Telus - East Coast (AS852) Sho ip bgp nei gives full ports/ips. telnet://route-views.ab.bb.telus.com" Telus - West Coast (AS852) Sho ip bgp nei gives full ports/ips. "telnet://route-server.cerf.net">CerfNet Route Server (AS1838)</A></LI> Sho ip bgp nei gives full ports/ips. "telnet://route-server.ip.tiscali.net">Tiscali (AS3257)</A></LI> Sho ip bgp nei gives full ports/ips. "telnet://route-server.gblx.net">Global Crossing (AS3549)</A></LI> Not misconfigured:-) "telnet://route-server.savvis.net/">SAVVIS Communications (AS3561)</A></LI> Sho ip bgp nei gives full ports/ips. "telnet://public-route-server.is.co.za" TARGET=NEW>Internet Solutions (AS3741)</A></LI> Sho ip bgp nei gives full ports/ips. "telnet://route-server-ap.exodus.net">Exodus Communications Asia (AS4197)</A></LI> No connection "telnet://route-server.as5388.net">Planet Online (AS5388)</A></LI> Sho ip bgp nei gives full ports/ips. "telnet://route-server.opentransit.net">Opentransit (AS5511)</A></LI> Not misconfigured:-) "telnet://tpr-route-server.saix.net">South African Internet eXchange SAIX (AS5713)</A></LI> Not misconfigure:-) "telnet://route-server.gt.ca">GT Group Telecom (AS6539)</A></LI> Sho ip bgp nei gives full ports/ips. "telnet://route-server.as6667.net">EUNet Finland (AS6667)</A></LI> Sho ip bgp nei gives full ports/ips. "telnet://route-server.he.net">Hurricane Electric (AS6939)</A></LI> Sho ip bgp nei gives full ports/ips. "telnet://route-server.ip.att.net">AT&T (AS7018)</A></LI> No connection "telnet://route-views.optus.net.au">Optus Route Server Australia (AS7474)</A></LI> Sho ip bgp nei gives full ports/ips. "telnet://route-server.wcg.net">Wiltel (AS7911)</A></LI> Sho ip bgp nei gives full ports/ips. "telnet://route-server.colt.net">Colt Internet (AS8220)</A></LI> Sho ip bgp nei gives full ports/ips. "telnet://route-server-eu.exodus.net">Exodus Communications Europe (AS8709)</A></LI> No connection "telnet://route-views.bmcag.net">Broadnet mediascape communications AG (AS9132)</A></LI> Not misconfigured:-) "telnet://route-server-au.exodus.net">Exodus Communications Australia (AS9328)</A></LI> No connection "telnet://route-server.manilaix.net.ph">Manila Internet Exchange, Philippines (AS9670)</A></LI> Sho ip bgp nei gives full ports/ips. "telnet://route-server.east.attcanada.com">ATT Canada - East (AS15290)</A></LI> Sho ip bgp nei gives full ports/ips. "telnet://route-server.west.attcanada.com">ATT Canada - West (AS15290)</A></LI> Sho ip bgp nei gives full ports/ips. "telnet://route-server.ip.ndsoftware.net">NDSoftware (AS25358)</A></LI> Sho ip bgp nei gives full ports/ips. "telnet://route-server.loudpacket.net">Loud Packet (AS27276)</A></LI> No connection. "telnet://route-server.as28747.net/">RealROOT (AS28747)</A></LI> No connection "telnet://route-views.oregon-ix.net">Oregon-ix.net Route Server</A></LI> Sho ip bgp nei appears it WOULD provide full ports/ips if they had any? The command executed but came back empty!!?? This one can be used as a proxy bounce (connect ip port) too:-( "telnet://route-server.utah.rep.net">Utah Regional Exchange Point Route Server</A></LI> Sho ip bgp nei gives full ports/ips. "telnet://www.netlantis.org">The NetLantis Project Route Server</A></LI> Not misconfigured. http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xAF00EDCC pgpFingerPrint:9CE4 227B B9B3 601F B500 D076 43F1 0767 AF00 EDCC Increased trust is received by not violating the trust you have received.

1 0

RE: Backbone IP network Economics - peering and transit
by Gary Hale 20 Apr '04

20 Apr '04

Daniel, That is way too cynical ... and does not address the question of whether building your own transport ever runs counter to the Internet as a consortium. There are business justifications that underpin peering relationships ... and they are based on understanding (or ... "philosophy") .... Gary -----Original Message----- From: Daniel Golding [mailto:dgolding@burtongroup.com] Sent: Tuesday, April 20, 2004 10:36 AM To: Gary Hale; Michel Py; Gordon Cook; nanog(a)merit.edu Subject: Re: Backbone IP network Economics - peering and transit On 4/20/04 8:45 AM, "Gary Hale" <ghale(a)globalinternetworking.com> wrote: > > The question is too simplistic ... It is not (simply) a matter of small > vs. big or being on your own network from source-to-destination. Peering > is an enabler ... and gives all an opportunity to share content globally > ... kinda' fundamental to the Internet consortium. > > Is your question, 'Since fiber is so cheap, why doesn't everyone build > an autonomous, facilities-based, global "Internet" network that competes > for narrowband/broadband "pullers" of data and hosting/data centers/etc. > for content providers ("pulled-fromers" or "pushers" of data)? > > Gary > > -----Original Message----- > From: Michel Py [mailto:michel@arneill-py.sacramento.ca.us] > Sent: Monday, April 19, 2004 10:46 PM > To: Gordon Cook; nanog(a)merit.edu > Subject: RE: Backbone IP network Economics - peering and transit > > >> Peering? Who needs peering if transit can be >> had for $20 per megabit per second? > > The smaller guys that don't buy transit buy the gigabit. > > Michel. > > > Gary, "Peering is an enabler" "gives all an opportunity to share content globally" "fundamental to the Internet consortium" This is like the "greatest hits" compendium collected from various failed 1990's service provider business plans :) People should be careful. Peering is a business/networking arrangement that can save them money (or not). Those who try to imbue it with philosophical significance must be viewed with skepticism. Daniel Golding Network and Telecommunications Strategies Burton Group

2 1

re: TCP vulnerability
by Allison Mankin 20 Apr '04

20 Apr '04

Hi, For those not helped too much the MD5 Signature Option, this i-d addresses the attacks in the Watson paper (it was meant to come out just when the advisory came out, but they jumped the gun). There are implementations in *xes and router OSes - more info from those sources. Allison -------- Forwarded Message A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TCP Maintenance and Minor Extensions Working Group of the IETF. Title : Transmission Control Protocol security considerations Author(s) : R. Stewart Filename : draft-ietf-tcpm-tcpsecure-00.txt Pages : 10 Date : 2004-4-20 TCP (RFC793 [1]) is widely deployed and one of the most often used reliable end to end protocols for data communication. Yet when it was defined over 20 years ago the internet, as we know it, was a different place lacking many of the threats that are now common. Recently several rather serious threats have been detailed that can pose new methods for both denial of service and possibly data injection by blind attackers. This document details those threats and also proposes some small changes to the way TCP handles inbound segments that either eliminate the threats or at least minimize them to a more acceptable level. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcpsecure-00.txt - --4737358894.1082487684/segue.merit.edu-- ------- End of Forwarded Message

1 0