9 ms·

Cisco can't stop using hard-coded passwords

221 points by pabs3 3y ago

bell-cot 3y ago
[Facepalm] Daydream: A new law puts legal liability for the consequences of hard-coded passwords on the manufacturers and their distribution chains. (The latter so Amazon can't sell root-holed crap from Lucky Good Fast Router Co. this week, then that company vanishes and Amazon sells amazingly similar crap from Good Lucky Fast Router Co. next week, then that company vanishes and ...)
- fweimer 3y ago
  Not going to happen. Most online services require applications that access them to embed hard-coded, obfuscated passwords in the binaries. That doesn't really work for open-source software, and Thunderbird's hard-coded passwords are easily viewed: https://hg.mozilla.org/comm-central/file/tip/mailnews/base/src/OAuth2Providers.jsm#l79 https://hg.mozilla.org/comm-central/file/tip/mailnews/base/s... I don't quite understand how we ended up in this situation. These passwords are more like user-agent strings. But they are still passwords in the sense that without any of them, you can't access (the authentication providers for) those online services.
  - dns_snek 3y ago
    Possession of OAuth Client Secrets doesn't grant you access to any private data, it's a non-issue and it's unrelated to the linked Cisco vulnerability: > A vulnerability in Cisco Emergency Responder could allow an unauthenticated, remote attacker to log in to an affected device using the root account, which has default, static credentials that cannot be changed or deleted.
    - fweimer 3y ago
      I understand these cases are structurally different. I just don't see how a quasi-ban of hardcoded passwords could work, given current industry practices. And I'm not sure these client-side secrets/group passwords are entirely meaningless. Some people somewhere must ascribe some security-related property to them.
      - jameshart 3y ago
        I think this is just a case of the APIs here supporting client ids and secrets so that users can control who uses the API on their behalf… but it being up to the API user to decide how much they care about who they share that client secret with. If Thunderbird shared their Netflix password in here, that wouldn’t say anything about the quality of Netflix’s security implementation or the security value of Netflix passwords in general - it tells you Thunderbird don’t care about how their Netflix account gets used. And in terms of the structural difference - this is of course a hardcoded credential used to identify this client to a service - the case at hand is about a hardcoded credential authentication embedded in a service, used to authenticate clients. We can distinguish those cases regulatorily.
  - mschuster91 3y ago
    > I don't quite understand how we ended up in this situation. These passwords are more like user-agent strings. But they are still passwords in the sense that without any of them, you can't access (the authentication providers for) those online services. Blame anti-cybercrime laws and weird interpretations of these for that one. The idea was that, as application level secrets (client_id/client_secret) in OAuth are scoped to a specific legal entity requesting them, site operators like Facebook, Twitter and others could request a takedown of third party apps at app stores for using the secrets of other apps.
- WesolyKubeczek 3y ago
  > root-holed crap from Lucky Good Fast Router Co. this week, then that company vanishes and Amazon sells amazingly similar crap from Good Lucky Fast Router Co. Even cheap routers start putting passwords on them that look randomized. Look, it shouldn't be that hard. One would expect that since manufacturers surely can produce unique serial numbers and MAC addresses and put them both into hardware and on the sticker on the bottom, a unique pair of credentials should be a piece of cake. Right? Right?
  - Hikikomori 3y ago
    But this was a dev account that ended up in prod, not an account you should use as it shouldn't exist. The device has a set up wizard where you set up your real account, like most Cisco products.
jacquesm 3y ago
This is really beyond stupid by now. You can't help but wonder if this is by accident or by design.
- onetimeuse92304 3y ago
  Both. Neither. It might not be an intention of the management but it surely is a consequence of their outsourcing decisions. There is a team working for Cisco who does not care for quality who decided it is a good idea to have a baked in password and who do not learn from past mistakes. The core of the problem is outsourcing your core product to people who are neither competent nor interested in the quality of the product. Every time I see any company thinking they can push their core responsibility to somebody else who's interests are not aligned, I can confidently say it is going to go downhill and fail at some point.
  - jacquesm 3y ago
    Regardless of outsourcing: you have to do at least some inbound QA and some checks on your product's firmware. Especially if you have had that exact bug before. But the paranoid part of me simply wonders whether this is so they can claim plausible deniability and 'accident' rather than malice.
    - onetimeuse92304 3y ago
      I wouldn't know if it is malice. We won't know unless somebody catches them red handed with an email to prove it. But I don't think it is malice. The engineer in me says that there are just too many eyes looking at the software and that it is just too easy for somebody to identify a password and that the consequences of it are too costly for the company. And I can think of a zillion ways to leave a backdoor that is much more difficult to detect. Of course, this does not absolve them from responsibility in any way. The core responsibility, the core product they provide is security. And not only they are showing they can't provide a secure product, they prove they simply do not learn and do not care to fix it.
    - WesolyKubeczek 3y ago
lousken 3y ago
At this point cisco should fire whoever did this. After 10 years they should have policies and software guards in place to prevent this
- ndsipa_pomu 3y ago
  Also, customers should switch away from Cisco as they clearly do not take security at all seriously.
- Qwertious 3y ago
  They'll fire the QA department they've been ignoring for 10 years, but they won't fire the CEO.
  - tialaramex 3y ago
    Yup. For example Symantec's "A tough day as leaders" blog post (of course no longer available shortly after they wrote it but it's on the various archives) is basically this formula. "Oh dear, a bad thing happened, we'll fire a junior employee but change nothing".
- rightbyte 3y ago
  Fire the guy that dug the hole he was told to dig.
  - oldbbsnickname 3y ago
    The difference between a manager, a lead engineer, an engineer, and an operator are the expectations of self-directed management.
WesolyKubeczek 3y ago
I kinda hoped, before clicking the link, to find some reasoning (compatibility blablabla, poor Cisco not having resources to make it right, etc, any reason at all, doesn't have to be a good one) behind this, but was disappointed that it's just another instance of business as usual. ("This is fine".)
- lithos 3y ago
  Field Technicians/Engineers love them. It's so much easier to use a never changing default at a new site under construction/finalization. Compared to other manufacturers that have default passwords printed on the device or something made from the serial number. When that hardware could be shoved in behind a ceiling panel somewhere (even chances of that hardware not being where it's supposed to be). _____ It's clearly not the "right answer", but it is an answer.
hulitu 3y ago
> Cisco Can't Stop Using Hard-Coded Passwords Of course they can't. CIA and NSA need access.
- stusmall 3y ago
  If they wanted to add a backdoor for feds there are better ways to do it. This is just stupid, lazy engineering. Not everything has to be some grand conspiracy.
  - hulitu 3y ago
    > This is just stupid, lazy engineering. The problem that i see is that this " stupid, lazy engineering" occurs very often at Cisco. I would have expected that they have learned from past mistakes, but at the company i work for, we also don't learn.
- abofh 3y ago
  They don't need the password to be hardcoded to get access, but a lazy CIO/CEO is much easier to find
Yizahi 3y ago
I work for a hardware vendor and their customers are basically the same as Cisco's. So here is what happened with us - we had some hardcoded root password in the equipment during early development stages. And it was also known to some of the customers support staff for debugging. Then some of our tech leads raised this issue and discussed that we had to change the root password because it was a correct thing to do and don't wait for some breach in the field. After some usual months of bureaucracy someone did the push and actually changed the password in all versions. Can you already guess what has happened next? :) The biggest customer threw a gigantic hysterical fit and practically demanded to return the old root password which they knew. We just shrugged and complied. It's not like it will be ours network which can be breached. If they want to operate insecurely, they are welcome. PS: just saying, no need to involve NSA in something that is better and more often explained by stupidity. :)
- kwanbix 3y ago
  Did you try to explain why this is a serious security issue?
  - Yizahi 3y ago
    Our lead developers tried, and they are way smarter than me). No luck, for some reason customers don't consider this a vulnerability. Even ones who take security more seriously and do some external pentesting on our equipment.
    - deadbunny 3y ago
      I've found having smart people explain things can be a detriment. Sometimes it needs to be the dumbest explanation to get people to understand.
      - posix86 3y ago
        Smart people explain things with big mental steps they deem obvious (true or not), and less smart people disagree with these steps but are unable to point the finger on them.
mschuster91 3y ago
I do get why they have hardcoded passwords in place: to save people who have misplaced their credentials (or SSO config) from having to wipe their devices and start anew, because that's what a lot of the support calls will be. What I don't get is why these passwords are baked into the firmware instead of a "split secret" scheme - basically, a user in trouble would read some sort of identifier from a label on the inside of the hardware in question to the support, who'd then use a secret on their side together with the identifier from the customer to generate the backdoor password. That way they'd avoid someone brute-forcing or leaking the backdoor password and compromising fleets of devices in the field, while still creating a paper trail of who has access to that password.
- pbhjpbhj 3y ago
  Well that sounds like a lot of work. Let's just make an advert that says we're the most secure instead!
- ok123456 3y ago
  That would require someone with physical access to the device. It's not a home network, the person responsible for fixing it could be in another country, and you could have hundreds of devices to fix.
  - mschuster91 3y ago
    A company could scan this as part of the onboarding process, and even if the network admins are in another country, in 99% of cases there's some on-site IT support staff that could read it out for you in an emergency.
    - ok123456 3y ago
      Now you have a spreadsheet of all the backdoors floating around.
      - mschuster91 3y ago
DonHopkins 3y ago
Doesn't Cisco have a Vice President Of Security In Charge Of Knowing His Ass From A Hole In The Ground who they can ask for his professional opinion of whether or not it's a brilliant idea to ship products with hard-coded passwords, before they ship products with hard-coded passwords AGAIN and AGAIN and AGAIN?
- pbhjpbhj 3y ago
  Ok, so they chat to the C-suite about what to do. The result will probably be "saying our security is flawed will make us look weak and undermine our marketing, just leave it". Then VP will either leave, because they have integrity; or stay and tell themselves they tried whilst enjoying their large financial compensation. Result, nothing changes. Market forces just don't seem to work on these things. I don't know what the answer is but putting the fate of millions of customers in the hands of one person's conscience, because of a knowledge imbalance, just doesn't seem right. I can imagine a technocracy having a licensing scheme for suppliers, where Cisco would be told, this is substandard we'll pull your license. But, that sorry if structure just seems like it would fail to corruption so easily. How do we improve standards over small, but impactful, parts of life that most politicians wouldn't understand; things that the market doesn't begin to address? Like the fable of the Dog and the Wolf, do we need to forgo some liberty to acquire the comfort of progress?
  - SAI_Peregrinus 3y ago
    Prevent disclaiming liability for security flaws, capped at the sum of the purchase price + any subscription fees paid. No risk for free (as in beer) software like most OSS, since the total price is $0, but risk for paid services & software.
nullc 3y ago
I dunno if its still the case but stratasys 3d printers used to have a hard coded root password. I had cause to crack it in order to repair something and did so with a couple gpu hours.
ok123456 3y ago
Imagine if this were found in a Huawei product. The warpigs would be calling this a "CCP Backdoor" and proof that Chinese networking products are intentionally insecure and should not be allowed on your network on one end, and calling for an all out cyberwar on the other.
- tonyedgecombe 3y ago
  Judging by history it will end up in a Huawei product. https://www.wsj.com/articles/SB10485560675556000 https://www.wsj.com/articles/SB10485560675556000
  - ok123456 3y ago
    2003. I doubt they would wholesale clone roms in 2023. A lot has changed in 20 years.
throwawaaarrgh 3y ago
Cisco is a very large company, that mostly acquires existing products and employees. They do make an effort to train new hires on their SDLC and security practices. But at the end of the day, security is up to the individual product development team. There's lots of those teams, and most of them are clueless about security. So it's honestly kind of a miracle when there isn't a big security vulnerability in any given product. I've worked for a lot of large enterprises, and they all are the same. Nothing special about Cisco or any others. Security is hard, and it does not provide a good return to invest in good security. You can stop using hardcoded passwords, but it won't make you any more money, and customers clearly aren't leaving because of them. The stock price is the only thing that matters. As long as that's safe, it's business as usual.
- jeffrallen 3y ago
  Cisco, to it's credit, does a good job of internal quality auditing, so bad behavior of these individual teams gets caught and corrected. But there is just so much bad behavior...
- JohnFen 3y ago
  > They do make an effort to train new hires on their SDLC and security practices. Cisco has security practices?
  - throwawaaarrgh 3y ago
    Not only do they have standard security practices and training programs, they have one of the industry's best known security research teams. rest of comment redacted due to too much honesty/whisky
- marcus0x62 3y ago
  Another thing to consider is how many development resources a given product/team has available. Emergency Responder is fundamentally a supporting product[0] to their PBX software. For the organizations that need it, it is something they have to have, but nobody that buys PBXes[1] picks a PBX on the basis of the security of the E911 add on package. Now, if you're a big vendor, do you give more resources to the PBX team that builds features which sells PBX customers, or the add on team used by a fraction of a percent of the worldwide PBX install base? I'm not asking what you should do, but rather what your inner MBA would do... 0 - the fundamental purposes of Emergency Responder are to a) provide enhanced location information about a caller, say the general location within a building, and b) to allow emergency responders to call back the person who placed an emergency call, even if the phone they called from does not have a directly callable phone number. It does some other things, too, but those are the "primary" features. 1 - source: sold a whole bunch of PBXes.
ang_cire 3y ago
The funny thing is that Cisco doesn't use this for support; to get remote support from them there is a user-initiated challenge-response workflow that authorizes Cisco TAC to connect to a box. Conspiracy people always gonna conspiracy though, and sometimes they're right, and whether it's an intentional backdoor or not, it is a backdoor.
gnu8 3y ago
What IS the hard coded password? TFA, Cisco, and all of the CVE databases seem to have failed to document the most important detail.
pjsg 3y ago
When I was at Cisco (over 10 years ago), one of the clauses in the PSB (Product Security Baseline) was "No default credentials". Back then, most of the issues arose in products that were produced by companies that Cisco subsequently purchased. I can't find the PSB that I was familiar with, but this is a variant that Cisco uses for Linux: https://www.cisco.com/c/dam/en_us/about/security/intelligence/Product_Security_Baseline_for_Linux.pdf https://www.cisco.com/c/dam/en_us/about/security/intelligenc... Cisco isn't perfect by any stretch of the imagination, but the corporation cares about security even if some of the individual employees don't care to the same extent.
- Salgat 3y ago
  I remember applying for Cisco 10 years ago and after registering on their site they sent me an e-mail confirmation with my password in plaintext.
stusmall 3y ago
A lot gets made of the inflation of CVSS scores but this is an interesting low ball of a score. It's a bit of a bold move to mark this one as a 9.8. If root access available to remote, unauthenticated users via the simplest means possible, unrevokable creds, isn't a perfect 10 then I don't know what is. I tried to find the mitigating factor that pushes it down that 0.2 but couldn't.
ehPReth 3y ago
What was the password?
- e12e 3y ago
  > The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability that is described in this advisory. https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cer-priv-esc-B9t3hqk9 https://sec.cloudapps.cisco.com/security/center/content/Cisc... Ed: ... But judging from this... "cisco"? https://www.lifewire.com/cisco-default-password-list-2619151 https://www.lifewire.com/cisco-default-password-list-2619151
oldbbsnickname 3y ago
Hard-coded default passwords is a non-problem. The problem is sloppy processes lacking protected networks for staging and deployment that properly configures said network gear with a unique password or TACACS+ auth.
- e12e 3y ago
  > Hard-coded default passwords is a non-problem. I humbly disagree. However, this is much worse, anyway - it's a static root password: > A vulnerability in Cisco Emergency Responder could allow an unauthenticated, remote attacker to log in to an affected device using the root account, which has default, static credentials that cannot be changed or deleted. > This vulnerability is due to the presence of static user credentials for the root account that are typically reserved for use during development. https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cer-priv-esc-B9t3hqk9 https://sec.cloudapps.cisco.com/security/center/content/Cisc...
  - oldbbsnickname 3y ago
    You're mischaracterizing what I was talking about: I was talking about the general case of a hard-reset default password that is user-configurable. I don't care about Cisco, so they can continue footgunning themselves in obviously stupid ways. It sounds like such a Cisco user should or must have an ability to be disabled. If not, that's fucking moronic. But really, what kind of morons put what should be their internal management network on the fucking internet and don't have TACACS+?
    - e12e 3y ago
      > You're mischaracterizing what I was talking about I didn't mean to imply you was talking about something else - I tried to make two separate points: 1) I don't think default passwords are "no problem" 2) This Cisco thing is anyway much worse than that. As for what you bring up: 3) But really, what kind of morons put what should be their internal management network on the fucking internet and don't have TACACS+? Indeed. Sadly 3) doesn't surprise me; it makes both 1 and 2 much worse (1 because the people that give us 3 aren't likely to change the default - even if they could - and with 2 they can't).
Dolores3012 3y ago
[flagged]

221 points by pabs3 3y ago

[Facepalm] Daydream: A new law puts legal liability for the consequences of hard-coded passwords on the manufacturers and their distribution chains. (The latter so Amazon can't sell root-holed crap from Lucky Good Fast Router Co. this week, then that company vanishes and Amazon sells amazingly similar crap from Good Lucky Fast Router Co. next week, then that company vanishes and ...)

fweimer 3y ago
Not going to happen. Most online services require applications that access them to embed hard-coded, obfuscated passwords in the binaries. That doesn't really work for open-source software, and Thunderbird's hard-coded passwords are easily viewed: https://hg.mozilla.org/comm-central/file/tip/mailnews/base/src/OAuth2Providers.jsm#l79 https://hg.mozilla.org/comm-central/file/tip/mailnews/base/s... I don't quite understand how we ended up in this situation. These passwords are more like user-agent strings. But they are still passwords in the sense that without any of them, you can't access (the authentication providers for) those online services.
- dns_snek 3y ago
  Possession of OAuth Client Secrets doesn't grant you access to any private data, it's a non-issue and it's unrelated to the linked Cisco vulnerability: > A vulnerability in Cisco Emergency Responder could allow an unauthenticated, remote attacker to log in to an affected device using the root account, which has default, static credentials that cannot be changed or deleted.
  - fweimer 3y ago
    I understand these cases are structurally different. I just don't see how a quasi-ban of hardcoded passwords could work, given current industry practices. And I'm not sure these client-side secrets/group passwords are entirely meaningless. Some people somewhere must ascribe some security-related property to them.
    - jameshart 3y ago
      I think this is just a case of the APIs here supporting client ids and secrets so that users can control who uses the API on their behalf… but it being up to the API user to decide how much they care about who they share that client secret with. If Thunderbird shared their Netflix password in here, that wouldn’t say anything about the quality of Netflix’s security implementation or the security value of Netflix passwords in general - it tells you Thunderbird don’t care about how their Netflix account gets used. And in terms of the structural difference - this is of course a hardcoded credential used to identify this client to a service - the case at hand is about a hardcoded credential authentication embedded in a service, used to authenticate clients. We can distinguish those cases regulatorily.
- mschuster91 3y ago
  > I don't quite understand how we ended up in this situation. These passwords are more like user-agent strings. But they are still passwords in the sense that without any of them, you can't access (the authentication providers for) those online services. Blame anti-cybercrime laws and weird interpretations of these for that one. The idea was that, as application level secrets (client_id/client_secret) in OAuth are scoped to a specific legal entity requesting them, site operators like Facebook, Twitter and others could request a takedown of third party apps at app stores for using the secrets of other apps.
WesolyKubeczek 3y ago
> root-holed crap from Lucky Good Fast Router Co. this week, then that company vanishes and Amazon sells amazingly similar crap from Good Lucky Fast Router Co. Even cheap routers start putting passwords on them that look randomized. Look, it shouldn't be that hard. One would expect that since manufacturers surely can produce unique serial numbers and MAC addresses and put them both into hardware and on the sticker on the bottom, a unique pair of credentials should be a piece of cake. Right? Right?
- Hikikomori 3y ago
  But this was a dev account that ended up in prod, not an account you should use as it shouldn't exist. The device has a set up wizard where you set up your real account, like most Cisco products.

jacquesm 3y ago

This is really beyond stupid by now. You can't help but wonder if this is by accident or by design.

onetimeuse92304 3y ago
Both. Neither. It might not be an intention of the management but it surely is a consequence of their outsourcing decisions. There is a team working for Cisco who does not care for quality who decided it is a good idea to have a baked in password and who do not learn from past mistakes. The core of the problem is outsourcing your core product to people who are neither competent nor interested in the quality of the product. Every time I see any company thinking they can push their core responsibility to somebody else who's interests are not aligned, I can confidently say it is going to go downhill and fail at some point.
- jacquesm 3y ago
  Regardless of outsourcing: you have to do at least some inbound QA and some checks on your product's firmware. Especially if you have had that exact bug before. But the paranoid part of me simply wonders whether this is so they can claim plausible deniability and 'accident' rather than malice.
  - onetimeuse92304 3y ago
    I wouldn't know if it is malice. We won't know unless somebody catches them red handed with an email to prove it. But I don't think it is malice. The engineer in me says that there are just too many eyes looking at the software and that it is just too easy for somebody to identify a password and that the consequences of it are too costly for the company. And I can think of a zillion ways to leave a backdoor that is much more difficult to detect. Of course, this does not absolve them from responsibility in any way. The core responsibility, the core product they provide is security. And not only they are showing they can't provide a secure product, they prove they simply do not learn and do not care to fix it.
  - WesolyKubeczek 3y ago

lousken 3y ago

At this point cisco should fire whoever did this. After 10 years they should have policies and software guards in place to prevent this

ndsipa_pomu 3y ago
Also, customers should switch away from Cisco as they clearly do not take security at all seriously.
Qwertious 3y ago
They'll fire the QA department they've been ignoring for 10 years, but they won't fire the CEO.
- tialaramex 3y ago
  Yup. For example Symantec's "A tough day as leaders" blog post (of course no longer available shortly after they wrote it but it's on the various archives) is basically this formula. "Oh dear, a bad thing happened, we'll fire a junior employee but change nothing".
rightbyte 3y ago
Fire the guy that dug the hole he was told to dig.
- oldbbsnickname 3y ago
  The difference between a manager, a lead engineer, an engineer, and an operator are the expectations of self-directed management.

WesolyKubeczek 3y ago

I kinda hoped, before clicking the link, to find some reasoning (compatibility blablabla, poor Cisco not having resources to make it right, etc, any reason at all, doesn't have to be a good one) behind this, but was disappointed that it's just another instance of business as usual. ("This is fine".)

lithos 3y ago
Field Technicians/Engineers love them. It's so much easier to use a never changing default at a new site under construction/finalization. Compared to other manufacturers that have default passwords printed on the device or something made from the serial number. When that hardware could be shoved in behind a ceiling panel somewhere (even chances of that hardware not being where it's supposed to be). _____ It's clearly not the "right answer", but it is an answer.

hulitu 3y ago

> Cisco Can't Stop Using Hard-Coded Passwords Of course they can't. CIA and NSA need access.

stusmall 3y ago
If they wanted to add a backdoor for feds there are better ways to do it. This is just stupid, lazy engineering. Not everything has to be some grand conspiracy.
- hulitu 3y ago
  > This is just stupid, lazy engineering. The problem that i see is that this " stupid, lazy engineering" occurs very often at Cisco. I would have expected that they have learned from past mistakes, but at the company i work for, we also don't learn.
abofh 3y ago
They don't need the password to be hardcoded to get access, but a lazy CIO/CEO is much easier to find

Yizahi 3y ago

I work for a hardware vendor and their customers are basically the same as Cisco's. So here is what happened with us - we had some hardcoded root password in the equipment during early development stages. And it was also known to some of the customers support staff for debugging. Then some of our tech leads raised this issue and discussed that we had to change the root password because it was a correct thing to do and don't wait for some breach in the field. After some usual months of bureaucracy someone did the push and actually changed the password in all versions. Can you already guess what has happened next? :) The biggest customer threw a gigantic hysterical fit and practically demanded to return the old root password which they knew. We just shrugged and complied. It's not like it will be ours network which can be breached. If they want to operate insecurely, they are welcome. PS: just saying, no need to involve NSA in something that is better and more often explained by stupidity. :)

kwanbix 3y ago
Did you try to explain why this is a serious security issue?
- Yizahi 3y ago
  Our lead developers tried, and they are way smarter than me). No luck, for some reason customers don't consider this a vulnerability. Even ones who take security more seriously and do some external pentesting on our equipment.
  - deadbunny 3y ago
    I've found having smart people explain things can be a detriment. Sometimes it needs to be the dumbest explanation to get people to understand.
    - posix86 3y ago
      Smart people explain things with big mental steps they deem obvious (true or not), and less smart people disagree with these steps but are unable to point the finger on them.

mschuster91 3y ago

I do get why they have hardcoded passwords in place: to save people who have misplaced their credentials (or SSO config) from having to wipe their devices and start anew, because that's what a lot of the support calls will be. What I don't get is why these passwords are baked into the firmware instead of a "split secret" scheme - basically, a user in trouble would read some sort of identifier from a label on the inside of the hardware in question to the support, who'd then use a secret on their side together with the identifier from the customer to generate the backdoor password. That way they'd avoid someone brute-forcing or leaking the backdoor password and compromising fleets of devices in the field, while still creating a paper trail of who has access to that password.

pbhjpbhj 3y ago
Well that sounds like a lot of work. Let's just make an advert that says we're the most secure instead!
ok123456 3y ago
That would require someone with physical access to the device. It's not a home network, the person responsible for fixing it could be in another country, and you could have hundreds of devices to fix.
- mschuster91 3y ago
  A company could scan this as part of the onboarding process, and even if the network admins are in another country, in 99% of cases there's some on-site IT support staff that could read it out for you in an emergency.
  - ok123456 3y ago
    Now you have a spreadsheet of all the backdoors floating around.
    - mschuster91 3y ago

DonHopkins 3y ago

Doesn't Cisco have a Vice President Of Security In Charge Of Knowing His Ass From A Hole In The Ground who they can ask for his professional opinion of whether or not it's a brilliant idea to ship products with hard-coded passwords, before they ship products with hard-coded passwords AGAIN and AGAIN and AGAIN?

pbhjpbhj 3y ago
Ok, so they chat to the C-suite about what to do. The result will probably be "saying our security is flawed will make us look weak and undermine our marketing, just leave it". Then VP will either leave, because they have integrity; or stay and tell themselves they tried whilst enjoying their large financial compensation. Result, nothing changes. Market forces just don't seem to work on these things. I don't know what the answer is but putting the fate of millions of customers in the hands of one person's conscience, because of a knowledge imbalance, just doesn't seem right. I can imagine a technocracy having a licensing scheme for suppliers, where Cisco would be told, this is substandard we'll pull your license. But, that sorry if structure just seems like it would fail to corruption so easily. How do we improve standards over small, but impactful, parts of life that most politicians wouldn't understand; things that the market doesn't begin to address? Like the fable of the Dog and the Wolf, do we need to forgo some liberty to acquire the comfort of progress?
- SAI_Peregrinus 3y ago
  Prevent disclaiming liability for security flaws, capped at the sum of the purchase price + any subscription fees paid. No risk for free (as in beer) software like most OSS, since the total price is $0, but risk for paid services & software.

nullc 3y ago

I dunno if its still the case but stratasys 3d printers used to have a hard coded root password. I had cause to crack it in order to repair something and did so with a couple gpu hours.

ok123456 3y ago

Imagine if this were found in a Huawei product. The warpigs would be calling this a "CCP Backdoor" and proof that Chinese networking products are intentionally insecure and should not be allowed on your network on one end, and calling for an all out cyberwar on the other.

tonyedgecombe 3y ago
Judging by history it will end up in a Huawei product. https://www.wsj.com/articles/SB10485560675556000 https://www.wsj.com/articles/SB10485560675556000
- ok123456 3y ago
  2003. I doubt they would wholesale clone roms in 2023. A lot has changed in 20 years.

throwawaaarrgh 3y ago

Cisco is a very large company, that mostly acquires existing products and employees. They do make an effort to train new hires on their SDLC and security practices. But at the end of the day, security is up to the individual product development team. There's lots of those teams, and most of them are clueless about security. So it's honestly kind of a miracle when there isn't a big security vulnerability in any given product. I've worked for a lot of large enterprises, and they all are the same. Nothing special about Cisco or any others. Security is hard, and it does not provide a good return to invest in good security. You can stop using hardcoded passwords, but it won't make you any more money, and customers clearly aren't leaving because of them. The stock price is the only thing that matters. As long as that's safe, it's business as usual.

jeffrallen 3y ago
Cisco, to it's credit, does a good job of internal quality auditing, so bad behavior of these individual teams gets caught and corrected. But there is just so much bad behavior...
JohnFen 3y ago
> They do make an effort to train new hires on their SDLC and security practices. Cisco has security practices?
- throwawaaarrgh 3y ago
  Not only do they have standard security practices and training programs, they have one of the industry's best known security research teams. rest of comment redacted due to too much honesty/whisky
marcus0x62 3y ago
Another thing to consider is how many development resources a given product/team has available. Emergency Responder is fundamentally a supporting product[0] to their PBX software. For the organizations that need it, it is something they have to have, but nobody that buys PBXes[1] picks a PBX on the basis of the security of the E911 add on package. Now, if you're a big vendor, do you give more resources to the PBX team that builds features which sells PBX customers, or the add on team used by a fraction of a percent of the worldwide PBX install base? I'm not asking what you should do, but rather what your inner MBA would do... 0 - the fundamental purposes of Emergency Responder are to a) provide enhanced location information about a caller, say the general location within a building, and b) to allow emergency responders to call back the person who placed an emergency call, even if the phone they called from does not have a directly callable phone number. It does some other things, too, but those are the "primary" features. 1 - source: sold a whole bunch of PBXes.

ang_cire 3y ago

The funny thing is that Cisco doesn't use this for support; to get remote support from them there is a user-initiated challenge-response workflow that authorizes Cisco TAC to connect to a box. Conspiracy people always gonna conspiracy though, and sometimes they're right, and whether it's an intentional backdoor or not, it is a backdoor.

gnu8 3y ago

What IS the hard coded password? TFA, Cisco, and all of the CVE databases seem to have failed to document the most important detail.

pjsg 3y ago

When I was at Cisco (over 10 years ago), one of the clauses in the PSB (Product Security Baseline) was "No default credentials". Back then, most of the issues arose in products that were produced by companies that Cisco subsequently purchased. I can't find the PSB that I was familiar with, but this is a variant that Cisco uses for Linux: https://www.cisco.com/c/dam/en_us/about/security/intelligence/Product_Security_Baseline_for_Linux.pdf https://www.cisco.com/c/dam/en_us/about/security/intelligenc... Cisco isn't perfect by any stretch of the imagination, but the corporation cares about security even if some of the individual employees don't care to the same extent.

Salgat 3y ago
I remember applying for Cisco 10 years ago and after registering on their site they sent me an e-mail confirmation with my password in plaintext.

stusmall 3y ago

A lot gets made of the inflation of CVSS scores but this is an interesting low ball of a score. It's a bit of a bold move to mark this one as a 9.8. If root access available to remote, unauthenticated users via the simplest means possible, unrevokable creds, isn't a perfect 10 then I don't know what is. I tried to find the mitigating factor that pushes it down that 0.2 but couldn't.

ehPReth 3y ago

What was the password?

e12e 3y ago
> The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability that is described in this advisory. https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cer-priv-esc-B9t3hqk9 https://sec.cloudapps.cisco.com/security/center/content/Cisc... Ed: ... But judging from this... "cisco"? https://www.lifewire.com/cisco-default-password-list-2619151 https://www.lifewire.com/cisco-default-password-list-2619151

oldbbsnickname 3y ago

Hard-coded default passwords is a non-problem. The problem is sloppy processes lacking protected networks for staging and deployment that properly configures said network gear with a unique password or TACACS+ auth.

e12e 3y ago
> Hard-coded default passwords is a non-problem. I humbly disagree. However, this is much worse, anyway - it's a static root password: > A vulnerability in Cisco Emergency Responder could allow an unauthenticated, remote attacker to log in to an affected device using the root account, which has default, static credentials that cannot be changed or deleted. > This vulnerability is due to the presence of static user credentials for the root account that are typically reserved for use during development. https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-cer-priv-esc-B9t3hqk9 https://sec.cloudapps.cisco.com/security/center/content/Cisc...
- oldbbsnickname 3y ago
  You're mischaracterizing what I was talking about: I was talking about the general case of a hard-reset default password that is user-configurable. I don't care about Cisco, so they can continue footgunning themselves in obviously stupid ways. It sounds like such a Cisco user should or must have an ability to be disabled. If not, that's fucking moronic. But really, what kind of morons put what should be their internal management network on the fucking internet and don't have TACACS+?
  - e12e 3y ago
    > You're mischaracterizing what I was talking about I didn't mean to imply you was talking about something else - I tried to make two separate points: 1) I don't think default passwords are "no problem" 2) This Cisco thing is anyway much worse than that. As for what you bring up: 3) But really, what kind of morons put what should be their internal management network on the fucking internet and don't have TACACS+? Indeed. Sadly 3) doesn't surprise me; it makes both 1 and 2 much worse (1 because the people that give us 3 aren't likely to change the default - even if they could - and with 2 they can't).

Dolores3012 3y ago

[flagged]