- Test - lists.nanog.org

Patching for Cisco vulnerability
by Irwin Lazar 20 Jul '03

20 Jul '03

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

15 22

RE: Working vulnerability? (Cisco exploit)
by Ben Buxton 19 Jul '03

19 Jul '03

It's released and it works - I have verified it in a lab here. BB > -----Original Message----- > From: Ken Yeo [mailto:kenyeo@on-linecorp.com] > Sent: Friday, July 18, 2003 3:24 PM > To: nanog(a)merit.edu > 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.** > > >

6 6

qmail smtp-auth bug allows open relay
by John Brown 19 Jul '03

19 Jul '03

seems that there are installs of the smtp-auth patch to qmail that accept anything as a user name and password and thus allow you to connect. http://marc.theaimsgroup.com/?l=qmail&m=105452174430616&w=2 is one URL that talks about this. There has been an increase is what appears to be qmail based open-relays over the last 5 days. Each of these servers pass the normal suite of open-relay tests. Spammers are scanning for SMTP-AUTH and STARTTLS based mail servers that may be misconfigured. Then using them to send out their trash. Some early docs on setting up qmail based smtp-auth systems had the config infor incorrect. This leads to /usr/bin/true being used as the password checker. :( >From an operational perspective, I suspect we will see more SMTP scans The basic test (see URL above) should get incorporated into various open-relay testing scripts. cheers john brown chagres technologies, inc

6 7

RE: Working vulnerability? (Cisco exploit)
by Ben Buxton 19 Jul '03

19 Jul '03

Yep its all a bit weird, I guess people are not too knowledgeable about it. For starters the original explit wont work very well out of the box for most script kiddies (random source addresses -> killed by anti-spoofing), and a single packet to a vulnerable box isnt enough (need to fill the queue slots). More of an annoyance really - most of the outages as a result are going to be from people upgrading boxes, not victims of attack. BB > -----Original Message----- > From: jlewis(a)lewis.org [mailto:jlewis@lewis.org] > > On Fri, 18 Jul 2003, Ben Buxton wrote: > > > It's released and it works - I have verified it in a lab here. > > And others are trying it in the field now. I setup the recommended > transit ACLs yesterday. Starting at 9:25am EDT this morning, > those ACLs > started getting hits. What doesn't make sense to me is > according to the > advisory, the packets have to be destined for the router to > crash it (not > just passed through it), but people are attacking seemingly > random IPs, > including ones in a new ARIN block that have not yet been > assigned/used > for anything. What do they think they're attacking? > > ---------------------------------------------------------------------- > Jon Lewis *jlewis(a)lewis.org*| I route > System Administrator | therefore you are > Atlantic Net | > _________ http://www.lewis.org/~jlewis/pgp for PGP public key_________ > >

4 3

Cisco Vulnerability Testing Results
by Jason Frisvold 19 Jul '03

19 Jul '03

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 friz(a)corp.ptd.net 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]

5 7

Re: Working vulnerability? (Cisco exploit)
by Paul Vixie 19 Jul '03

19 Jul '03

> >I'd estimate than less than a tenth of a percent (that's 0.1%) of > >edge paths use RPF, even though BCP38 states the case clearly and the > >technology makes it easy > "Makes it easy" if you live in an Internet with a number of routes > significantly less than the limit imposed for having stable RPF > enabled on your devices, or have devices without bugs in RPF checking > when said limit is spotted vaguely across the horizon. since those are two very common beliefs about BCP38 deployment, i'm going to leave it to barry to repost his standard answers to them, once he's gotten some sleep. > I dont seem to be in either of those places. (Although I have not > sacrificed a router in the last upgrade version or two to see if things > have improved.) please do, and please post your results, as an example to others.

1 0

Cisco vulnerability on smaller catalyst switches
by Chris Griffin 19 Jul '03

19 Jul '03

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 cgriffin(a)ufl.edu Network Engineer - CCNP Phone: (352) 392-2061 OIT - Network Services Fax: (352) 392-9440 University of Florida Gainesville, FL 32611

2 1

RE: Cisco vulnerability on smaller catalyst switches
by Steve Rude 19 Jul '03

19 Jul '03

>> 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 believe directing the attack to VLAN1 should just kill the remote > management and won't effect switching capability. Can anyone confirm? Ah, you are right. I just tested it, and the switching through the catalyst continues without interruption. Only the management interface is unavailable. --steve

1 0

RE: Cisco vulnerability on smaller catalyst switches
by Steve Rude 19 Jul '03

19 Jul '03

> 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

2 1

RE: Cisco vulnerability on smaller catalyst switches
by McBurnett, Jim 18 Jul '03

18 Jul '03

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:cgriffin@ufl.edu] Sent: Friday, July 18, 2003 5:58 PM To: nanog(a)merit.edu 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 cgriffin(a)ufl.edu Network Engineer - CCNP Phone: (352) 392-2061 OIT - Network Services Fax: (352) 392-9440 University of Florida Gainesville, FL 32611

1 0