Cisco, haven't we learned anything? (technician reset)

In this
(http://blogs.securiteam.com/wp-admin/post.php?action=edit&post=207) 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.

In this
(Vulnerability Security Testing & DAST | Fortra's Beyond Security) 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.

...

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

Cisco acquired Protego in Dec 2004 and thereby acquired MARS:
http://www.infoworld.com/article/04/12/20/HNciscoprotego_1.html

Cisco didn't put it in there - they bought the bug for $65M. :slight_smile:

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 am sure there are more. The previous one I remember was with their
Riverhead purchase:

and before that was:

but I don't know which company was purchased to introduce that one.

I think Cisco just doesn't check the product closely enough and trusts the
R&D coders and doesn't introduce an external security QA to the product
being purchased.

-Hank

Hi, NANOGers.

] 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.

This is NOT a default password in the IOS. The use of "cisco" as
the access and enable passwords is a common practice by users, but
it isn't bundled in the IOS. I've heard it began in training
classes, where students were taught to use "cisco" as the
passwords.

Oh, and for those of you who think it mad leet to use "c1sc0" as
your access and enable passwords, the miscreants are on to that as
well. :wink:

We've seen large, massively peered and backbone routers owned
through this same technique. We've even seen folks who have
switched to Juniper, yet continue to use "cisco" as the login and
password. :frowning:

The nice thing about cooking up blame is that there is always
enough to serve everyone.

Thanks,
Rob.

Hi, Matthew.

] Cisco Router and Security Device Manager (SDM) is installed on this device.
] This feature requires the one-time use of the username "cisco"
] with the password "cisco".

Interesting. Is it limited to one-time use? Are the network login
services (SSH, telnet, et al.) prevented from using this login and
password?

Thanks!
Rob.

I know the AP350 comes with a default Cisco/Cisco account..

  (as opposed to doing a nvram/config clear and
it only lets you login on console).

  problem is with cisco each product group controls how
they ship their system, so the Aironet teams don't quite seem
to get this IMHO. That doesn't mean your 76k/GSR/CRS-1 will have
Cisco/Cisco, but your aironet products sure may.

  - jared

Hi, NANOGers.

You all know how I love a good segue... :wink:

How can you tell if your router has been owned? In general the
configuration will be modified. This is why we advocate using rancid
(or something akin to it) as both a configuration backup tool AND an
early warning tool. If you have a router running BGP, it also pays
to peer with it externally. You can use a private ASN and rackspace
with a buddy. You can use this peering to detect announcements you
don't expect or necessarily condone.

How else can you tell? Here are some tips:

If there is a new user account, or if the enable and access passwords
have changed, look out! The miscreants love to scan and find routers
with "cisco" as the access and enable passwords. They know that
other miscreants are doing the same thing. In fact this is even more
widespread thanks to a module found in rBot and rxBot. Yes, even
bots are scanning for routers now.

If there are new or changed ACLs, look out! The miscreants love to
use routers as IRC bounces. To avoid detection by IRC server proxy
monitors, the miscreants will block access to the router (generally
all access, sometimes just TCP 23) from those proxy monitors using
ACLs.

If there are new or changed SNMP RW community strings, look out!
One of the tricks they employ is to leave a SNMP RW community
backdoor. Is this to avoid the actions of we good folk? No, it's
usually employed in the case where a compromised router is stolen
from one miscreant by another.

If the banner has changed, look out! As with the ACLs, this is a
method by which the miscreants attempt to fool any proxy monitors.
The most common banner we see identifies the router as a FreeBSD
box.

If tunnels suddenly appear on the router, look out! Chaining
together lots of routers is also common now. This provides
obfuscation and sometimes encryption.

Most of the changes are based on templates. Consider this bundled
clue, where the prowess of the template user isn't at all a factor.

Use the flows. :slight_smile:

Thanks,
Rob.

Many products have default STARTING passwords. Whose fault is it that
someone can't figure out that it's not real bright if they don't change it?

The hidden ones are more an issue (with static passwords as opposed to
generated ones).

Scott

PS. If your briefcase still uses 0000 as the combination, I have no
sympathy for your missing items... :wink:

No. No. (It's nothing special -- it doesn't do anything you couldn't
configure manually on a pre-SDM device if you wanted.)

     -- Brett

Just as an offshoot discussion, what's the state-of-the-art for AAA services? We use an modified tacacs server for multi-factor authentication, and are moving towards a model that supports single-use/rapid expiration passwords, with strict control over when and how local/emergency authentication can be used.

I'd be interested in that discussion, on or offlist.

- billn

I've been pretty happy with Cisco ACS - fairly solid, good reporting,
once set up it seems to Just Work.

John

I thought everyone sensible put ACLs on vtys. Guess I was wrong.

-Dan

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yo Rob!

If you have any SNMP v1/v2 RW communities what so ever, you're likely to be owned, at least if they're common to several units in your network and you don't limit what part of the tree the RW communities can access.

Seems like a common attack vector is to send SNMP WRITE and upload the router configuration to a hacked tftp server, and then iterate thru the network as a lot of people have a single SNMP WRITE community in their network.

If there is a new user account, or if the enable and access passwords
have changed, look out! The miscreants love to scan and find routers
with "cisco" as the access and enable passwords.

I thought everyone sensible put ACLs on vtys. Guess I was wrong.

I've seen ACL-less VTYs because someone copied a config from a router
with fewer VTYs. 8-(

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?

I did not change my mind, but to be fair, I have to add:

After writing this I�ve been made aware that this product was from a company Cisco bought not so long ago. This very same issue happened before (and more than once)... in one recent example with another company Cisco bought named Riverhead.

It is true Cisco's PSIRT is one of the best to work with among vendors, even Mike Lynn said that Cisco PSIRT are some of the more decent people he worked with - "I've never had a problem with PSIRT".

It is also true that Cisco can't find out about these until after they buy the companies, still, Cisco f*cked up, more than just once or twice, and we call it. This kind of a so-called "vulnerability" should not happen, or be disclosed, continually, in this particular fashion.

Checking into new investments security-wise, especially with security products and external QA may help solve such issues in the future.

  Gadi.

On Fri, 2006-01-13 at 01:30:52 +0200, Gadi Evron proclaimed...

Checking into new investments security-wise, especially with security
products and external QA may help solve such issues in the future.

Thank you for this interruption. We now returned to our scheduled
programming, already in progress.

Rob Thomas wrote:

Hi, NANOGers.

] 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.

This is NOT a default password in the IOS. The use of "cisco" as
the access and enable passwords is a common practice by users, but
it isn't bundled in the IOS. I've heard it began in training
classes, where students were taught to use "cisco" as the
passwords.

Actually, and fairly recently, this IS a default password in IOS. New out-of-box 28xx series routers have cisco/cisco installed as the default password with privilege 15 (full access). This is a recent development.

To be fair, the box also has a huge default login banner urging the user to delete that username/password pair. But we all know how much attention is paid to huge, verbose banners, disclaimers, click-to-agree dialog boxes, etc.

Actually, and fairly recently, this IS a default password in IOS. New out-of-box 28xx series routers have cisco/cisco installed as the default password with privilege 15 (full access). This is a recent development.

This is hardly only cisco's problem. Most office routers I've dealt with
also come with default username/password and on occasions when I dealt
with existing installation those passwords have rarely been changed.

What should really be done (BCP for manufactures ???) is have default
password based on unit's serial number. Since most routers provide this
information (i.e. its preset on the chip's eprom) I don't understand
why its so hard to just create simple function as part of software to use this data if the password is not otherwise set.

william(at)elan.net wrote:

Actually, and fairly recently, this IS a default password in IOS. New out-of-box 28xx series routers have cisco/cisco installed as the default password with privilege 15 (full access). This is a recent development.

This is hardly only cisco's problem. Most office routers I've dealt with
also come with default username/password and on occasions when I dealt
with existing installation those passwords have rarely been changed.

True. However I much prefer the old way that Cisco did it. No default passwords on the box at all. But, no remote administration at all until a password was set on the console.

Now, there is a default cisco/cisco. Newbie admin creates a new user/pass, tests thinks it's secure, fails to remove the default, game over.

What should really be done (BCP for manufactures ???) is have default
password based on unit's serial number. Since most routers provide this
information (i.e. its preset on the chip's eprom) I don't understand
why its so hard to just create simple function as part of software to use this data if the password is not otherwise set.

The old-school Cisco way works for me. Default is no password if you have physical access, but no remote access.

That works too and is most secure way.

But its often enough that small offices would not have person who can fix the system and its not always possible to get network guy to come in right
a way. It is good for those cases to be able to ask somebody onsite to just
look at the back and dictate the serial# by phone.