Although Secure Shell (SSH) is the most broadly used security protocol for remotely managing Unix/Linux, routers, firewalls, and other systems, most organizations have limited or no formal SSH policies in place. Many security practitioners and managers outside of the Unix teams have only a cursory knowledge of SSH—some may not be able to tell you whether SSH uses certificates or public keys, let alone how broadly it’s used or the risks it poses if not properly managed. When badly managed or improperly implemented, SSH machine identities can be the root of serious cybersecurity risks.
Here is a list of the top SSH security risks that you need to be aware of.
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 systems where SSH use is justified, if SSH server and client software isn’t kept up to date with fixes and updates, it can unintentionally expose the systems and data it’s designed to protect and make them vulnerable to compromise.
Vulnerable SSH configuration
Most SSH server and client implementations (such as OpenSSH) include a significant number of configuration parameters that impact operation and security. Most administrators choose secure defaults. However, a couple of these default configurations, such as port forwarding and the location of authorized key files, aren’t optimal for security. 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. If local port forwarding is enabled on an SSH client that’s been granted SSH access to a server on the other side of a firewall, an attacker may be able to use it to bypass firewalls.
Private key compromise
When you configure SSH for public key authentication, private keys enable access to accounts. If a private key gets compromised, an attacker can authenticate into the account(s) where the private key is trusted. SSH private keys can be compromised in the following ways:
- Careless users
When administrators are authorized to use SSH public key authentication, they can be careless in their handling of their private keys by 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 can be responsible for managing the private key for the process. Administrators can make copies of those private keys and, if they’re reassigned or terminated, can still use the key(s) to authenticate to the target servers.
- Weak keys
Because many SSH keys haven’t been changed in years, smaller length keys may still be in use, making it possible for a sophisticated attacker to derive the value of the private key. In addition, we have seen bugs in cryptographic libraries that have resulted in weak, easily breakable keys being generated.
Privilege elevation
SSH is generally integrated with other components to enable privileged access—including operating system permissions, sudo (which allows one user to run a program as another user), and privileged access management (PAM) solutions. It can be difficult to centrally orchestrate the secure configuration of all these components to prevent cybercriminals from successfully elevating privileges during an attack. What’s even more challenging is when you have multiple individual administrators each making decisions on the implementation of SSH without any central oversight or review. Without this oversight, you face greater potential for privilege elevation, especially because attackers remotely accessing systems over SSH will have an encrypted session within which to hide their actions.
Rogue known host keys
If users or administrators who initially establish a connection from an SSH client to an SSH server don’t check the authenticity of the public key for that server, they may inadvertently accept an attacker’s public key and enable a man-in-the-middle attack.
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.
How can you mitigate SSH machine identity risks?
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. This lack of central oversight leaves network administrators to their own devices, resulting in mistakes and significant security risks.
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.
Related posts
