In my last blog, I talked a bit about where SSH (Secure Shell) is used and provided an overview of the basic components of SSH and how they operate. As I discussed before, SSH is a powerful security tool, protecting privileged access to mission critical systems. However, when it is not properly managed, it can become a security liability instead of asset. My goal is to help you understand the underlying challenges of securing SSH. In this blog, I’ll summarize some of the risks related to SSH, so when we move on to talking about best practices in my next blog entry, you’ll know why they’re needed.
Secure Your SSH Machine Identities With SSH Protect
Why worry about SSH security?
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.
The diagram below provides a summary of SSH security risks. As you can see, the risks span the SSH server and client, with most arising on the server-side.
Common SSH security risks
Unapproved SSH servers
You need to be particularly careful when activating an SSH server because 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. If you have users and administrators enabling SSH server access on systems where it isn’t required, you’re expanding your attack surface because attackers will have a greater possibility of remotely gaining access to those systems.
Unpatched SSH software
For the systems where SSH use is justified, if SSH server and client software is not kept up to date with fixes and updates, it can expose the systems and data it is designed to protect and make them vulnerable to compromise.
Vulnerable SSH configuration
Most SSH server and client implementations (e.g., OpenSSH) include a significant number of configuration parameters which impact operation and security, including options for authentication, root access, port forwarding, file locations, etc. Fortunately, over the years, most SSH implementation developers have selected default configurations that are more secure. However, there are a couple of defaults, such as port forwarding and the location of authorized key files, that are not optimal. In addition, if your users and administrators arbitrarily change those configurations without considering the security implications, they can open those systems to broader attacks.
SSH port forwarding
Dating back to the days where encryption wasn’t available for all protocols, SSH features the ability to forward traffic sent to a local port on an SSH client. The traffic is forwarded through the encrypted SSH session to the SSH server or even beyond. The challenge is that this provides the ability for unapproved communications to traverse firewalls. If the user of an SSH client that has been granted SSH access to a server on the other side of a firewall is allowed to enable local port forwarding, they open the possibility that an attacker can gain access to systems and devices which might otherwise not be accessible. By exploiting port forwarding, an attacker may bypass firewalls that have been setup to limit access to the server’s network. In addition, attackers avoid detection because they are operating over an encrypted SSH connection.
Private key compromise
When you configure SSH for public key authentication, private keys then enable access to accounts. If a private key gets compromised, an attacker can authenticate into the account(s) where the private key is trusted. Here are some of the risks posed to SSH private keys:
- Careless Users: When users are authorized to use SSH public key authentication, they can be careless in their handling of their private keys, either placing them in insecure locations, copying them to multiple computers, and not protecting them with strong passwords.
- Administrator Turnover: When public key authentication is used for automated processes, one or more administrators for the process will be responsible for managing the process’ private key. Administrators can make copies of those private keys and, if they’re reassigned or terminated, can use the key(s) to authenticate to the target servers.
- Weak Keys: Because many SSH keys have not been changed in years, smaller length keys (e.g., 512 or 768-bit keys) are still in use, making it possible for a sophisticated attacker to derive the value of the private key. In addition, there have been bugs in cryptographic libraries (e.g., Debian in 2006) that have resulted in weak, easily breakable keys being generated.
Unauthorized SSH access
Because SSH provides remote access into systems, it is critical that access be tracked and controlled. Since many organizations don’t have centralized oversight and control of SSH, the risk of unauthorized access is increasing. Here are a few of these risks:
- Untracked Trust Relationships: Just as with any access method, not keeping an inventory of where SSH keys are installed and the trust relationships they establish between systems and accounts is a recipe for unauthorized access. With administrators coming and going over time, many organizations have accumulated large numbers of SSH keys but do not have visibility into the access they provide.
- Terminated Employees: If SSH users—whether employees or outside contractors—change roles or are terminated and their access to SSH servers is not properly updated or terminated, these individuals can have ongoing (yet unauthorized) access to mission critical systems.
- Backdoor Keys: By default, most SSH implementations (e.g., OpenSSH) allow users to configure their own authorized key files (placing a public key in an account so they can access it using a private key). If organizations don’t keep an up to date inventory of authorized keys and regularly review it, users or even attackers may place authorized keys in unexpected places for future access.
Privilege escalation
SSH is generally integrated with other components to enable access (e.g., operating system permissions, sudo, PAM, identity management, etc.). It is difficult enough to centrally orchestrate the secure configuration of all these components to prevent an attacker from successfully escalating privileges during an attack. It’s even more challenging when you have multiple individual administrators each making decisions on the implementation of SSH without any central oversight or review. Without this oversight, you’ll face greater potential for privilege escalation, especially since attackers remotely accessing systems over SSH have an encrypted session within which to hide their actions.
Rogue known host keys
If a user or administrator who initially establishes a connection from an SSH client to an SSH server does not check the authenticity of the public key for that server, they may accept an attacker’s public key and enable a man-in-the-middle attack.
Pivoting risk
Once attackers gain an initial entry into a network (either via phishing or some other means), their next goal is typically to get onto other systems. If not tightly controlled and managed, SSH can enable that movement (pivoting) between systems because of the persistent trust relationships created with SSH keys. And SSH-enabled pivoting can be the most damaging because SSH users and automated processes are typically granted elevated privileges. Many organizations leave themselves open to SSH-based pivoting because they have no inventory of deployed SSH keys that enable persistent access between systems.
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. When SSH machine identities fall into the wrong hands, this is very dangerous for your organization because SSH users and automated process are typically granted elevated privileges.
Circumventing security controls
While cybercriminals are busy moving laterally within your network, they could come across firewalls and other security technologies designed to block malicious network activity. Unfortunately, if you don’t properly control your SSH environment, attackers could bypass these safeguards by configuring SSH for port forwarding or other privileges. 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.
Obscured and exfiltrated data
Attackers like to hide within the infrastructure by using readily available tools, like the SSH protocol, to redirect and exfiltrate data without being detected by traditional controls. SSH enables traffic redirects and allows its users to set up a listening port on a client and tunnel data through an encrypted channel to an exit server port or vice versa. As a result, encrypted SSH connections can also be abused by attackers to exfiltrate data without being detected.
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.
The best solution is to integrate a centralized platform like Venafi SSH Protect, offering full visibility of all machine identities across your entire enterprise. Enforce SSH key policies, discover and remediate policy violations or compromises, and more from a single dashboard.
(This post has been updated. It was originally published Posted on January 11, 2019.)
Get a FREE & Confidential SSH Risk Assessment from Venafi!
Related Posts
