Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Saturday June 27 2015, @02:19PM   Printer-friendly
from the "security"-appliance dept.

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


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 4, Insightful) by draconx on Saturday June 27 2015, @05:07PM

    by draconx (4649) on Saturday June 27 2015, @05:07PM (#202132)

    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:

    • The host keypair, used by the client to authenticate the server.
    • The client keypair, used by the server to authenticate the client.

    I imagine the issue is one of the following:

    • The same host keypair is used across devices, and is available in the firmware image. This means that someone could obtain the private key from their own device and then successfully man-in-the-middle future, authorized connections to different devices. That's bad, but the article says that an attacker could use the private key to authenticate as the root user, which isn't normally possible with the host key, so...
    • All devices have some client public key authorized for root logins. This means that someone (probably some Cisco developer) with the corresponding private key could log in as the root user. That's bad, but the article says that an attacker can obtain the private key from the firmware, which isn't normally possible for the client key, so...
    Starting Score:    1  point
    Moderation   +2  
       Insightful=1, Interesting=1, Total=2
    Extra 'Insightful' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   4  
  • (Score: 1, Informative) by Anonymous Coward on Saturday June 27 2015, @06:02PM

    by Anonymous Coward on Saturday June 27 2015, @06:02PM (#202165)

    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

      by frojack (1554) on Saturday June 27 2015, @06:44PM (#202178) Journal

      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

    by frojack (1554) on Saturday June 27 2015, @06:37PM (#202176) Journal

    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

      by Anonymous Coward on Saturday June 27 2015, @09:13PM (#202223)

      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

    by FatPhil (863) <{pc-soylent} {at} {asdf.fi}> on Sunday June 28 2015, @10:27AM (#202389) Homepage
    > but the article says that an attacker can obtain the private key from the firmware

    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