Cisco Nexus 9000 Switches Allow SSH As Root
nvd.nist.gov
nvd.nist.gov
Cisco model numbers are fun.
Meanwhile, the router that serves my office is from a company that's had fewer than nine security problems in the past ten years. Two, I think, but I confess I don't really keep count (ditto the nine above). The precise number doesn't matter, because
1. If you want to be cynic you can point out that 9>0 and 2>0 and really they all suck.
2. And if you don't want to be cynic, then Cisco's recent record is in a league of its own. Steals the show. Makes other people's CVE count look like rounding errors.
We are moving offices, and it's time to change equipment, Been reading about but still haven't gotten a good list.
The only thing i found is great micro tick for wifi routing/AP's
All of those will give you hardware that does the job and stays up, and provide uncomplicated upgrades for many years.
Also the 9th they have fixed.
> Not ninth security problem total, ninth backdoor. The ninth security problem Cisco shipped intentionally.
How can you be sure it was intentional?
> Meanwhile, the router that serves my office is from a company that's had fewer than nine security problems in the past ten years.
How can you be sure? Did you audit all the source code yourself? Did you compile the source code yourself and are you running only binaries you compiled? Are you sure you can trust the compiler you used?
Or, are you assuming that, because there isn't a CVE, there isn't a vulnerability or security problem?
Fewer CVEs doesn't necessarily mean more secure, it may just mean less validation/testing etc.
But sure, it could mean more secure, it's just not a guarantee.
I've worked for a company that built OS images for distribution to customers. Putting my SSH key in development image builds would have been convenient, but there was too much of a risk of exactly this problem; instead we just made it easy enough to download an SSH key on a development build (and start up an sshd) once you've booted it and have physical access to a terminal.
Also, a practical concern with disclosed vulnerabilities is that non-nation-state attackers (which are most of the attackers most people care about) are very unlikely to find and exploit a vulnerability that neither has a public CVE issued now nor will have one issued for years. So even if the alternative vendor has difficult-to-discover vulnerabilities, there is, in a very real sense, reduced exposure from those vulnerabilities compared to things that are disclosed and fixed. And especially if Cisco's disclosed-and-fixed vulnerabilities originate from outside vulnerability reports, there's a definite correlation between whether a vulnerability can be found by someone who would report it and whether a vulnerability can be found by someone who would exploit it.
Backdoors are unusual: They happen because someone writes code of the form addAccount("s3kr3e", "s3kr3t"), and that's code that's written. You can typo and accidentally omit a bounds check, but you can't typo and accidentally end up with a valid SSH key pair and code that installs it.
It's possible to ship that SSH key pair and the code to customers that as a bug, e.g. if someone writes that code on purpose, intending to add and deploy s3kr3t/s3kr3t but not intending to ever have that code on the branch that's deployed to regular customers, and then someone else mismerged. In that case serving it to customer X is due to a bug, it should only have gone to customer Y or test environment Z. What I'm saying is that shipping those backdoors at all must have been intentional.
(Personally I think shipping backdoors to test environments is fine. Including test environments at customers. Risky.)
> Backdoors are unusual: They happen because someone writes code of the form addAccount("s3kr3e", "s3kr3t"), and that's code that's written. You can typo and accidentally omit a bounds check, but you can't typo and accidentally end up with a valid SSH key pair and code that installs it.
Not sure if you're intentionally trolling but a backdoor is simply some code which bypasses security that a particular person knows about. It does not have to be obvious. The ones that have plausible deniability are the better ones as that is considered a feature. That way the company can say "oops, we made a mistake".
To say that a backdoor must be obvious is absolute nonsense particularly for closed sourced binaries where disassembly and using simple tools like https://en.wikipedia.org/wiki/Strings_(Unix) would reveal the presence of such backdoor.
> (Personally I think shipping backdoors to test environments is fine. Including test environments at customers. Risky.)
It depends. Unless that "test build" specifically has an option that disables all "test related backdoors" then the answer is no. You cannot risk having something slip through to a production build.
As the previous poster said:
> I've worked for a company that built OS images for distribution to customers. Putting my SSH key in development image builds would have been convenient, but there was too much of a risk of exactly this problem; instead we just made it easy enough to download an SSH key on a development build (and start up an sshd) once you've booted it and have physical access to a terminal.
Another very common solution would be a template where at build time the keys are generated/imported by whatever build system is being used.
That way if something unintended happens or is "forgotten about", the build simply won't have a key at all and therefore will not work, rather than having a set of keys that are the same across all production builds.
> Cisco Nexus 9000 Switches Allow SSH As Root
Also, link to Cisco's own advisory: https://tools.cisco.com/security/center/content/CiscoSecurit...
The right title is something like: CVS-2019-1804: Cisco Nexus 9000 Switches Allow SSH As Root.
It’s “allow ssh as root with a publicly available ssh key”. Your version is making it sound mundane.
I'm hypothesizing that you might do this, even with keys intended to be used as a back door, by shipping it on devices, you vastly increase the number of potential suspects for any backdoor abuse.
Continuing this train of thought - a hardcoded password is classic example of a backdoor, and just as "public" as including a private key.
Which makes it even more likely to be explained by stupidity as to malice.
Backdoor definition: "A backdoor is a method, often secret, of bypassing normal authentication in a computer system."
That someone might not be the company, it might be a developer.
It's entirely true that the company says it's not a backdoor, the developer says it's a mistake, but he/she was approached from an external organization.
Unless you can provide either way it's impossible to classify it as a backdoor or not.
And considering you can never know if someone else knows about it, that means you can never know if it was a backdoor.
And my response to the OP was to push back on the idea that only "idiots" could make mistakes. To me that is an absurdly reductionist view of human nature.
That is not the same thing as "Just stop communicating" or "shut up". I shouldn't have been so terse. Without the verbal cues you made a different assumption about what I was trying to say.
I never used the term idiots, that's you putting someone else's words in my mouth.
It's hard for me to imagine how a person can make a mistake in a given domain without being at least bit incompetent in it, hence my point about competence/incompetence existing on a continuum.
Edit: ...and if the person were malicious, it wouldn't be a mistake to begin with.
We'll just have to agree to disagree regarding human nature.
Mistakes aren't always made due to incompetency and extremely competent people still can make mistakes.
I think most of the "seven factors that lead to stupidity" could still affect someone very competent: https://fs.blog/2019/01/how-not-to-be-stupid/
> CVS-2019-1804: Cisco Nexus 9000 remote root exploit via SSH-over-IPv6
(Yes, it's a backdoor, I ran out of time sorry)
I'll spin this around though: What would a high-quality plausibly deniable backdoor look like to you?
At least that's my reading.
This of course says nothing about whether its inclusion was due to intent, incompetence, and/or malice. (If the private key includes “Comment: hack the planet” then yeah it’s malice :)
If Cisco had some SecretFBIChinaBackdoor() function somewhere the backlash would be way way worse (or at least an unknown). Whereas at this point it's abundantly clear that serious "non intentional" security vulnerabilities in networking hardware basically go ignored by the market.
Maybe, but without proof it's still just speculation. Real bugs do occur often, and sometimes in sensitive areas.
I understand wanting to be vigilant. In both assuming malice and assuming human error though, you're still forced to make an assumption.
Indeed. That's what I was trying to say.
At the same time, your suggested "right title" doesn't seem too accurate either (imo).
When I see the term backdoor, I think of something done intentionally.
Maybe something like: Embeded unsecured credentials , allow attacker remote root ssh access
( it's actually much harder than I initially thought , to phrase)
Submitted title was "Backdoor Found in Cisco Routers CVE-2019-1804".
That sounds like they just erroneously left AllowRootLogins yes in the ssd_config, which would not be a critical vulnerability.
You shouldn't be able to use this to connect at all, but apparently works over IPv6.
So you'd have to have the private key, as well as knowing the IPv6 address of the device you're connecting to, and that device would have to have a route to the internet or a location you could connect to it from.
There is one bright side to otherwise disgraceful incidents: All the customers running older versions are now forced to upgrade to the latest versions. The burden of supporting really old versions suddenly vanishes.
Box vendors should really stop selling unmanaged boxes/solutions. In reality, customers end up buying service contracts anyway along with boxes. Instead, sell usage/service/connectivity and manage the hardware. A critical patch like this one could then be applied before a PSIRT is released. Frequent upgrades(security patches or feature/bug fix patches) are now commonplace. The user experience would be so much better if the solution were managed by the vendor (cloud managed).
Also, given the number and severity of these sort of vulnerabilities in recent times, do you want to give the same companies remote access to your infrastructure as well? :)
Users should no longer be allowed to own their own hardware? That'll be popular with both the hacker crowd and the high-security people.
What of devices that are never intended to be connected to the wider internet?
Pros of open sourcing a product:
- fewer total number of vulnerabilities
Cons of open sourcing a product:
- more publicly-known vulnerabilities
- less effort required to find new vulnerabilities
The product might be more objectively secure, with more bug reports and more fixes.
But it will be less practically secure. There will be more known vulnerabilities, and many customers can't upgrade, leaving more total vulnerable customers. And worse, now anyone on the internet can try and find new vulnerabilities for $0, while before they'd need to buy a $1,000+ piece of hardware to even get a shot at the compiled code.
The real defense against this problem is security auditing. Security engineers try to hack the device while asking a bunch of questions about SSH connections and private keys. This is the technique most companies employ, often combined with bug bounties.
Auditor: "Big surprise. We once again recommend that you use a build system. Question 2. ..."
* Edit * Plus the Nexus the backdoor is only relevant if the switch in using ACI, and not standalone NX-OS mode. ACI training is a 5 day course for advanced engineers. https://www.cisco.com/c/en/us/training-events/training-certi...
Also western governments: Cisco will remedy their errors
Cisco: Hold my beer
Neither... it's nothing but hegemony with the pretext of both.
This is a true backdoor, not some silly telnet left on.