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 that 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 rein on vulnerable boxes, which, given Cisco’s market share and presence in the enterprise worldwide, is likely a high number. The default key apparently was inserted into the software for support reasons.

“A vulnerability in the remote support functionality of Cisco WSAv, Cisco ESAv, and Cisco SMAv Software could allow an unauthenticated, remote attacker to connect to the affected system with the privileges of the root user,” Cisco’s advisory 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.”

Security researchers say the Cisco bug unfortunately isn’t unique, and that it is illustrative of a larger industry issue.

“As most firmware vendors recognize that telnet-based remote administration is a Bad Idea, secure shell (SSH) based administration consoles are becoming more common. Unfortunately, occasionally these vendors mistakenly ship a single default SSH key across an entire product line. While it’s better than telnet, all it takes for an attacker to compromise these devices is to get a hold of one of them (or an Internet mirror of the firmware), extract the key, and then go to town,” said Tod Beardsley, security engineering manager at Rapid7.

“As we come across devices like this, we recommend that vendors instead have a ‘first boot’ procedure that dynamically generates a unique SSH key for that device. That way, the keys are distinct per customer, and not shared among all customers and whomever else gets a hold of the key. Note that usually, these devices don’t have administration ports open to the Internet, so attackers usually need to be on the local network (either physically or on a VPN that also has access to the Cisco gear at issue).

“There are several Metasploit modules available for vulnerabilities like this from a variety of vendors, since once you have the key, the Metasploit module is dead easy to write.”

Beardsley said Rapid7 is building a library of known bad SSH keys, and that he’d expect to see Cisco’s key in there soon.

The vulnerability would give an attacker essentially undetected access to a target system and Cisco said that exploiting the bug is simple, especially if an attacker has a man-in-the-middle position on a target network.

“Exploiting this vulnerability on Cisco SMAv is possible in all cases in which SMAv is used to manage any content security appliance. Successfully exploiting this vulnerability on Cisco SMAv allows an attacker to decrypt communication toward SMAv, impersonate SMAv, and send altered data to a configured content appliance. An attacker can exploit this vulnerability on a communication link toward any content security appliance that was ever managed by any SMAv,” the advisory says.

Cisco says there is no workaround for the vulnerability, but it has released patches for all of the affected software versions. The company said the vulnerability was discovered during internal security testing. The vulnerable appliances provide a variety of security functionality, including content, email, and Web security.

Categories: Vulnerabilities, Web Security

Comments (6)

  1. Ben
    3

    I am confused about the use of the term “SSH key” in this article. What I am used to is that this refers to an asymmetric crypto public key is installed on the server using an algorithm like RSA or Diffie-Hellman. Access to the public key should not provide access to the private key (which should only be available at the SSH client or in the case Cisco tech support).

    So, I am having trouble with the following claim:
    “all it takes for an attacker to compromise these devices is to get a hold of one of them (or an Internet mirror of the firmware), extract the key, and then go to town.”

    Are you saying the *private* key is also stored in the firmware?!

    • a robot
      4

      I’m with Ben on this one.
      If only the public key is stored on the machine, someone would have to get the private key from Cisco.
      It’s still static, so once it’s stolen, it’s open forever, but until then, I don’t see how anyone would get in this way.

  2. KR
    5

    @Ben: The device needs the private key to decode encrypted data it is sent, so it is stored on the device. It’s not part of the firmware necessarily, it probably has its own memory somewhere, but I don’t know how the guts of these devices work.

    The issue from my understanding is that the PRIVATE keys for the SSH/Diffe-Hellman/RSA/whatever are a default value, and since everyone knows the public keys already the attacker can access the system and log into it. If you have ever been inside a cysco firmware, you can change logon passwords, monitor traffic, etc., which could be a serious security breach.

    Now for the SSH logon protocol, there should be a password as well, but the attacker can just monitor traffic and he will be able to read the password by eavesdropping on a login. Then he owns the system, can reconfigure their networks, disable any firewalls on the device, etc.

    I hope this was helpful,
    -KR

    • Ace
      6

      @KR …
      I think you are completely confused about how public/private key pairs work.

Comments are closed.