Secure Shell (SSH) is a network protocol that establishes a cryptographically secure connection between two parties. As such, it plays a crucial role in protecting information those parties exchange. But the network protocol isn't foolproof.
Unlike other security tools, SSH machine identities generally aren’t centrally managed. Instead, SSH is most often managed by individual administrators for the servers they control. Consequently, most organizations don’t have a central view or one way of controlling the configuration of SSH or the access it provides. Because of this lack of central oversight, administrators are left to their own devices, which results in significant security risks.
If organizations mismanage their SSH keys, they could expose themselves to significant digital security risks. That's especially the case if they have lots of untracked persistent SSH trust relationships in their encryption environments.
Here are four big risks of weak SSH key management that your organization should have on its radar.
1. Unauthorized Access
Bad actors could abuse unprotected SSH keys to gain unauthorized access to privileged accounts. For instance, if an organization keeps default SSH configurations, that means users can manage their own authorized SSH keys. An attacker could exploit this setting by compromising a privileged user and setting up a backdoor key. Alternatively, they could leverage poorly protected private keys to gain illegitimate access to sensitive business accounts. Both external actors and malicious insiders could accomplish these methods of intrusion. In addition, if the organization doesn't properly monitor its SSH keys, terminated employees could retain access to sensitive business information long after they walk out the door.
2. Lateral Movement
After attackers gain an initial entry into your network, their next goal is typically to get onto other systems, which is called lateral movement. When cybercriminals’ jump from system to system, they can easily pivot on your network by abusing persistent SSH trust relationships to their advantage. That’s especially the case if administrators don’t review those keys often or maintain strong oversight over them.
3. Circumvent Security Controls
While they're busy pivoting, attackers could come across firewalls and other security technologies designed to block malicious network activity. Unfortunately, if companies don't properly control their SSH environment, they could potentially bypass these safeguards by configuring SSH for port forwarding. Doing so would allow the attackers to communicate with other systems that leverage authorized connections via firewalls and thereby find an alternate yet nonetheless "approved" route through the network.
4. Unauthorized Use of SSH Server
Organizations need to be careful when activating an SSH server, as these types of assets enable remote login. Attackers could abuse this facet in a poorly controlled SSH environment using free implementations like OpenSSH to surreptitiously enable SSH on critical assets. With SSH set up, attackers could then gain remote access to an asset and thereafter do whatever they want with it.
The Importance of SSH Controls
To defend against the threats described above, it's imperative that organizations properly manage and configure their SSH environments. Policies and procedures play a critical role in SSH security by establishing consistent baseline requirements across the diverse systems and environments where SSH keys are deployed. Your policies should clearly spell out roles and responsibilities in order to prevent misunderstandings that result in security lapses and to ensure accountability. When you leave compliance in the hands of the various administrators who manage SSH keys for the systems they control, you’ll see inconsistent results for policy enforcement. That’s why it’s critical that you educate all SSH stakeholders on SSH security policies and processes—and have automation. Learn more about SSH key management here.
(This post has been updated. It was originally published by David Bisson on November 7, 2017.)
Related posts
