Cisco Can’t Stop Using Hard-Coded Passwords

There’s a new Cisco vulnerability in its Emergency Responder product:

This vulnerability is due to the presence of static user credentials for the root account that are typically reserved for use during development. An attacker could exploit this vulnerability by using the account to log in to an affected system. A successful exploit could allow the attacker to log in to the affected system and execute arbitrary commands as the root user.

This is not the first time Cisco products have had hard-coded passwords made public. You’d think it would learn.

Tags: Cisco, passwords, vulnerabilities

Posted on October 11, 2023 at 7:04 AM • 19 Comments

Comments

R.Cake • October 11, 2023 9:42 AM

pheww… I guess this is what you get if you go cheap: for the “new product”, you just order a bunch of subcontractors to take the design database of a 12 year old product as-is (I am only making this up of course) and touch it up in a few places to only just check all the requirements of the specifying customer.
As the subcons are only paid to do the bare minimum, that is exactly what they will do. They will certainly not have the initiative to do a security review, unless that is explicitly asked for. Very likely they are also not subject matter experts, nor trained in security.
Another nice example of the pleasures of capitalism at work for you…

Me • October 11, 2023 10:14 AM

@R.Cake

Sadly, this sounds like a likely scenario, though you would think that the previous product’s defect list would make it into the design spec.

Mike Norman • October 11, 2023 10:23 AM

I once was a contractor to Cisco (up here in Canada) and everyone that recently joined
went to a 5-day security course (well 5 half-days) On the first day, the instructor mentioned
the ‘hard-coded userid/password’ problem and then that very night on US National TV
(MSNBC, CNN, etc.) a story broke about Cisco and a hard-coded u/p problem in a popular
product (ie. millions of installed devices worldwide). I told everyone about that on Tuesday …
and then on Wednesday evening, another CVE report of hard-coded u/p (this time not
mainstream TV news, but still!) .. when I told the class on Thursday, I could see that the
instructor had labelled ME the ‘trouble-maker’ 🙂

Professional Cynic • October 11, 2023 11:17 AM

My cynical view is that Cisco has learned. They’ve done the math and decided that the static credentials are better for their bottom line. It’s going to save them a ton in support center calls when the customer fubars their machine and locks themselves out. If it turns into an exploit they can easily patch it out but the security hole isn’t likely to cost them any sales. The product in question is an add-on to their enterprise unified communications platform. The purchase decision is made much, much higher up than anyone who actually understands the security implications. The static credentials may even be passed off as some sort of rapid response customer support feature.

Mind you, I’m not picking specifically on Cisco here. I’d be equally cynical about any vendor in this situation. Maybe I just woke up on the wrong side of the testbed this morning.

Mexaly • October 11, 2023 11:55 AM

Isolate your Cisco gear from the Internet.
Oh, wait.

P.Robbins • October 11, 2023 3:29 PM

They’ve done the math and decided that the static credentials are better for their bottom line. It’s going to save them a ton in support center calls when the customer fubars their machine and locks themselves out.

There are other ways to do that, such as pre-installed certificates whose private keys are only known to Cisco (at least initially). Arguably, that’d be worse for users. People wouldn’t consider it a “vulnerability” until it were proven that someone else had the keys; if such attackers kept a low enough profile, there’s a chance the public would never find out.

Eitan Caspi • October 11, 2023 4:28 PM

Sorry, but not sorry, this means Cisco is doing this intentionally. The same thing over and over again for years is way beyond negligence. The only question is the motive.

Chris • October 11, 2023 7:18 PM

I once worked for a system company where I was working in the lab on a new product. I looked into my .ssh/known_hosts file for some reason and noticed that all of the machines in the lab had the same public ssh key. They were installed from the exact same image which included the key itself. It’s lucky that I noticed this before we shipped anything or else every customer would know every other customer’s private key.

Sean • October 12, 2023 3:23 AM

Well, even companies like Hikvision do not have a hard coded key as far as I have seen, just have a recovery method that you use to recover a lost key, or at least can use a private key on the machine to recover it. Had to use it a few times to recover DVR passwords, and the setup will not allow a weak key either, they at least have done something right there to force stronger logins. Yes it is connected, but also the router has PNP turned off, so it cannot accept connections, unless via NAT traversal.

Peter A. • October 12, 2023 5:48 AM

This was a common practice in the past, when not everything was connected to the Internet but had a local (mostly serial) console. Almost every equipment had a “service password”, it was easier for the service people to just log in, do needed changes and charge an exorbitant fee. It was reasonably secure. Now that the service is done over the ‘net, it’s a wholly different picture.

At the university I was working for in the past, we had a large (for the time) HP server. Whenever we wanted to reconfigure something in the firmware we had to call support and pay for a guy to arrive. He always asked us out of the server room, sat at the console and did his job. One particular time we had put a Linux laptop with two RS-232 ports below the raised floor, connected one port to the server and the other to the HP text terminal working as the console, and run two ‘tee’ commands to copy the data from one port to the other and vice versa while saving it to files. Voila! The password proved to be a trivial one, we probably could have guessed it if we tried a bit harder. Since then, we were able to do whatever we wanted with our server without ruining our department’s small operational budget.

R.Cake • October 12, 2023 7:57 AM

@Peter A. – thanks a lot for sharing, excellent job back then 😀
Around 1990, I worked with IBM mainframes, and they all had a service console physically installed into them for the technical team to run maintenance and reconfiguration. I guess you are right, the default settings for those service consoles is very likely exactly what was copied to the online maintenance interface without much thought to the consequences and the changed risk profile… at least for the first few generations. Today, we should really really be beyond that point.

Sheilagh Wong • October 12, 2023 5:15 PM

They deserved to be sued.

Meme • October 13, 2023 6:26 AM

Having a harder and harder time assuming this is yet another innocent mistake.

Neil • October 13, 2023 7:50 AM

@R.Cake – seriously!? Capitalism!? I’m so tired of the downers on capitalism. This will happen regardless of the ideology / ism / whatever you mention. Mankind is lazy, it’s our defining characteristic. There, fixed it for ya. And don’t thank me, buy me a present, a small Cadillac will do…

Sok Puppette • October 13, 2023 8:08 AM

If the problem at Cisco is the same as it used to be, it’s that Cisco actually can’t and doesn’t build new products. As a matter of POLICY, Cisco acquires companies instead of inventing things. Turns out that the companies they buy up are small and growing and cut corners and do stupid things.

Of course, Cisco also doesn’t properly audit the products when they buy the companies…

Clive Robinson • October 14, 2023 7:11 PM

@ Bruce, ALL,

From BSD 14.0-RC1 dated,

Friday 13th…

(That is “Spooky-Wooky hallows fest yesterday, what could possibly go wrong 😉

https://lists.freebsd.org/archives/freebsd-stable/2023-October/001547.html

Well…,

“Note regarding arm SD card images: For convenience for those without console access to the system, a freebsd user with a password of freebsd is available by default for ssh(1) access. Additionally, the root user password is set to root. It is strongly recommended to change the password for both users after gaining access to the system.”

And the world still turns 😉

ResearcherZero • October 17, 2023 4:05 AM

Disable the HTTP/S server feature on internet-facing systems (vulnerability in the Web User Interface)

Any switch, router or WLC running IOS XE and has the web UI exposed to the internet is vulnerable.

‘https://blog.talosintelligence.com/active-exploitation-of-cisco-ios-xe-software/

CVE-2023-20198

“CVE-2023-20109 is not related to the advisory today.”

‘https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-iosxe-webui-privesc-j22SaA4z

lurker • October 17, 2023 1:15 PM

@ResearcherZero

“Disable the HTTP/S server feature” fullstop.

Mind you, establishing an RS232 link can these days be a non-trivial exercise.

Jesse Thompson • October 19, 2023 3:56 PM

@lurker Nah, it’s super easy. Barely an inconvenience.
I just use this cloud-managed KVM system that plugs into the RS232 ports on all of the cisco gear, and presents an HTTP/S Javascript front end to access the console ports on each of them. 😋

Schneier on Security

Cisco Can’t Stop Using Hard-Coded Passwords

Comments

Leave a comment Cancel reply