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.
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
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.....
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..
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
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
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..