Four SSH Vulnerabilities You Should Not Ignore

The Secure Shell (SSH) protocol was created in 1995 by a researcher from the University of Helsinki after a password-sniffing attack. SSH is the tool of choice for system admins and is used throughout traditional and virtual datacenter environments to enable secure remote access to Unix, Linux and sometimes Windows systems. You can think of the SSH key, which enables this remote access, as a “Swiss Army Knife” for IT teams in that it helps administrators and developers authenticate to systems, build authentication into systems and applications and encrypt the resulting traffic between its users and systems.

During the authentication process, these SSH keys often establish direct, privileged or root access to a variety of critical systems, effectively turning these cryptographic assets into privileged credentials. SSH keys are granted the same access as passwords, but when most people think about securing their privileged credentials, they forget about SSH keys. As a result, these keys can easily fall into the wrong hands and, instead of protecting access to important assets, these keys can become “virtual skeleton keys.” To make matters worse, when an attacker gains access to one privileged SSH key, she or he can access every SSH key stored on that machine and spider the entire company network, often gaining access to all company data. As few as five to 20 unique SSH keys can grant access to an entire enterprise through transitive SSH key trust, providing attackers with privileged access to the organization’s most sensitive systems and data.

Four SSH vulnerabilities you should not ignore:

1.  SSH Key Tracking Troubles. It’s not uncommon for a typical large enterprise with 10,000+ servers to have more than one million SSH keys – making it incredibly difficult, if not impossible, to find and manage each key. Organizations typically accumulate large numbers of SSH keys because end users can create new SSH keys (credentials) or even duplicate them without oversight, unlike certificates or passwords. Once a large number of SSH keys are built up over time, an organization could, for example, easily lose track of these credentials when development servers are migrated into production environments (assuming the development environment credentials are not scrubbed) or when employees leave the company and their keys are not changed. The result? SSH keys left unaccounted for can provide attackers with long-term privileged access to corporate resources. If attackers gain access to a key that is never revoked or rotated, the attackers could have a permanent network entry point and impersonate the user that the SSH key originally belonged to.
2.  When it Comes to SSH Keys, Sharing Isn’t Caring. For the sake of efficiency, SSH keys are often shared or replicated across a common group of employees or servers and infrastructure components. As noted above, as a result of SSH key duplication, as few as five to 20 unique keys can grant access to all machines throughout an enterprise. This approach may make IT teams’ jobs easier in the short-term, but it also makes attackers’ lives easier in the long-term. SSH key duplication creates complicated, many-to-many private public key mappings that significantly reduce security because it is difficult to rotate and revoke a single key without breaking untold other SSH key relationships that share the same key fingerprint. SSH key sharing is also dangerous because it reduces auditability and nonrepudiation.
3. Static SSH Keys, Because “Ain’t Nobody Got Time for Rotation!” It’s easy to see how rotating one million plus SSH keys would be a logistical nightmare. Many IT administrators and security professionals rarely change and re-distribute keys for fear that a critical component or employee may be forgotten (which could mean anything from a simple inconvenience for a single employee to a major company-wide system outage). These factors typically result in a surge of static SSH keys, opening the door for attackers to compromise an unchanged key, use it to move laterally through the enterprise and gain permanent, unauthorized access to sensitive data and assets.
4. Embedded SSH Keys – The Ones No One Wants to Mess With. SSH keys are frequently embedded within applications or scripts. Administrators are often fearful of changing them as they do not understand the code the keys are embedded in or are strongly discouraged from rotating them because of the level of coordination required to prevent system outages. As a result, static SSH keys embedded in applications, code and scripts can lead to persistent backdoors for attackers.

SSH keys can present a tremendous opportunity for hackers to gain privileged access to networks, stay connected, impersonate legitimate users, hide their activity with encryption and move freely. To learn about SSH key challenges and best practices for mitigating associated risks while improving your overall security posture, visit our website. And to learn more about our comprehensive secrets management tool to help secure SSH keys, credentials and other secrets used by applications and machines, check out this blog post.

Editor’s Note: This article has been updated. It was originally published April, 2016.