Cisco vulnerability and dangerous filtering techniques
I had a passing thought over the weekend regarding Thursday's cisco vulnerability and the recent Microsoft holes. The next worm taking advantage of the latest Windows' vulnerabilities is more or less inevitable. Someone somewhere has to be writing it. So why not include the cisco exploit in the worm payload? Based on past history, there will be plenty of vulnerable Windows hosts to infect with the worm. I would also guess that there are lots of organizations and end-users that have cisco devices that haven't patched their IOS. Furthermore, I wonder how many people have applied filtering only at their border? But packets from an infected host inside the network wouldn't be stopped by filtering applied only to the external side. Basically, if you're filtering access to your interface IP's rather than upgrading IOS, remember that the internet isn't the only source of danger to your network. Adam Maloney Systems Administrator Sihope Communications
* adamm@sihope.com (Adam Maloney) [Tue 22 Jul 2003, 15:33 CEST]:
The next worm taking advantage of the latest Windows' vulnerabilities is more or less inevitable. Someone somewhere has to be writing it. So why not include the cisco exploit in the worm payload?
Why would a worm disable a vital component on its path to new infections? -- Niels.
On Tue, 22 Jul 2003 15:40:02 +0200, Niels Bakker <niels=nanog@bakker.net> said:
* adamm@sihope.com (Adam Maloney) [Tue 22 Jul 2003, 15:33 CEST]:
The next worm taking advantage of the latest Windows' vulnerabilities is more or less inevitable. Someone somewhere has to be writing it. So why not include the cisco exploit in the worm payload?
Why would a worm disable a vital component on its path to new infections?
It's not part of the spread-the-worm code, it's part of the DDoS engine that it leaves behind. If you get lucky, one of your 20K zombies is the other side of a router along with whoever you're pissed at and want to DDoS, so you send the command, and the zombie sprays 76 packets, goes to sleep for 30 mins, sprays another 76.. lather rinse repeat. I'm going to go out on a limb and say that at least 30% of Ciscos are installed in places that would, if hit with this, have NO CLUE why their router needs to be power cycled every 30 mins.....
On Tue, 2003-07-22 at 09:54, Valdis.Kletnieks@vt.edu wrote:
I'm going to go out on a limb and say that at least 30% of Ciscos are installed in places that would, if hit with this, have NO CLUE why their router needs to be power cycled every 30 mins.....
Not only the "clueless", but how about those of us who deploy older routers sometime in the future with legitimate uses? What happens when we "forget" that this bug exists? Now we have to go through the process of adding a "don't forget the IPV4 Cisco Bug" clause to our procedures.. -- --------------------------- Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering friz@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]
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 22 Jul 2003, Jason Frisvold wrote:
Not only the "clueless", but how about those of us who deploy older routers sometime in the future with legitimate uses? What happens when we "forget" that this bug exists? Now we have to go through the process of adding a "don't forget the IPV4 Cisco Bug" clause to our procedures..
You don't need to add that clause as long as you maintain a set of baseline configurations. If you deploy all routers with the same code, or as close to it as possible, then you don't have to remember individual security alerts, because as you update the code on your existing routers, you should be creating a new baseline that should be installed on all newly deployed routers. allan - -- Allan Liska allan@allan.org http://www.allan.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE/HXtTvfQS9KzHT6ARAo+1AJ0WYoveQOYum6Fjqt2BgphxAIw2tACfRRTo pyJ71GMRlVYpltvuUrWsLLo= =hFp+ -----END PGP SIGNATURE-----
In our case we use some older routers as managment devices... Not critical to the core unless there is some larger outage... Those devices are old enough that they can't handle a newer rev of code... ACL's are the only answer there.. Luckily they have very little traffic even under heavy use, so ACL's don't hurt as much, but still something we need to be aware of.. On Tue, 2003-07-22 at 13:58, Allan Liska wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 22 Jul 2003, Jason Frisvold wrote:
Not only the "clueless", but how about those of us who deploy older routers sometime in the future with legitimate uses? What happens when we "forget" that this bug exists? Now we have to go through the process of adding a "don't forget the IPV4 Cisco Bug" clause to our procedures..
You don't need to add that clause as long as you maintain a set of baseline configurations. If you deploy all routers with the same code, or as close to it as possible, then you don't have to remember individual security alerts, because as you update the code on your existing routers, you should be creating a new baseline that should be installed on all newly deployed routers.
allan - -- Allan Liska allan@allan.org http://www.allan.org -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE/HXtTvfQS9KzHT6ARAo+1AJ0WYoveQOYum6Fjqt2BgphxAIw2tACfRRTo pyJ71GMRlVYpltvuUrWsLLo= =hFp+ -----END PGP SIGNATURE----- --
Jason H. Frisvold Backbone Engineering Supervisor Penteledata Engineering friz@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]
Hi Adam, I thought the same, and the solution is to apply the filters to all interfaces not just the borders. One thing about the worm idea is that if it hits routers it should burn itself out fairly quickly as it cuts off its own access. Another thing is it is necessary to send out probes prior to launching an attack which will reveal the source address, it is necessary to use non-spoofed traceroutes (or other ttl-expire technique) as you must set the ttl on the attack packets so that it arrives with ttl 0 Steve On Tue, 22 Jul 2003, Adam Maloney wrote:
I had a passing thought over the weekend regarding Thursday's cisco vulnerability and the recent Microsoft holes.
The next worm taking advantage of the latest Windows' vulnerabilities is more or less inevitable. Someone somewhere has to be writing it. So why not include the cisco exploit in the worm payload?
Based on past history, there will be plenty of vulnerable Windows hosts to infect with the worm. I would also guess that there are lots of organizations and end-users that have cisco devices that haven't patched their IOS. Furthermore, I wonder how many people have applied filtering only at their border? But packets from an infected host inside the network wouldn't be stopped by filtering applied only to the external side.
Basically, if you're filtering access to your interface IP's rather than upgrading IOS, remember that the internet isn't the only source of danger to your network.
Adam Maloney Systems Administrator Sihope Communications
participants (6)
-
Adam Maloney -
Allan Liska -
Jason Frisvold -
Niels Bakker -
Stephen J. Wilcox -
Valdis.Kletnieks＠vt.edu