RE: Working vulnerability? (Cisco exploit)
It's released and it works - I have verified it in a lab here. BB -Original Message- From: Ken Yeo [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 3:24 PM To: [EMAIL PROTECTED] Subject: Working vulnerability? (Cisco exploit) Is this true: http://www.eweek.com/article2/0,3959,1196496,00.asp **there is a working exploit for this vulnerability but that it has not been released yet.**
Cisco exploit and Huawei
It would be interesting to know if Huawei routers also falls to the Cisco IOS exploit... Rubens
Cisco Vulnerability Testing Results
Hi all, First post.. I hope this is ok ... We tested the Cisco vulnerability and I wanted to share our results with you ... The attack code we used is the same code that was posted to the Full Disclosure list. Compiled on a Redhat Linux 6.2 machine. Testing scenario is this : Linux Machine (10.0.0.2/24) Cisco 2514 Ethernet0 (10.0.0.1/24) is in from the attacker Ethernet1 (192.168.0.1/24) is output to the 2501 Cisco 2501 Ethernet0 (192.168.0.2/24) is in from the 2514 First attack was to the 2514, ran the program as thus : ./sc 192.168.0.1 1 This produced unexpected results. Cisco indicated that the vulnerability was on the interface specified in the packets. However, after running this, it was actually the INPUT interface that the input queue increased on. In our test, this was Ethernet0, not Ethernet1 as expected. Next attach was to the 2501 : ./sc 192.168.0.2 2 This produced expected results. Input queue did increase on the 2501. Next we tried a pass-through attack : ./sc 192.168.0.2 0 ./sc 192.168.0.2 1 No interfaces on either Cisco were affected. It seems that pass-through attacks are not possible. The attack *must* terminate on an IP on one of the router interfaces. An additional test to both routers using a high TTL value was also run. No interfaces were affected. This is in-line with Cisco's posting. Code was then upgraded on the 2514 to 12.0.27 (non-vulnerable) .. Tests were run again. This time, the 2514 was not affected by any tests. The 2501 was still vulnerable. I will be testing ACL's in a moment, but I wanted to get these results out and see if they were on-par with any testing anyone else has done. -- --- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering [EMAIL PROTECTED] RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --- Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -- Albert Einstein [1879-1955] signature.asc Description: This is a digitally signed message part
SC Signature and HPING Signature
For those interested, these are the packet dumps of all 4 protocols
using HPing and the release ShadowChode exploit.
I'm told you can create the necessary IDS filters from this.. we're
working on this now as well... :) I'm not an IDS expert, so I don't
have the know-how to do this... yet.. :)
-Forwarded Message-
From: Keith Pachulski
Output below is from both the SC code and hping performing the same as
SC. Feel free to develop your signatures from it.
SC Exploit
11:59:59.014190 79.111.123.116 dhcp9-1.noc.corp.ptd.net: swipe 181
0x 4500 00c9 bf25 0235 fe3b 4f6f 7b74E%...5.;Oo{t
0x0010 ccba 6301 0001 0203 0405 0607 0809 0a0b..c.
0x0020 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b
0x0030 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b.!#$%'()*+
0x0040 2c2d 2e2f 3031 3233 3435 3637 3839 3a3b,-./0123456789:;
0x0050 3c3d 3e3f 4041 4243 4445 4647 4849 4a4b=[EMAIL PROTECTED]
0x0060 4c4d 4e4f 5051 5253 5455 5657 5859 5a5bLMNOPQRSTUVWXYZ[
0x0070 5c5d 5e5f 6061 6263 6465 6667 6869 6a6b\]^_`abcdefghijk
0x0080 6c6d 6e6f 7071 7273 7475 7677 7879 7a7blmnopqrstuvwxyz{
0x0090 7c7d 7e7f 8081 8283 8485 8687 8889 8a8b|}~.
0x00a0 8c8d 8e8f 9091 9293 9495 9697 9899 9a9b
0x00b0 9c9d 9e9f a0a1 a2a3 a4a5 a6a7 a8a9 aaab
0x00c0 acad aeaf b0b1 b2b3 b4 .
11:59:59.014402 dhcp9-1.noc.corp.ptd.net 79.111.123.116: icmp:
dhcp9-1.noc.corp.ptd.net protocol 53 unreachable [tos 0xc0]
0x 45c0 00e5 80f8 4001 fdc0 ccba 6301[EMAIL PROTECTED]
0x0010 4f6f 7b74 0302 df39 4500 00c9Oo{t...9E...
0x0020 bf25 0235 fe3b 4f6f 7b74 ccba 6301.%...5.;Oo{t..c.
0x0030 0001 0203 0405 0607 0809 0a0b 0c0d 0e0f
0x0040 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0050 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f.!#$%'()*+,-./
0x0060 3031 3233 3435 3637 3839 3a3b 3c3d 3e3f0123456789:;=?
0x0070 4041 4243 4445 4647 4849 4a4b 4c4d 4e4f@ABCDEFGHIJKLMNO
0x0080 5051 5253 5455 5657 5859 5a5b 5c5d 5e5fPQRSTUVWXYZ[\]^_
0x0090 6061 6263 6465 6667 6869 6a6b 6c6d 6e6f`abcdefghijklmno
0x00a0 7071 7273 7475 7677 7879 7a7b 7c7d 7e7fpqrstuvwxyz{|}~.
0x00b0 8081 8283 8485 8687 8889 8a8b 8c8d 8e8f
0x00c0 9091 9293 9495 9697 9899 9a9b 9c9d 9e9f
0x00d0 a0a1 a2a3 a4a5 a6a7 a8a9 aaab acad aeaf
0x00e0 b0b1 b2b3 b4 .
11:59:59.014380 36.71.143.53 dhcp9-1.noc.corp.ptd.net: mobile: []
(bad checksum 515)
0x 4500 00c9 fefc 0237 d5c9 2447 8f35E7..$G.5
0x0010 ccba 6301 0001 0203 0405 0607 0809 0a0b..c.
0x0020 0c0d 0e0f 1011 1213 1415 1617 1819 1a1b
0x0030 1c1d 1e1f 2021 2223 2425 2627 2829 2a2b.!#$%'()*+
0x0040 2c2d 2e2f 3031 3233 3435 3637 3839 3a3b,-./0123456789:;
0x0050 3c3d 3e3f 4041 4243 4445 4647 4849 4a4b=[EMAIL PROTECTED]
0x0060 4c4d 4e4f 5051 5253 5455 5657 5859 5a5bLMNOPQRSTUVWXYZ[
0x0070 5c5d 5e5f 6061 6263 6465 6667 6869 6a6b\]^_`abcdefghijk
0x0080 6c6d 6e6f 7071 7273 7475 7677 7879 7a7blmnopqrstuvwxyz{
0x0090 7c7d 7e7f 8081 8283 8485 8687 8889 8a8b|}~.
0x00a0 8c8d 8e8f 9091 9293 9495 9697 9899 9a9b
0x00b0 9c9d 9e9f a0a1 a2a3 a4a5 a6a7 a8a9 aaab
0x00c0 acad aeaf b0b1 b2b3 b4 .
11:59:59.014603 dhcp9-1.noc.corp.ptd.net 36.71.143.53: icmp:
dhcp9-1.noc.corp.ptd.net protocol 55 unreachable [tos 0xc0]
0x 45c0 00e5 5815 4001 3e0b ccba 6301[EMAIL PROTECTED]...c.
0x0010 2447 8f35 0302 df39 4500 00c9$G.5...9E...
0x0020 fefc 0237 d5c9 2447 8f35 ccba 6301.7..$G.5..c.
0x0030 0001 0203 0405 0607 0809 0a0b 0c0d 0e0f
0x0040 1011 1213 1415 1617 1819 1a1b 1c1d 1e1f
0x0050 2021 2223 2425 2627 2829 2a2b 2c2d 2e2f.!#$%'()*+,-./
0x0060 3031 3233 3435 3637 3839 3a3b 3c3d 3e3f0123456789:;=?
0x0070 4041 4243 4445 4647 4849 4a4b 4c4d 4e4f@ABCDEFGHIJKLMNO
0x0080 5051 5253 5455 5657 5859 5a5b 5c5d 5e5fPQRSTUVWXYZ[\]^_
0x0090 6061 6263 6465 6667 6869 6a6b 6c6d 6e6f`abcdefghijklmno
0x00a0 7071 7273 7475 7677 7879 7a7b 7c7d 7e7fpqrstuvwxyz{|}~.
0x00b0 8081 8283 8485 8687 8889 8a8b 8c8d 8e8f
0x00c0 9091 9293 9495 9697 9899 9a9b 9c9d 9e9f
0x00d0 a0a1 a2a3 a4a5 a6a7 a8a9 aaab acad aeaf
0x00e0 b0b1 b2b3 b4 .
11:59:59.014572 57.21.62.14 dhcp9-1.noc.corp.ptd.net: nd
AOL Mail Blocking
Anyone notice any issues that began today regarding AOL blocking mail servers? Gary Attard Director Network Operations Center Invision.com Inc. http://www.invision.net Phone: (631) 543-1000 x306 Fax: (631) 864-8896 E-Mail: [EMAIL PROTECTED]
RE: possible exploit.. (Cisco Issue)
*raising hand* guilty of not reading past Distribution after version 1.0. Someone else pointed that out off list. Thanks, Gerald On Fri, 18 Jul 2003, Barry Raveendran Greene wrote: The changes are all detailed at the bottom of the advisory. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gerald Sent: Friday, July 18, 2003 8:43 AM To: [EMAIL PROTECTED] Subject: Re: possible exploit.. (Cisco Issue) Wouldn't it be nice if they would CVS-web this thing so I can just see the lines that they have changed on each revision. :-) ...off to read 1.5 G On Fri, 18 Jul 2003, NANOG wrote: It appears Cisco has seen the posting too. The Cisco PSIRT updated their announcement to 1.4 at 5am this morning. The sentence in the Exploitation and Public Announcments section is new and states that they are aware that the exploitation has been publised on a public mailing list. The link is the same, but the version number has changed: http://www.cisco.com/warp/public/707/cisco-sa-20030717-blocked.shtml Len Rose wrote: It seems to work. On Fri, Jul 18, 2003 at 02:39:18AM -0400, Len Rose wrote: This was posted a while ago. http://lists.netsys.com/pipermail/full-disclosure/2003- July/011421.html http://lists.netsys.com/pipermail/full-disclosure/2003- July/011420.html I haven't had the chance to test it in a controlled environment yet.
Re:AOL MAIL BLOCKING
Sorry about the wrong url its http://postmaster.info.aol.com/
Cisco DoS exploits in the wild?
Hi all, Is anyone seeing active exploits of the latest Cisco DoS now that exploit code is public? The following article claims that attacks have been reported: http://biz.yahoo.com/djus/030718/1136000519_2.html Thanks, Scott __ Scott Waddell Global Defense Space Group Cisco Systems, Inc. [EMAIL PROTECTED]
Re: Cisco Vulnerability Testing Results
Just a quick credit email.. :) I wanna make sure credit is given to the 2 guys who helped with this testing.. Keith Pachulski and Chrus Kruslicky .. both from PTD.. :) On Fri, 2003-07-18 at 11:34, Jason Frisvold wrote: Ok, update to my testing : On Fri, 2003-07-18 at 10:48, Jason Frisvold wrote: Hi all, First post.. I hope this is ok ... We tested the Cisco vulnerability and I wanted to share our results with you ... SNIP Testing scenario is this : Linux Machine (10.0.0.2/24) Cisco 2514 Ethernet0 (10.0.0.1/24) is in from the attacker Ethernet1 (192.168.0.1/24) is output to the 2501 Cisco 2501 Ethernet0 (192.168.0.2/24) is in from the 2514 SNIP Firstly, HPing (www.hping.org) can craft the packets required for this attack very simply... I won't post the exact command string, but it's not that hard to figure out... And with HPing, you can easily take down an interface in under a second. Now, on to ACL testing... 3 ACL tests just to make sure we had everything correct ... We first tried the any any ACL that Cisco recommends : access-list 101 deny 53 any any access-list 101 deny 55 any any access-list 101 deny 77 any any access-list 101 deny 103 any any access-list 101 permit ip any any This produced expected results. When placed on the interface, it prevented the router from being attacked. Next, we tried an ACL with just the interface IP in it : access-list 101 deny 53 any host 10.0.0.1 access-list 101 deny 55 any host 10.0.0.1 access-list 101 deny 77 any host 10.0.0.1 access-list 101 deny 103 any host 10.0.0.1 access-list 101 permit ip any any We applied this to the Ethernet0 interface on the 2514. Attacks to that IP were prevented as expected. Attacks through to the 2501 were not blocked, again as expected. And finally, attacks to the ethernet1 interface on the 2514, which passes through the ethernet0 interface, still caused the ethernet0 interface to be attacked. And the last test was an ACL containing all of the IP's on the router: access-list 101 deny 53 any host 10.0.0.1 access-list 101 deny 55 any host 10.0.0.1 access-list 101 deny 77 any host 10.0.0.1 access-list 101 deny 103 any host 10.0.0.1 access-list 101 deny 53 any host 192.168.0.1 access-list 101 deny 55 any host 192.168.0.1 access-list 101 deny 77 any host 192.168.0.1 access-list 101 deny 103 any host 192.168.0.1 access-list 101 permit ip any any This blocked all attacks on the 2514 while still allowing attacks through to the 2501.. This is as expected. Also, another note. Loopback interfaces, while not vulnerable themselves, make it much easier to completely take out routers.. (We're assuming that the device is still vulnerable) If the attacker has the loopback of the router, they can run an attack at that interface. Every input interface will be attacked in succession. As each interface goes down and the traffic re-routed, the next interface will fall under attack. Just be sure to add the loopback IP as part of the ACL ... :) -- --- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering [EMAIL PROTECTED] RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --- Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -- Albert Einstein [1879-1955] signature.asc Description: This is a digitally signed message part
Re: Cisco exploit and Huawei
As listed on the advisory, e-maiing [EMAIL PROTECTED] A show tech and the chassis S/N on the front mail will help expedite the process... Rubens - Original Message - From: Vincent Poy [EMAIL PROTECTED] To: Rubens Kuhl Jr. [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Friday, July 18, 2003 12:01 PM Subject: Re: Cisco exploit and Huawei | Speaking about the patches, how does one get the patches if they | don't have a support contract with Cisco? | | | Cheers, | Vince - [EMAIL PROTECTED] - Vice President __ | Unix Networking Operations - FreeBSD-Real Unix for Free / / / / | / [__ ] | WurldLink Corporation / / / / | / | __] ] | San Francisco - Honolulu - Hong Kong / / / / / |/ / | __] ] | HongKong Stars/Gravis UltraSound Mailing Lists Admin /_/_/_/_/|___/|_|[] | [EMAIL PROTECTED] - oahu.DAL.NET Hawaii's DALnet IRC Network Server Admin |
ATT Contact
Anyone have an ATT Project Management/Provisioning contact in NYC who can get things done? Ive got a circuit thats been waiting 2 weeks for a smartjack and its getting towards crunch time with no smartjack. Thanks in advance, Hunter
Patching for Cisco vulnerability
Just out of curiosity, are folks just applying the Cisco patch or do you go through some sort of testing/validation process to ensure that the patch doesn't cause any other problems? Given typical change management procedures how long is taking you to get clearance to apply the patch? I'm trying here to gauge the length of time before this vulnerability is closed out. irwin
after Cisco IOS exploit patch
After I upgraded my IOS this morning I've seen 13,844 input errors on the port; when looking at the switch the router is connected to I see that a very similar number of multi-cast packets (13,423). Has anyone else seen this? Is this perhaps what the patch does (register exploit packets as input errors)? FastEthernet0/0 is up, line protocol is up Hardware is DEC21140A, address is 0002.1723.0800 (bia 0002.1723.0800) Internet address is 199.185.131.249/24 MTU 1500 bytes, BW 10 Kbit, DLY 100 usec, reliability 255/255, txload 106/255, rxload 118/255 Encapsulation ARPA, loopback not set Keepalive set (10 sec) Full-duplex, 100Mb/s, 100BaseTX/FX ARP type: ARPA, ARP Timeout 04:00:00 Last input 00:00:00, output 00:00:00, output hang never Last clearing of show interface counters never Input queue: 0/75/53/231 (size/max/drops/flushes); Total output drops: 733 Queueing strategy: fifo Output queue: 0/40 (size/max) 5 minute input rate 46298000 bits/sec, 9642 packets/sec 5 minute output rate 4171 bits/sec, 8891 packets/sec 163709405 packets input, 2006456215 bytes Received 11374 broadcasts, 0 runts, 0 giants, 2 throttles 13844 input errors, 0 CRC, 0 frame, 0 overrun, 13182 ignored 0 watchdog 0 input packets with dribble condition detected 15703 packets output, 1121349334 bytes, 0 underruns 0 output errors, 0 collisions, 2 interface resets 0 babbles, 0 late collision, 0 deferred 0 lost carrier, 0 no carrier 0 output buffer failures, 0 output buffers swapped out FastEthernet8 is up Hardware is FastEthernet, address is 00e0.5202.4613 (bia 00e0.5202.4613) Configured speed 100Mbit, actual 100Mbit, configured duplex fdx, actual fdx Member of L2 VLAN ID 1, port is untagged, port state is FORWARDING STP configured to OFF, priority is high, flow control enabled mirror disabled, monitor disabled Not member of any active trunks Not member of any configured trunks No port name 5 minute input rate: 43045336 bits/sec, 8985 packets/sec, 44.47% utilization 5 minute output rate: 46621104 bits/sec, 9711 packets/sec, 48.16% utilization 689714869 packets input, 3817420687 bytes, 0 no buffer Received 4493 broadcasts, 0 runts, 0 giants 5 input errors, 5 CRC, 0 frame, 0 ignored 13423 multicast 736196013 packets output, 1836390208 bytes, 0 underruns 0 output errors, 0 collisions saxon jones network infrastructure admin interbaun communications suite 200 18404 stony plain road edmonton, ab T5S 2M8 mailto:[EMAIL PROTECTED] http://www.interbaun.com/ (780) 447-8276
RE: Patching for Cisco vulnerability
I don't see a lot of choice with this exploit. It's easy and quick. I knocked down a 7206 in less than a minute. Expedite where you can. BobG -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Irwin Lazar Sent: Friday, July 18, 2003 2:30 PM To: [EMAIL PROTECTED] Subject: Patching for Cisco vulnerability Just out of curiosity, are folks just applying the Cisco patch or do you go through some sort of testing/validation process to ensure that the patch doesn't cause any other problems? Given typical change management procedures how long is taking you to get clearance to apply the patch? I'm trying here to gauge the length of time before this vulnerability is closed out. irwin
Re: Patching for Cisco vulnerability
On Fri, Jul 18, 2003 at 12:29:30PM -0600, Irwin Lazar wrote: Just out of curiosity, are folks just applying the Cisco patch or do you go through some sort of testing/validation process to ensure that the patch doesn't cause any other problems? Given typical change management procedures how long is taking you to get clearance to apply the patch? I'm trying here to gauge the length of time before this vulnerability is closed out. most providers can easily go from (for example) 12.0(21)S3 to 12.0(21)S7 with less testing than from 12.0(21)S to 12.0(25)S The hurdles are still there to maintain the necessary customer notifications, etc.. but aside from that, I think the press is doing their job (good or bad) in that most customers are aware that there's something bad going on and people are moving to protect the internet infrastructure. - jared -- Jared Mauch | pgp key available via finger from [EMAIL PROTECTED] clue++; | http://puck.nether.net/~jared/ My statements are only mine.
RE: Cisco exploit and Huawei
Title: RE: Cisco exploit and Huawei Now that would be quite telling - and may put the nail in the antitrust coffin! Chris -Original Message- From: Rubens Kuhl Jr. [mailto:[EMAIL PROTECTED]] Sent: Friday, July 18, 2003 10:44 AM To: [EMAIL PROTECTED] Subject: Cisco exploit and Huawei It would be interesting to know if Huawei routers also falls to the Cisco IOS exploit... Rubens
Re: Patching for Cisco vulnerability
On Fri, Jul 18, 2003 at 03:04:45PM -0400, Jared Mauch wrote: most providers can easily go from (for example) 12.0(21)S3 to 12.0(21)S7 with less testing than from 12.0(21)S to 12.0(25)S 12.0(21)S* (at least S5 and above) have broken SNMP interface counters and Cisco refuses to fix the bug in 12.0(21)S*, so people who don't want to lose money (accounting) are forced to upgrade to 12.0(25)S*. I guess they want to force all conservative ISPs to jump over the 12.0(22)S barrier. Some things won't be forgotten (see also recent discussion about the new non-Cisco-GBIC blocking). Voting with pockets takes place. Regards, Daniel
Re: Patching for Cisco vulnerability
On Fri, 2003-07-18 at 14:29, Irwin Lazar wrote: Just out of curiosity, are folks just applying the Cisco patch or do you go through some sort of testing/validation process to ensure that the patch doesn't cause any other problems? Given typical change management procedures how long is taking you to get clearance to apply the patch? I think a lot of providers are doing the minimum testing required (upgrade, does it boot? can I ping?) and then rolling it out... I guess it's more of an implicit trust type deal rather than having routers running with an increased load because of ACL's and still having the possibility of a vulnerable router because something was overlooked.. Going forward, if you go the ACL route, every time you add a new interface you need to be sure to either apply the any any acl to it, or add the new ip's to the big block by ip acl ... I'm trying here to gauge the length of time before this vulnerability is closed out. I don't think it will ever truly go away.. there are lots of older routers that won't be able to support the newer code, albeit small routers like the 2500's, but they'll exist.. irwin -- --- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering [EMAIL PROTECTED] RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --- Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -- Albert Einstein [1879-1955] signature.asc Description: This is a digitally signed message part
Re: Patching for Cisco vulnerability
I don't think it will ever truly go away.. there are lots of older routers that won't be able to support the newer code, albeit small routers like the 2500's, but they'll exist.. Yes I have some old routers (2500s) for which no code exists which is patched and small enough to sit in the flash/memory... acl acl ! Steve
Re: Patching for Cisco vulnerability
On Fri, 2003-07-18 at 15:37, Stephen J. Wilcox wrote: I don't think it will ever truly go away.. there are lots of older routers that won't be able to support the newer code, albeit small routers like the 2500's, but they'll exist.. Yes I have some old routers (2500s) for which no code exists which is patched and small enough to sit in the flash/memory... acl acl ! And given the low processing power of those routers, acl's hurt ... :( Steve -- --- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering [EMAIL PROTECTED] RedHat Engineer - RHCE # 807302349405893 Cisco Certified - CCNA # CSCO10151622 MySQL Core Certified - ID# 205982910 --- Imagination is more important than knowledge. Knowledge is limited. Imagination encircles the world. -- Albert Einstein [1879-1955] signature.asc Description: This is a digitally signed message part
Re: Patching for Cisco vulnerability
On Fri, Jul 18, 2003 at 03:31:25PM -0400, Jared Mauch wrote: 12.0(21)S* (at least S5 and above) have broken SNMP interface counters and Cisco refuses to fix the bug in 12.0(21)S*, so people who don't Do you have a DDTS I can reference? Not handy, but from cisco-nsp Archives I've found CSCea35259 and CSCdy30984, and a reference to CSCea63754 which I can't take a look at in BugToolkit. Symptom: SNMP output octet counter stops counting traffic (except some control plane traffic it seems), with every few days jumping by weird amounts producing such funny things like 150mbps spikes on a FE interface. I've seen a box with a nicely loaded FE (30-70mbps) which took (reproducably) just about 48 hours to have this interface stop counting. If this would have been a customer interface, it would have meant reload router every two nights or lose money. This bug is supposed to be (finally) fixed in 12.0(25)S1. Given that you a) don't want to lose money and b) don't want to do two whole-network upgrades within a short time, going to 12.0(21)S7 to fix the vulnerabilty is no real option, so people are more or less forced to put their networks on bigger risk by going from 12.0(21)S* to (25)S1. Regards, Daniel
Re: Patching for Cisco vulnerability
--On Friday, July 18, 2003 21:57:57 +0200 Daniel Roesen [EMAIL PROTECTED] wrote: On Fri, Jul 18, 2003 at 03:31:25PM -0400, Jared Mauch wrote: 12.0(21)S* (at least S5 and above) have broken SNMP interface counters and Cisco refuses to fix the bug in 12.0(21)S*, so people who don't Do you have a DDTS I can reference? Not handy, but from cisco-nsp Archives I've found CSCea35259 and CSCdy30984, and a reference to CSCea63754 which I can't take a look at in BugToolkit. Symptom: SNMP output octet counter stops counting traffic (except some control plane traffic it seems), with every few days jumping by weird amounts producing such funny things like 150mbps spikes on a FE interface. I've seen a box with a nicely loaded FE (30-70mbps) which took (reproducably) just about 48 hours to have this interface stop counting. If this would have been a customer interface, it would have meant reload router every two nights or lose money. This bug is supposed to be (finally) fixed in 12.0(25)S1. Given that you a) don't want to lose money and b) don't want to do two whole-network upgrades within a short time, going to 12.0(21)S7 to fix the vulnerabilty is no real option, so people are more or less forced to put their networks on bigger risk by going from 12.0(21)S* to (25)S1. I'm running 12.0(25.2)S, and it has the bug REALLY squashed. LER -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 972-414-9812 E-Mail: [EMAIL PROTECTED] US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749
Cisco vulnerability on smaller catalyst switches
As part of our vulnerability tests, we have been unable to confirm that the smaller catalyst switches running IOS but without L3 capability are vulnerable. They don't seem to react in a negative way to the same attacks that lock up the other devices we have tested. Has anyone else been able to verify this one way or the other? -- Chris Griffin [EMAIL PROTECTED] Network Engineer - CCNP Phone: (352) 392-2061 OIT - Network Services Fax: (352) 392-9440 University of Florida Gainesville, FL 32611
Re: Infrastructure Filtering (was Re: Patching for Cisco vulnerability)
* [EMAIL PROTECTED] (Christopher L. Morrow) [Sat 19 Jul 2003, 01:03 CEST]: hrm, what nodes don't run 55/53/77/103? What do? Do you have a list? Could we have it? I'm sure you know what devices in your network run Mobile IP or Sun ND (to paraphrase Randy Bush, you can probably count them on the fingers of your nose). Router#conf t Router(config)#ip receive-acl 10 no-idiocy Seriously though... the edge networks (as Jared pointed out) should be able to decide what they want to filter and what they don't... perhaps some large ISP would decide you don't want any traffic from 212/8 or perhaps all porn? Or all religious material? You don't want someone deciding what you do and don't get... unless that someone is you :) That's why I said that transit networks could filter only towards their own infrastructure. yes... inside my network I know what my loopbacks and links are, inside yours?? No idea... or Jared's or Tim Battles or... Luckily it's not your responsibility to protect them (only to intervene when advised they're under attack, which I've heard you're doing a very good job at - but that aside). Regards, -- Niels. -- The time of getting fame for your name on its own is over. Artwork that is only about wanting to be famous will never make you famous. Any fame is a bi-product of making something that means something. You don't go to a restaurant and order a meal because you want to have a shit. -- Banksy
RE: Cisco vulnerability on smaller catalyst switches
With the idea below. What is the current opinion about upgraded switches behind a firewall on a private lan? I suspect upgrade later or not at all. But curious about other's opinions.. Later, J -Original Message- From: Chris Griffin [mailto:[EMAIL PROTECTED] Sent: Friday, July 18, 2003 5:58 PM To: [EMAIL PROTECTED] Subject: Cisco vulnerability on smaller catalyst switches As part of our vulnerability tests, we have been unable to confirm that the smaller catalyst switches running IOS but without L3 capability are vulnerable. They don't seem to react in a negative way to the same attacks that lock up the other devices we have tested. Has anyone else been able to verify this one way or the other? -- Chris Griffin [EMAIL PROTECTED] Network Engineer - CCNP Phone: (352) 392-2061 OIT - Network Services Fax: (352) 392-9440 University of Florida Gainesville, FL 32611
RE: Cisco vulnerability on smaller catalyst switches
As part of our vulnerability tests, we have been unable to confirm that the smaller catalyst switches running IOS but without L3 capability are vulnerable. They don't seem to react in a negative way to the same attacks that lock up the other devices we have tested. Has anyone else been able to verify this one way or the other? I tested Catalyst 2924-XL-EN with 12.0(5)WC5a and I found that without L3 capability it does not seem to be affected. But with L3 connectivity, if you direct the attack at the VLAN1 interface it is definitely susceptible. I've tested 12.0(5)WC8 and it has the fix. --steve
RE: Infrastructure Filtering (was Re: Patching for Cisco vulnerability)
As mentioned before, Receive Path ACL (rACL) is already in 12.0(21)S2 (and forward) for the GSR and 12.0(24)S for the 7500. This is one way of doing infrastructure filtering without packet filtering the data plane (customer traffic). The second phase of Receive Path ACL (rACL) is going everywhere. The marketing name is Control Plane Protocol (CPP) ... but it also takes care of any packet punted to the receive path (i.e. packet with destination address = to the router). It is MQC based (ACL + rate-limiting). Think of it as a TCP wrapper for the receive path - but with the rate-limiting. The rate limiting part is important. It will first show up in 12.2S (and forward) and then cross-port/back-port through customer pressure (talk to your Cisco Account Teams). You'll see it on everything for the small boxes (26XX) to switches (CAT6Ks) to the high end (GSRs). Personally, I see this TCP Wrapper with Rate-Limit around a router as something that is going to be a requirement for all vendors on the Net. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Charles Sprickman Sent: Friday, July 18, 2003 1:21 PM To: [EMAIL PROTECTED] Subject: Infrastructure Filtering (was Re: Patching for Cisco vulnerability) This has me wondering if there are any BCPs that touch on the whole idea of filtering traffic destined to your router, or what the advisory called infrastructure filtering. All in all, it seems like a good idea to block any direct access to router interfaces. But as some have probably found already, it's a big pain in the arse. If I recall correctly, Rob's Secure IOS Template touches on filtering known services (the BGP listener, snmp), but what are people's feelings on maintaining filters on all interfaces *after* loading a fixed IOS? Thanks, Charles -- Charles Sprickman [EMAIL PROTECTED] On Fri, 18 Jul 2003, Irwin Lazar wrote: Just out of curiosity, are folks just applying the Cisco patch or do you go through some sort of testing/validation process to ensure that the patch doesn't cause any other problems? Given typical change management procedures how long is taking you to get clearance to apply the patch? I'm trying here to gauge the length of time before this vulnerability is closed out. irwin
Re: Infrastructure Filtering (was Re: Patching for Cisco vulnerability)
On Sat, 19 Jul 2003, Niels Bakker wrote: * [EMAIL PROTECTED] (Christopher L. Morrow) [Sat 19 Jul 2003, 01:03 CEST]: hrm, what nodes don't run 55/53/77/103? What do? Do you have a list? Could we have it? I'm sure you know what devices in your network run Mobile IP or Sun ND (to paraphrase Randy Bush, you can probably count them on the fingers of your nose). my nose has many fingers... wait, thats hairs! :) though I do agree... So, I must apologize for reading your message's intent in reverse. Router#conf t Router(config)#ip receive-acl 10 no-idiocy Seriously though... the edge networks (as Jared pointed out) should be able to decide what they want to filter and what they don't... perhaps some large ISP would decide you don't want any traffic from 212/8 or perhaps all porn? Or all religious material? You don't want someone deciding what you do and don't get... unless that someone is you :) That's why I said that transit networks could filter only towards their own infrastructure. Agreed, and it does, to some extent... As should anyone elses, eh? It makes sense that if you have either of the 2 main vendor's products you can accomplish this task easily and at 'no cost' yes... inside my network I know what my loopbacks and links are, inside yours?? No idea... or Jared's or Tim Battles or... Luckily it's not your responsibility to protect them (only to intervene when advised they're under attack, which I've heard you're doing a very good job at - but that aside). We thank you, its a group effort... but as I said above, my apologies, this current event has me a bit punchy :)
Re: Infrastructure Filtering (was Re: Patching for Cisco vulnerability)
On Fri, 18 Jul 2003, Niels Bakker wrote: Personally I'd try to filter packets destined for known router interfaces and let the rest pass through. And of course not run known-buggy software (famous last words...). That would mean Windows (pick your flavor.) :-) Sorry, I couldn't resist. Curtis -- Curtis Maurand mailto:[EMAIL PROTECTED] http://www.maurand.com
Re: Cisco vulnerability on smaller catalyst switches
My testing with the exploit I initially created has no effect on L2 only catalysts, like 2924XL or so. I haven´t been able to figure out the right sequence if any to accomplish that. No effect even on the management interface. Pete As part of our vulnerability tests, we have been unable to confirm that the smaller catalyst switches running IOS but without L3 capability are vulnerable. They don't seem to react in a negative way to the same attacks that lock up the other devices we have tested. Has anyone else been able to verify this one way or the other? -- Chris Griffin [EMAIL PROTECTED] Network Engineer - CCNP Phone: (352) 392-2061 OIT - Network Services Fax: (352) 392-9440 University of Florida Gainesville, FL 32611
