Re: Cisco 675 Denial of Service Attack

[J Edgar Hoover <zorch () TOTALLY RIGHTEOUS NET>]

While it is always pleasure to discuss security issues with gaus, this
illustrates my point wrt to public disclosure. I'm a customer who paid a
premium price for a premium brand product for my home, and now I'm
following up by providing free a service that is worth more than the
product itself.

On Tue, 5 Dec 2000, Damir Rajnovic wrote:

> Hello there,
>
> At 15:17 01/12/2000 -0800, J Edgar Hoover wrote:
> > At the risk of further delaying the actual release of an upgrade... there
> > are some other problems with the Cisco 675.
>
> We are correcting the threat model an we will address some of concerns
> raised in this and other mails there.

The advisory was a good idea, particularly with work arounds noted.
Shipping the fix on time will be nice.

It is the unfortunate truth that neither the advisory or patch will help
the average home user. They will probably never know about them. Which
brings up another point... why is a product like this, destined for a home
user, shipped with such poor default security? The problems with SNMP have
been known and well documented since before the product shipped. Does
Cisco really think home users want anonymous remote users seeing their
network connections? Is there any need to have the password readable in
nvram from the command line? How long have TFTP issues been public?

> > If you disable telnet, it still accepts connections on port 23. You can
> > move telnet to port xxx and disable telnet, and it will listen on port
> > xxx. Vulnerable to DoS, possible exploit.
>
> How?

My interest here was to protect myself, not to develop an exploit. I
disabled telnet, set the port to a high number, and set the timeout to one
second. Then I wailed on the port with mostly common DoS tools.

One type of syn flood caused the router to stop responding for the
duration of the attack. Somewhere along the line, something caused it to
stop responding at all on that port until power cycled.

> > The IP Filtering is a joke. The command line doesn't match the written or
> > electronic documention, and the actual filter rules don't do what they
> > claim to do.
>
> Do you have any example which you mind to share (not documentation
> bugs)?

The IP filter rules made mistakes wrt incoming and outgoing directions.

> > Before anyone flames me about not notifying Cisco privately... keep in
> > mind it is not my job to help cisco develop a more secure product. I've
> > had vendors sit on bugs for over a year, threaten legal action, and just
> > plain waste my time in a volley of denials and questions. It's far more
> > efficient to just release the bugs on IRC.
>
> Yes, we goofed this time. How much more ashes we need to spill upon ourselves?

None, that was never the point. This thread started entirely because this
type of situation is too common. Many vendors try to sit on bugs for far
too long. Cisco is not the worst.

> It is true that customers should not be in a business of helping Cisco
> to make more secure products but it just happen to be that way. Then again,
> no one is asking you to help us or any other vendor for that matter. It
> is up to you to decide what you will do. From our side, we are trying to
> be proactive as much as we can. It is not much as we would like to but we
> can not do more at this time.

What is the TV ad? Something to do with the overwhelming percentage of
networks running on Cisco? With this type of market in critical areas of
infrastructure, somebody really should do comprehensive security audits on
these products before they are deployed.

With various tools to exploit SNMP, telnet and tftp, the majority of
"Cisco Powered" networks can be downed.

Which situation is worse for the corporate bottom line, "Cisco releases
patches for most of their routers" or "15 year old canadian cripples
internet with Cisco bug"?

> If someone thinks that it can do better I would like to see that person.
> We are looking to enlarge PSIRT so if any one think that (s)he is up to
> the challenge just send us your CV and we will talk.

You probably already have some highly skilled technical people. Do they
audit products before they ship? Are recommendations applied to products
before they go to market? If the answer is no, I'd say the core problem is
more corporate than technical.

Cheers,
zorch