Lax Secure Shell Key Management Endangers Enterprise Networks - Page 2

Secure Shell protocol inventor warns that uncontrolled SSH credentials could cause major security incidents, gives best practices for mitigating the risks.

 By Jude Chao
Page 2 of 3   |  Back to Page 1
Print Article

Vulnerabilities already discovered: F5 Networks and the U.S. emergency broadcast system

The risks Ylönen discussed aren't theoretical. SSH vulnerabilities have already come to light. In June of 2012, an SSH vulnerability was discovered in a number of F5 Networks platforms, among them fifteen BIG-IP models and the BIG-IP Virtual Edition. The vulnerability arose from a configuration error that made a private SSH key public; exploiting it would allow remote users to log in with root access on the affected systems. "Neither a strong password nor remote authentication helps mitigate the issue," F5 declared in its security advisory.

More recently, a compromised SSH key appeared in Monroe Electronics products used to broadcast Emergency Alert System messages (EAS). The key granted root access to the devices affected. Exploiting the vulnerability could have compromised the U.S. EAS's "availability, integrity, and confidentiality," according to a Monroe Electronics security advisory.

Best practices for getting a handle on your enterprise's SSH credentials

Alarmingly, most organizations simply don't have control over all those credentials. Most have no idea how many automated keys they have that allow access to their production environments. They don't know who has access to the keys, and they certainly don't know who can access their most business-critical systems and data, according to Ylönen. Large financial institutions and enterprises may have hundreds of thousands of uncontrolled SSH keys on their hands. And, he said, "You can't just remove the keys, because some of them may be critical for running the business."

So what can organizations do to take control of their keys?

SSH Communications does provide tools to mitigate the risks of automated SSH keys: Universal SSH Key Manager for enterprises, and SSH Risk Assessor for security and compliance auditors. He stressed that organizations will still have "a lot of manual work to do," however.

Organizations must first get the creation of new SSH keys under control with a standardized provisioning process. "You wouldn't give people user accounts on your servers without filling in certain paperwork and providing proper reasons for granting access. The same needs to apply for key-based access," he said.

Next, Ylönen advised a full examination of all an organization's keys to understand which of the keys are actually in use. With that understanding, administrators can then delete the keys that are no longer needed and "justify, document, and audit" the remaining keys, he said. Documentation and auditing are particularly vital "so that if a hacker installs a new key as a back door, we immediately detect it," Ylönen explained.

From there, "organizations need to configure restrictions on what can be done with their keys," he said. Keys often provide unlimited privileges and can get command line access to critical systems. To mitigate the risks that that incurs, Ylönen advised that "access needs to be restricted so that a given key can only run a single, pre-specified command within a machine, so that you cannot use it to spread an attack."

Next page: What regulators are doing, and the role of the PCI Council

This article was originally published on Sep 25, 2013
Get the Latest Scoop with Networking Update Newsletter