January 2011 - Test - lists.nanog.org

Cisco Security Advisory: Cisco Content Services Gateway Vulnerabilities
by Cisco Systems Product Security Incident Response Team 26 Jan '11

26 Jan '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Cisco Security Advisory: Cisco Content Services Gateway Vulnerabilities Advisory ID: cisco-sa-20110126-csg2 http://www.cisco.com/warp/public/707/cisco-sa-20110126-csg2.shtml Revision 1.0 For Public Release 2011 January 26 1600 UTC (GMT) +--------------------------------------------------------------------- Summary ======= A service policy bypass vulnerability exists in the Cisco Content Services Gateway - Second Generation (CSG2), which runs on the Cisco Service and Application Module for IP (SAMI). Under certain configurations this vulnerability could allow: * Customers to access sites that would normally match a billing policy to be accessed without being charged to the end customer * Customers to access sites that would normally be denied based on configured restriction policies Additionally, Cisco IOS Software Release 12.4(24)MD1 on the Cisco CSG2 contains two vulnerabilities that can be exploited by a remote, unauthenticated attacker to create a denial of service condition that prevents traffic from passing through the CSG2. These vulnerabilities require only a single content service to be active on the Cisco CSG2 and can be exploited via crafted TCP packets. A three-way handshake is not required to exploit either of these vulnerabilities. Workarounds that mitigate these vulnerabilities are not available. This advisory is posted at http://www.cisco.com/warp/public/707/cisco-sa-20110126-csg2.shtml. Affected Products ================= The service policy bypass vulnerability affects all versions of the Cisco IOS Software for the CSG2 prior to the first fixed release, as indicated in the "Software Versions and Fixes" section of this advisory. The two denial of service vulnerabilities only affect Cisco IOS Software Release 12.4(24)MD1 on the Cisco CSG2. No other Cisco IOS Software releases are affected. Vulnerable Products +------------------ To determine the version of Cisco IOS Software that is running on the Cisco CSG2, issue the "show module" command from Cisco IOS Software on the switch on which the Cisco CSG2 module is installed to identify what modules and sub-modules are installed on the system. Cisco CSG2 runs on the Cisco Service and Application Module for IP (SAMI) card, and is identified in the following example in slot 2 via the WS-SVC-SAMI-BB-K9 identification: C7600#show module Mod Ports Card Type Model Serial No. --- ----- -------------------------------------- ------------------ ----------- 1 2 Supervisor Engine 720 (Active) WS-SUP720-3BXL JAF1226ARQS 2 1 SAMI Module (csgk9) WS-SVC-SAMI-BB-K9 SAD113906P1 4 48 CEF720 48 port 10/100/1000mb Ethernet WS-X6748-GE-TX SAL1127T6XY Mod MAC addresses Hw Fw Sw Status --- ---------------------------------- ------ ------------ ------------ ------- 1 001e.be6e.a018 to 001e.be6e.a01b 5.6 8.5(2) 12.2(33)SRC5 Ok 2 001d.45f8.f3dc to 001d.45f8.f3e3 2.1 8.7(0.22)FW1 12.4(2010040 Ok 4 001c.587a.ef20 to 001c.587a.ef4f 2.6 12.2(14r)S5 12.2(33)SRC5 Ok Mod Sub-Module Model Serial Hw Status ---- --------------------------- ------------------ ----------- ------- ------- 1 Policy Feature Card 3 WS-F6K-PFC3BXL JAF1226BNQM 1.8 Ok 1 MSFC3 Daughterboard WS-SUP720 JAF1226BNMC 3.1 Ok 2 SAMI Daughterboard 1 SAMI-DC-BB SAD114400L9 1.1 Other 2 SAMI Daughterboard 2 SAMI-DC-BB SAD114207FU 1.1 Other 4 Centralized Forwarding Card WS-F6700-CFC SAL1029VGFK 2.0 Ok Mod Online Diag Status ---- ------------------- 1 Pass 2 Pass 4 Pass C7600# After locating the correct slot, issue the "session slot <module number> processor <3-9>" command to open a console connection to the respective Cisco CSG2. Once connected to the Cisco CSG2, perform the "show version" command: The following example shows that the Cisco CSG2 is running software Release 12.4(24)MD1: CSG2#show version Cisco IOS Software, SAMI Software (SAMI-CSGK9-M), Version 12.4(24)MD1, RELEASE SOFTWARE (fc2) Technical Support: http://www.cisco.com/techsupport Copyright (c) 1986-2010 by Cisco Systems, Inc. Compiled Wed 07-Apr-10 09:50 by prod_rel_team --- output truncated --- Products Confirmed Not Vulnerable +-------------------------------- The Cisco Content Services Gateway - 1st Generation (CSG) is not affected by these vulnerabilities. No other Cisco products are currently known to be affected by these vulnerabilities. Details ======= The Cisco Content Services Gateway - Second Generation (CSG2) provides intelligent network capabilities such as flexible policy management and billing based on deep-packet inspection, as well as subscriber and application awareness capabilities that enable mobile operators to quickly and easily offer value-added, differentiated services over their mobile data networks. The service policy bypass vulnerability affects configurations that allow end users to first access non-accounted or billed sites. After a user accesses a non-accounted site, it is possible to access other sites that are defined by a billing service policy or to access sites that may be blocked by other policies by sending specially crafted HTTP packets. This vulnerability only affects HTTP content traffic. HTTPS and other traffic types are not affected. Both denial of service vulnerabilities require only a single content service to be active on the Cisco CSG2 and can be exploited via crafted TCP packets. A three-way handshake is not required to exploit either of these vulnerabilities. The vulnerabilities are triggered by TCP traffic that transits the Cisco CSG2. The service policy bypass vulnerability is documented in Cisco Bug ID CSCtk35917 and has been assigned CVE ID CVE-2011-0348. The denial of service bugs are documented in Cisco Bug ID CSCth17178 and Cisco Bug ID CSCth41891 and have been assigned CVE IDs CVE-2011-0349 and CVE-2011-0350 respectively. Vulnerability Scoring Details ============================= Cisco has provided scores for the vulnerabilities in this advisory based on the Common Vulnerability Scoring System (CVSS). The CVSS scoring in this Security Advisory is done in accordance with CVSS version 2.0. CVSS is a standards-based scoring method that conveys vulnerability severity and helps determine urgency and priority of response. Cisco has provided a base and temporal score. Customers can then compute environmental scores to assist in determining the impact of the vulnerability in individual networks. Cisco has provided an FAQ to answer additional questions regarding CVSS at: http://www.cisco.com/web/about/security/intelligence/cvss-qandas.html Cisco has also provided a CVSS calculator to help compute the environmental impact for individual networks at: http://intellishield.cisco.com/security/alertmanager/cvss * CSCtk35917 ("Service Policy Bypass Vulnerability") CVSS Base Score - 6.4 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - Partial Integrity Impact - Partial Availability Impact - None CVSS Temporal Score - 5.3 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed * CSCth41891/CSCth17178 ("Crafted TCP packet causes CSG2 to restart") CVSS Base Score - 7.8 Access Vector - Network Access Complexity - Low Authentication - None Confidentiality Impact - None Integrity Impact - None Availability Impact - Complete CVSS Temporal Score - 6.4 Exploitability - Functional Remediation Level - Official-Fix Report Confidence - Confirmed Impact ====== Successful exploitation of the service policy bypass can allow customers to obtain access to sites that would normally be accounted and billed according to the billing policy without the billing policy being engaged. Additionally, customers could gain access to URLs that are configured in the Cisco CSG2 to be explicitly denied. Successful exploitation of either denial of service vulnerability could result in the Cisco CSG2 reloading or potentially hanging. Due to Cisco Bug ID CSCtg50821, the Cisco CSG2 may not automatically recover and may require a manual reload of the SAMI card by issuing the "hw-module module <x> reset" CLI command from the switch. Software Versions and Fixes =========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center (TAC) or your contracted maintenance provider for assistance. Each row of the Cisco IOS Software table (below) names a Cisco IOS release train. If a release train is vulnerable, then the earliest possible releases that contain the fix (along with the anticipated date of availability for each, if applicable) are listed in the "First Fixed Release" column of the table. The "Recommended Release" column indicates the releases which have fixes for all the published vulnerabilities at the time of this Advisory. 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. Cisco recommends upgrading to a release equal to or later than the release in the "Recommended Releases" column of the table. +---------------------------------------------------------------+ | Major | Availability of Repaired Releases | | Release | | |------------+--------------------------------------------------| | Affected | | | 12.x-Based | First Fixed Release | | Releases | | |------------+--------------------------------------------------| | 12.0 - | 12.0 through 12.3 based releases are not | | 12.3 | affected | |------------+--------------------------------------------------| | Affected | First Fixed Release | | 12.4-Based |--------------------------------------------------| | Releases | DoS | Service Policy Bypass | | | Vulnerabilities | Vulnerability | |------------+------------------+-------------------------------| | | All 12.4(11)MD | | | | releases are not | All 12.4(11)MD releases are | | | affected. | affected. Migrate to a fixed | | | | release. | | | All 12.4(15)MD | | | | releases are not | All 12.4(15)MD releases are | | | affected. | affected. Migrate to a fixed | | | | release. | | | All 12.4(22)MD | | | 12.4MD | releases are not | All 12.4(22)MD releases are | | | affected. | affected. Migrate to a fixed | | | | release. | | | Releases prior | | | | to 12.4(24)MD1 | All 12.4(24)MD releases prior | | | are not | to 12.4(24)MD3 are affected. | | | affected. | | | | | First fixed in 12.4(24)MD3 | | | First fixed in | | | | 12.4(24)MD2 | | |------------+------------------+-------------------------------| | | | All 12.4(22)MDA releases | | | | prior to 12.4(22)MDA5 are | | | | affected. First fixed in 12.4 | | | No releases | (22)MDA5 | | 12.4MDA | affected. | | | | | All 12.4(24)MDA releases | | | | prior to 12.4(24)MDA3 are | | | | affected. First fixed in 12.4 | | | | (24)MDA3 | |------------+--------------------------------------------------| | Affected | | | 15.X-Based | First Fixed Release | | Releases | | |------------+--------------------------------------------------| | 15.0 - | 15.0 through 15.1 based releases are not | | 15.1 | affected | +---------------------------------------------------------------+ Cisco IOS Software for the CSG2 is located on Cisco Software Download center at the following location: Cisco Interfaces and Modules --> Cisco Services Modules --> Cisco Service Application Module for IP. Workarounds =========== There are no workarounds for these vulnerabilities. Obtaining Fixed Software ======================== Cisco has released free software updates that address these vulnerabilities. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/en/US/docs/general/warranty/English/EU1KEN_.html, or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml. Do not contact psirt(a)cisco.com or security-alert(a)cisco.com for software upgrades. Customers with Service Contracts +------------------------------- 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 using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreements with third-party support organizations, such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix 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 or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but do not hold a Cisco service contract, and customers who purchase through third-party vendors but are unsuccessful in obtaining fixed software through their point of sale should acquire 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 Customers should have their product serial number available and be prepared to give the URL of this notice as evidence of entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/en/US/support/tsd_cisco_worldwide_contacts.html for additional TAC contact information, including localized telephone numbers, and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is aware of public announcements of the service billing bypass vulnerability on some external blog sites. However the Cisco PSIRT is not aware of any malicious use of the vulnerabilities described in this advisory. These vulnerabilities were found by both internal testing and when handling customer support calls. Status of this Notice: FINAL ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document 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 is posted on Cisco's worldwide website at: http://www.cisco.com/warp/public/707/cisco-sa-20110126-csg2.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 * first-bulletins(a)lists.first.org * bugtraq(a)securityfocus.com * vulnwatch(a)vulnwatch.org * cisco(a)spot.colorado.edu * cisco-nsp(a)puck.nether.net * full-disclosure(a)lists.grok.org.uk * comp.dcom.sys.cisco(a)newsgate.cisco.com 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 1.0 | 2011-January-26 | Initial 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/en/US/products/products_security_vulnerability_policy.…. This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt. +-------------------------------------------------------------------- Copyright 2010-2011 Cisco Systems, Inc. All rights reserved. +-------------------------------------------------------------------- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iF4EAREIAAYFAk1APx0ACgkQQXnnBKKRMNBE4QD/WfH2GXgAJub+4ech0JhHizBO 98PLNKENutVsJpa0eCUA/2hKwfofNSloEh7i5JZXrwKFcjgBYJcPnDa1W2JRHSfZ =EZt9 -----END PGP SIGNATURE-----

1 0

Network Naming
by Nick Olsen 26 Jan '11

26 Jan '11

Whats the rule of thumb for naming gear these days (routers,switches...etc). Or is there one? looks like level3 does something like interface.routertype.location.level3.net Nick Olsen Network Operations (855) FLSPEED x106

7 7

Understanding reverse DNS better
by Caleb Tennis 26 Jan '11

26 Jan '11

We have a /24 from one of our upstream providers that we handoff to a customer. The /24 has been SWIPd to us, and we have nameservers setup with ARIN against that record. Twice now this information has just "disappeared". That is, if do reverse DNS lookups, they returns nothing, whereas they were just working fine earlier. If you do an NS lookup on the block, it returns nothing. The /24 blocks immediately surrounding us continue to work just fine. If we do a lookup directly against our nameserver, it works just fine. It's like the nameserver information against that reverse DNS is just magically gone. The ARIN record looks good, nothing has changed. Last time, our upstream resubmitted the info so it would repopulate, and it started working again soon there after. I admit to not being the smartest one with how these records work: is the problem with the upstream, or ARIN's database, or is there not enough information to tell? Thanks, Caleb

7 8

Re: IPv6 filtering
by Hank Nussbacher 26 Jan '11

26 Jan '11

At 18:20 26/01/2011 +1300, Franck Martin wrote: >Content-Transfer-Encoding: 7bit > >Well we filter icmp due to exploits, if no exploits, then we can let the >whole of icmpv6 through. Or is there something terribly dangerous in >icmpv6 already? Ever since Cisco came out with "IPv6 Routing Header Vulnerability" in 2007 http://www.cisco.com/en/US/products/products_security_advisory09186a00807cb… I have had the following enabled: On the protected interface: ipv6 traffic-filter filter-rh in ipv6 access-list filter-rh deny ipv6 any any log routing permit ipv6 any any and have stopped many pkts that way. I still occasionally see hits in our log from all sorts of newbies who continue to try old bugs. -Hank

1 0

IPv6 - real vs theoretical problems
by Deepak Jain 25 Jan '11

25 Jan '11

Please, before you flame out, recognize I know a bit of what I am talking about. You can verify this by doing a search on NANOG archives. My point is to actually engage in an operational discussion on this and not insult (or be insulted). While I understand the theoretical advantages of /64s and /56s and /48s for all kinds of purposes, *TODAY* there are very few folks that are actually using any of them. No typical customer knows what do to do (for the most part) with their own /48, and other than autoconfiguration, there is no particular advantage to a /64 block for a single server -- yet. The left side of the prefix I think people and routers are reasonably comfortable with, it's the "host" side that presents the most challenge. My interest is principally in servers and high availability equipment (routers, etc) and other things that live in POPs and datacenters, so autoconfiguration doesn't even remotely appeal to me for anything. In a datacenter, many of these concerns about having routers fall over exist (high bandwidth links, high power equipment trying to do as many things as it can, etc). Wouldn't a number of problems go away if we just, for now, follow the IPv4 lessons/practices like allocating the number of addresses a customer needs --- say /122s or /120s that current router architectures know how to handle -- to these boxes/interfaces today, while just reserving /64 or /56 spaces for each of them for whenever the magic day comes along where they can be used safely? As far as I can tell, this "crippling" of the address space is completely reversible, it's a reasonable step forward and the only "operational" loss is you can't do all the address jumping and obfuscation people like to talk about... which I'm not sure is a loss. In your enterprise, behind your firewall, whatever, where you want autoconfig to work, and have some way of dealing with all of the dead space, more power to you. But operationally, is *anything* gained today by giving every host a /64 to screw around in that isn't accomplished by a /120 or so? Thanks, DJ

20 37

Re: Network Naming
by GP Wooden 25 Jan '11

25 Jan '11

Punk bands here .... ----- Reply message ----- From: "Christopher" <caldcv(a)gmail.com> Date: Tue, Jan 25, 2011 3:11 pm Subject: Network Naming To: <nanog(a)nanog.org> I usually name them after ex-girlfriends On 01/25/2011 03:50 PM, Nick Olsen wrote: > Whats the rule of thumb for naming gear these days > (routers,switches...etc). Or is there one? > > looks like level3 does something like > interface.routertype.location.level3.net > > Nick Olsen > Network Operations > (855) FLSPEED x106 > > >

1 0

Update Spamhaus DROP list from Cisco CLI (TCL)
by Thomas Magill 25 Jan '11

25 Jan '11

Previous conversations made me decide this would be fun to do so I ignored all my real work today and made it happen. I built a TCL script that can be mapped to an alias ("alias exec updatedrop tclsh updatedrop.tcl") that will connect to the Spamhaus DROP list and route all of the prefixes to null0. It should alsbo be able to be mapped to a kron job, but I haven't tested that and I've heard there are issues with kron+tcl unless you tie it to an EEM event. It adds a name indicator (Spamhaus_SBLXXXXX) to all of the routes to show that they come from the DROP list. You can find the script at: http://tmagill.net/cisco_networking_ccie_studies/?p=83 There is also a script to remove all of the Spamhaus_SBLXXXXX null routes. If I were to redis these into BGP they could be propagated just like the CYMRU Bogons... I plan on doing that within the next week and start testing. Does anyone see that as a useful service to be offered? Thomas Magill Network Engineer Office: (858) 909-3777 Cell: (858) 869-9685 tmagill(a)providecommerce.com<mailto:tmagill@providecommerce.com> provide-commerce 4840 Eastgate Mall San Diego, CA 92121 ProFlowers<http://www.proflowers.com/> | redENVELOPE<http://www.redenvelope.com/> | Cherry Moon Farms<http://www.cherrymoonfarms.com/> | Shari's Berries<http://www.berries.com/>

5 5

Re: IPv6: numbering of point-to-point-links
by Lasse Jarlskov 25 Jan '11

25 Jan '11

Thank you all for your comments - it appears that there is no consensus on how this should be done. Thank you for the reference to this draft, Marco - and to Ron as well. Both RFC3627 and this draft appears to be stating that these issues a implementation-specific. E.g. whether an implementation will perform subnet-router-anycast on a small subnet, whether Neighbor-Discovery-messages are rate-limited etc. Does anyone have any information on how different vendors handle this - even in older software? /126 appears to be the middle path - which is reserving the subnet-router-anycast address while keeping the subnet as small as possible. This appears to address both issues - at least for Ethernet links. (one free address will hardly constitute a potential Neighbor Cache Exhaustion issue). Best regards, /Lasse -----Oprindelig meddelelse----- Fra: Marco Hogewoning [mailto:mch-nanog@xs4all.nl] Sendt: 24. januar 2011 14:11 Til: Lasse Jarlskov Cc: nanog(a)nanog.org Emne: Re: IPv6: numbering of point-to-point-links > While reading up on IPv6, I've seen numerous places that subnets are now > all /64. > > I have even read that subnets defined as /127 are considered harmful. RFC3627, with a lot of discussion in the IETF on this. See also https://datatracker.ietf.org/doc/draft-ietf-6man-prefixlen-p2p/ > However while implementing IPv6 in our network, I've encountered several > of our peering partners using /127 or /126 for point-to-point links. I personally don't any benefit in using /126 subnets. > What is the Best Current Practice for this - if there is any? > > Would you recommend me to use /64, /126 or /127? > > What are the pros and cons? >From an operational point of view there is a risk that be using /64 somebody can eat away a lot of memory by either scanning or even changing addresses. This is also described in the draft above... I would personally recommend to at least always assign the /64, even if you would decide to configure the /127. RFC 3627 has been around long enough that you will keep running into equipment or software that won't like the /127. In which case you can always revert back to /64. This will also allow you to use easy to remember addresses like ::1 and ::2, saving you the headache of a lot of binary counting. Grtx, Marco

2 1

bestpath as-path multipath-relax
by Zaid Ali 24 Jan '11

24 Jan '11

I am looking for some operational feedback of this undocumented feature, bgp bestpath as-path multipath-relax, for IOS. If you are using this for outbound load balancing I would like to hear your experiences. Also if you are running it across edges. Thanks, Zaid

1 0

The Conficker Working Group Lessons Learned Document
by freed0 24 Jan '11

24 Jan '11

http://www.confickerworkinggroup.org/wiki/pmwiki.php/ANY/LessonsLearned http://www.confickerworkinggroup.org/wiki/uploads/Conficker_Working_Group_L… The Conficker Working Group Lessons Learned Document Starting in late 2008, and continuing through June of 2010, a coalition of security researchers worked to resist an Internet borne attack carried out by malicious software known as Conficker. This coalition became known as “The Conficker Working Group”, and seemed to be successful in a number of ways, not the least of which was unprecedented cooperation between organizations and individuals around the world, in both the public and private sectors. In 2009, The Department of Homeland Security funded a project to develop and produce a “Lessons Learned” document that could serve as a permanent record of the events surrounding the creation and operation of the working group so that it could be used as an exemplar upon which similar groups in the future could build. This is the document. The Rendon Group conducted the research independently, and although a number of members of the Conficker Working Group were interviewed, and provided information to the authors, the report is the sole work product of the Rendon Group. The views and conclusions are not necessarily those of the Conficker Working Group, or any of its official or unofficial members. Nonetheless the Core Committee of the Conficker Working Group believes the report has substantial value and is pleased to provide access to the Rendon document via the Conficker Working Group Website. Rodney Joffe Chair Conficker Working Group Follow up questions can be directed to the Rendon Group at the address below, as well as the following members of the Conficker Working Group Core Committee: * The Rendon Group * Phone: +1 202-745-4900 * trginfo(a)rendon.com Conficker Working Group Core Committee: The ShadowServer Foundation * Andre' M. DiMino * Co-Founder and Director * Phone: +1 914-410-6480 * Email: adimino(a)shadowserver.org Neustar, Inc * Rodney Joffe * Senior Vice President * Phone: +1 202-533-2900 * Email: rodney.joffe(a)neustar.biz Verisign, Inc. * Ramses Martinez * Director of Information Security * Phone: +1 571-723-1874 * Email: ramartinez(a)verisign.com Arbor Networks * Kevin Whalen * kwhalen(a)arbor.net * Phone: +1 978-852-8432 Internet Software Consortium * Barry Greene * President * Phone: +1 650-423-1311 * Email: bgreene(a)isc.org

1 0