Before 2013, the average person rarely thought about encryption. But that changed when Edward Snowden breached the National Security Agency (NSA) and disclosed information about PRISM. Since then, a series of events have helped keep encryption at the forefront of everyone’s minds. Most recently, WikiLeaks published a new document in its “Vault 7” data leak series involving the CIA. This new file contained information on “BothanSpy” and “Gyrfalcon,” two hacking tools which enable someone to steal a target’s SSH keys.
Adversaries and insiders have long known how to abuse the trust established by keys and certificates and use them as the next attack vector. Acknowledging that fact, I decided to work with Dimensional Research to understand how organizations were managing and implementing Secure Shell (SSH) in their environments. The researchcovered the responses of 411 security professionals with knowledge of SSH from the United States the United Kingdom and Germany.
What was very evident from the research was the fact that most organizations were inadequately prepared for or incapable of detecting a security incident related to the compromise or misuse of SSH keys. We break down these chilling results below.
A lack of visibility
A majority of organizations don’t have adequate visibility into their SSH keys. Significantly, 90 percent of security professionals surveyed by Venafi said that they lacked a complete and accurate inventory of all SSH keys. As a result, they had no means to determine whether someone had stolen or misused their organization’s keys.
The more SSH admins, the scarier!
The issue of key misuse doesn’t relate to only external attackers. Malicious insiders also constitute a threat if they have the ability to configure authorized SSH keys. Organizations can mitigate this risk by creating policies that prohibit such behavior. But according to survey participants, just 35 percent of organizations actually enforce these policies. 61% of respondents said that their organization doesn’t even limit or monitor the number of administrators who are authorized to manage SSH.
Unlimited opportunities in how SSH keys are used
As most organizations fail to clarify who can manage their SSH keys, it’s no surprise that many also fail to stipulate how their SSH keys can be used. For instance, nearly half of respondents said that their organization doesn’t restrict port forwarding for SSH, limit the locations where SSH can be used or remove SSH keys when a user leaves the company at 48 percent, 49 percent and 42 percent, respectively. These oversights make it possible for someone to abuse SSH in order to evade other security mechanisms.
A never-ending nightmare
As the research suggests, organizations have limited visibility into how SSH keys are used in the enterprise network and no ability to apply policies to SSH keys. However, you would think that even organizations using manual, disparate SSH key management would provide guidelines for rotating SSH keys. After all, SSH keys have no expiration date.
Unfortunately, that’s not the case. Seventy-percent of survey respondents said that their organization does not rotate SSH keys regularly. This opens the possibility for an SSH key leak, such as what happened in a security incidentagainst FreeBSD’s infrastructure back in 2012.
Considering that SSH bypasses host-based controls and provides elevated privileges, every organization should make rotating keys a priority. Every organization needs to stop viewing SSH keys and the management thereof as an operational matter that can be resolved with a few simple discovery scripts or relying on individual application administrators to self-govern. You wouldn’t do that with domain credentials, so why treat SSH keys—which enable elevated root privilege—any differently?
Every organization needs to have central visibility into the entire SSH key inventory, understand how SSH keys are used on the enterprise network and apply SSH policies. Only then will an organization be able to quickly detect security incidents related to SSH and immediately remediate them.
(This post has been updated. It was originally posted by Gavin Hill on February 26, 2016.)