lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.21.0601120710450.21762-100000@linuxbox.org>
Date: Thu, 12 Jan 2006 07:14:42 -0600 (CST)
From: Gadi Evron <ge@...uxbox.org>
To: bugtraq@...urityfocus.com
Subject: Cisco, haven't we learned anything? (technician reset)


In this
(http://www.cisco.com/warp/public/707/cisco-sa-20060111-mars.shtml) recent
Cisco advisory, the company alerts us to a security problem
with Cisco MARS (Cisco Security Monitoring Analysis and Response System).

The security issue is basically a user account on the system that will
give you root when accessed.

The account is:
1. Hidden.
2. Default.
3. With a pre-set password.

In other words, this is a journey back 10 years when technicians would
commonly have special keys (actual keys, electronics or passwords) to
access a device if they have to troubleshoot it for anything, or say? the
user lost his password.

People used to trade these keys online and hidden accounts were a thing of
common practice. Today people still trade commonly used default passwords
but it is not as popular as it used to be, at least in the online world.

On the other hand, the most common practice to hack routers today, is
still to try and access the devices with the notoriously famous default
login/password for Cisco devices: cisco/cisco.

Cisco/cisco is the single most used default password of our time. It got
more routers pwned than any exploit in history, and it still does. One
would think that a company such as Cisco, especially with this history,
would stay away from such ?default? accounts? but the fact that this
account is hidden makes it something different.

It makes it a backdoor. One much like those used by the Bad Guys.

Now? if Cisco knowingly put it there, shame on them. If somebody put it
there without their knowledge? well, shame on them.

This is indeed a vulnerability, as in a weakness. It is not however a
software coding bug that may result in say? a buffer overflow. It is a
part of the design of the system.
Cisco disclosing this is very nice and commendable, but perhaps they
should also let us know whether this was indeed a backdoor somebody put in
their system or if it was part of the design?

I love eastereggs. I just don?t like surprises in system privileges or
backdoors, especially not in a security monitoring and response product.

I very much doubt it was anything else but a part of the design but that
should be admitted to.
As the advisory states:

    "No other Cisco products are currently known to be affected by this
vulnerability."

Okay, but how about other vulnerabilities of this type? Are there any more
backdoors to other Cisco products?
If not, why wouldn?t they just come out and say that?
?There are NO other such backdoors in our products?.

I?d even be happy with:
?To our knowledge, there are no other vulnerabilities of this type in our
products.?

This is not a bug. One can never be sure ALL bugs are eliminated ? however
hard one may try.
One CAN admit to having no such features in other products, though.

Once again we fall upon re-naming of a feature as a bug or a bug as a
feature to make the problem sound less severe.

IN this case, the judgement is plain and simple:
If Cisco were Bad Guys, this is a backdoor.
As Cisco are Good Guys, this is a technician reset.

Terminology? What?s the difference?

The difference is that Cisco are not Bad Guys. If they disclosure a
problem they should do it fully, because as a client, I am now concerned.

This reminds me of Ciscogate but not for obvious reasons. That was a bad
event for everybody involved.
It reminds me of the very issue Mike Lynn discussed:
Remote exploitation for Cisco is possible, while so far Cisco disclosed
all these problems as DoS vulnerabilities.
I am not saying Cisco did that on purpose, but in THIS case they CAN set
my mind at ease.

Why don?t they?

	Gadi.



Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ