Many Cisco security appliances contain default, authorized SSH keys that can allow an attacker to connect to an appliance and take almost any action he chooses. The company said all of its Web Security Virtual Appliances, Email Security Virtual Appliances, and Content Security Management Virtual Appliances are affected by the vulnerability.
This bug is about as serious as they come for enterprises. An attacker who is able to discover the default SSH key would have virtually free reign on vulnerable boxes, which, given Cisco's market share and presence in the enterprise worldwide, is likely a high number. Threatpost.com writes that the default key was inserted into the software for support reasons.
Cisco says, "The vulnerability is due to the presence of a default authorized SSH key that is shared across all the installations of WSAv, ESAv, and SMAv. An attacker could exploit this vulnerability by obtaining the SSH private key and using it to connect to any WSAv, ESAv, or SMAv. An exploit could allow the attacker to access the system with the privileges of the root user."
(Score: 4, Insightful) by draconx on Saturday June 27 2015, @05:07PM
It is not clear at all what the actual problem is from the article.
There are, of course, two keypairs used in ssh public key authentication:
I imagine the issue is one of the following:
(Score: 1, Informative) by Anonymous Coward on Saturday June 27 2015, @06:02PM
More likely a public key stuffed into /root/.ssh/authorized_keys.
This is, as another commenter stated, a back-door for Cisco / anybody else with access to the corresponding private key.
(Score: 3, Interesting) by frojack on Saturday June 27 2015, @06:44PM
anybody else with access to the corresponding private key.
And that suggests a breach at cisco, or someone reverse-engineered the private key.
TFA is giving us only PART of the story here. The part Cisco has omitted is the interesting part.
No, you are mistaken. I've always had this sig.
(Score: 3, Interesting) by frojack on Saturday June 27 2015, @06:37PM
Actually there are not two keypairs.
All you need is one keypair, your private key, and your public key. Push your public key into authorized_keys on the root account, and you are in. You don't need to know a thing about the server's own keypair. I'm betting Intel did exactly that, pushed the same public key into authorized_keys on each device.
I suspect this became a problem because ONLY the private key matching that public key installed on each device, has been leaked, stolen, or reverse engineered, probably by the US government or the Chinese.
No, you are mistaken. I've always had this sig.
(Score: 0) by Anonymous Coward on Saturday June 27 2015, @09:13PM
Except with cisco systems you still need to have local login credentials to do anything meaningful. It isn't a generic linux box and has not been for two decades.
(Score: 2) by FatPhil on Sunday June 28 2015, @10:27AM
Citation please - which sentence says that? Sentences not containing the adjective "private", or a synonymous adjectival phrase, in the context of key material will not be considered as supporting your assertion. Likewise, sentences not asserting that an attacker actually can obtain private key material will be rejected.
However, I agree it's a bloody-awfully-written article (specifically because it does not distinguish between private and public key material).
Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves