No Hacking Exposed book is complete without mentioning some of the "famous" vulnerabilities or tools available to the hacking/security professionals community. This section provides a short description of the generic Cisco device DoS vulnerabilities that have been floating about on various security research sites and message boards . Later on, we will take a look at some of the vulnerabilities that are relevant to specific devices, such as routers and switches.
Even though some of the bugs that we mention here might be a bit old by the time this book hits the shelves , our research indicates that many Cisco appliances are left in the wilderness of the Internet without any protection and patching whatsoever. It was common for us to find that some client's Cisco devices had not been updated for five or more years , and that makes a lot of old vulnerabilities still available and exploitable. For example, IOS 11.x versions are still out there and running. After all, if it works, why break it?
These attacks are based on abusing the general design weaknesses of TCP/IP. Thus, they would work against many types of networked hosts , including some of the Cisco devices. While not being truly exciting, they do deserve their place in this chapter, if only by the frequency with which they occur in the real world.
This vulnerability affects operating systems, firewalls, routers, and other hardware appliances from a long list of vendors. The problem exists in implementation of Internet Control Message Protocol (ICMP) with respect to the error-handling mechanism. The majority of vendors (WatchGuard, Symantec, Sun, RedHat, Nortel, Microsoft, Cisco Systems, and many others) fail to implement an adequate security mechanism for checking ICMP error messages, thus making their systems prone to all sorts of DoS attacks. A malicious user can exploit this bug to terminate target TCP connections and deny service to legitimate users or degrade the performance of an established TCP connection by flooding with ICMP source quench messages. More information about this issue can be found at http://www.securityfocus.com by searching for Bug ID ( bid ) 13124 . A proof of concept code can be obtained from the same location to test whether your systems are vulnerable. The code compiled cleanly on our systems and has three different ICMP-based attacks against TCP:
arhontus # ./HOD-icmp-attacks-poc (MS05-019) (CISCO:20050412) ICMP attacks against TCP (Proof-of-Concept) Copyright (c) 2004-2005 .: houseofdabus :. Usage: ./HOD-icmp-attacks-poc <-fi:SRC-IP> <-ti:VICTIM-IP> >-fi:SRC-PORT> [-tp:int] [-a:int] [-n:int] -fi:IP From (sender) IP address -ti:IP To (target) IP address -fp:int Target open TCP port number (for example - 21, 25, 80) -tp:int Inicial value for bruteforce (sender) TCP port number (default: 0 = range of ports 0-65535) -n:int Number of packets -a:int ICMP attacks: 1 - Blind connection-reset attack (ICMP protocol unreachable) 2 - Path MTU discovery attack (slow down the transmission rate) 3 - ICMP Source Quench attack
The following Cisco devices are vulnerable to these attacks:
Cisco Content Services Switch 11000 series (WebNS)
Cisco Global Site Selector (GSS) 4480 1.x
Cisco IOS 10.x routers and switches
Cisco IOS 11.x routers and switches
Cisco IOS 12.x routers and switches
Cisco IOS R11.x routers and switches
Cisco IOS R12.x routers and switches
Cisco IOS XR (CRS-1) 3.x
Cisco ONS 15000 series
Cisco PIX 6.x
Cisco SAN-OS 1.x (MDS 9000 switches)
At the time of writing, most of the affected vendors have prepared advisories and updates that can be downloaded from their web sites. Cisco Systems has made a variety of OS upgrades available to resolve the issue. For full information on which particular systems need to be upgraded to avoid this DoS attack, consult the Cisco advisory at http://www.cisco.com/warp/public/707/cisco-sa-20050412-icmp.shtml . Temporary workarounds to protect against ICMP DoS attacks against TCP are also available. They include disabling path-mtu-discovery in IOS and using the maximum segment size instead to block the path-mtu-discovery attack:
affected_router(config)#no ip tcp path-mtu-discovery affected_router(config)#ip tcp mss <segmentsize>
Since the connection reset and source quench attacks depend on IP spoofing by crackers, the standard Cisco antispoofing defense will work:
affected_router(config)#ip cef affected_router(config-if)#ip verify unicast reverse-path
You can find more about Cisco antispoofing measures at http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080120f48.shtml#sec_ip .
A variety of Cisco products contain multiple vulnerabilities in handling SNMP requests and traps. It is possible for a remote cracker to create a DoS condition by sending a specially crafted malformed SNMP request to the SNMP service of a Cisco device or appliance. The targeted device will most likely restart or completely stop functioning until it is manually restarted. A proof of concept tool is available for download from http://www.packetstormsecurity.org/0206-exploits/ciscokill.c ; we have already reviewed this tool and the attack in Chapter 7.
Cisco has released an advisory for this bug that contains details regarding the fixes for firmware for IOS-based systems with versions 11.x and 12.x and non-IOS based Cisco products. Please see the advisory "Malformed SNMP Message-Handling Vulnerabilities for Cisco Non-IOS Products" at Cisco Systems' web site for details.
Such attacks are not that common but can crash a router with only a few packets, since a specific software design bug is exploited. In some cases, such attacks are basically " unfinished " buffer overflow exploits because the attacker did not have enough skill, knowledge, desire , or time to look further into the proper exploitation of the discovered flaw. What may happen if such deep investigation does take place is well- illustrated in the Case Study at the beginning of Part II. Here we will review two specific DoS attacks against reasonably recent IOS versions, but more of them existfor example, crashing old IOS 11.x systems with a CDP frames flood, as described by Phenoelit.
Another flaw leading to a DoS condition has been identified in the Cisco System devices running IOS. This time, it relates to Cisco 6500/7600 Catalysts, high-end switches with installed virtual private network (VPN) service modules, and other IOS-based devices with cryptographic support that processes Internet Key Exchange (IKE) messages that carry out a functionality of VPN devices. When these appliances process a malformed IKE packet, IOS triggers a crash and reload. Consistent exploitation of this flaw against a target will result in a DoS.
A Cisco advisory ( http://www.cisco.com/warp/public/707/cisco-sa-20040408-vpnsm.shtml ) has been released to counsel system administrators on this issue. If your Cisco equipment is being used for the VPN functionality, it is highly advisable that you upgrade your devices with the latest software, as there is a high possibility that an exploit code is circulating among underground groups and message boards.
A DoS condition has been identified in all Cisco IOS-based devices that are configured to process IPv4. This bug does not affect devices that run IPv6. The vulnerability can be exploited by sending a series of specially crafted packets directly at the device.
Successful exploitation of such a flaw causes the router to seize processing of further packets on all targeted interfaces. A reboot of the device is required to resume proper operations.
The proof of concept code is available to check vulnerability of your devices to this attack (or to cause havoc on the Internet). It can be obtained from the PacketStorm security web site by searching for cisco-bug-44020 .
Here is an example of this tool in action:
arhontus cisco-bug-44020 # ./cisco-bug-44020 192.168.66.100 192.168.66.202 1 1000 DEBUG: Hops: 1 DEBUG: Protocol: 55 DEBUG: Checksum: 47389 DEBUG: 45 10 00 14 55 6b 40 00 01 37 1d b9 c0 a8 42 64 c0 a8 42 ca DEBUG: Wrote 20 bytes. DEBUG: Protocol: 55 DEBUG: Checksum: 27731 DEBUG: 45 10 00 14 1f b8 40 00 01 37 53 6c c0 a8 42 64 c0 a8 42 ca DEBUG: Wrote 20 bytes. DEBUG: Protocol: 77 DEBUG: Checksum: 26184 DEBUG: 45 10 00 14 2a a8 40 00 01 4d 48 66 c0 a8 42 64 c0 a8 42 ca DEBUG: Wrote 20 bytes. DEBUG: Protocol: 77 DEBUG: Checksum: 1279 DEBUG: 45 10 00 14 74 09 40 00 01 4d ff 04 c0 a8 42 64 c0 a8 42 ca DEBUG: Wrote 20 bytes. # lines omitted to save trees in Siberia ;-)
You can check to see if the DoS worked (it actually did):
arhontus $ ping 192.168.66.202 PING (192.168.66.202) 56(84) bytes of data. --- 192.168.66.102 ping statistics --- 5 packets transmitted, 0 received, 100% packet loss, time 3998ms
A quick and temporary workaround would be to execute the following commands on the router:
# access-list 101 deny 53 any any # access-list 101 deny 55 any any # access-list 101 deny 77 any any
Note that in these access lists, 53, 55, and 77 are the numbers of IP protocols, not TCP or User Datagram Protocol (UDP) ports. When the workaround got released, many confused system administrators started to block TCP and UDP ports with the corresponding numbers instead and wondered why the name resolution ceased to work! To solve the problem permanently, Cisco System advises that you upgrade the IOS software to the latest version.