By Gavin Hill
Secure Shell (SSH) is the de facto protocol used by millions to authenticate to workloads running in the cloud and transfer data securely. Even more SSH sessions are established automatically between systems, allowing those systems to securely transfer data without human intervention. In either case, this technology underpins the security of vital network communications. According to the Ponemon Institute, organizations recognize SSH’s role in securing network communication and list threats to their SSH keys as the number one most alarming threat arising from failure to control trust in the cloud.
SSH authentication holds only as strong as the safeguards around the authentication tokens, the SSH keys. Failure to secure and protect these keys can compromise the environment, breaking down the trust that SSH should establish. Malicious actors take advantage of common mistakes in key management, the following are some of the common pitfalls organizations fall prey to.
The Weakest Link
Malicious actors often target SSH keys because SSH bypasses the authentication controls that typically regulate a system’s elevated privileges. In their efforts to exploit SSH, malicious actors naturally focus on compromising the weakest link in a highly secure protocol – human error and mismanagement of the private SSH keys.
The risks are real, and so are the costs. According to the Ponemon Institute, the average US organization risks losing up to $87 million per stolen SSH key.
Lack of Control
Less than 50% of organizations have a clear understanding of their encryption key and certificate inventory – let alone efficient controls to provision, rotate, track, or remove SSH keys. System administrators usually deploy keys manually, with different groups managing their own independent silos, leading to a fractured, distributed system. Without centralized monitoring and automated tools, system administrators cannot secure or maintain control of keys.
A report issued by Dell SecureWorks’ Counter Threat Unit revealed that one in every five Amazon Machine Images (AMI) has unknown SSH keys, each of which represents a door into the system to which an unknown party has access. As shocking as this fact seems, it is actually not surprising when you consider the ad-hoc management practices common in many organizations. In performing their jobs, application administrators copy their host key to multiple workloads but often fail to document the locations. As employees move on to new jobs, the keys linger, and the organization loses all ability to manage and assess its systems’ exposure to unauthorized access.
Injected Elevated Trust
An SSH server uses public-key cryptography to validate the authenticity of the connecting host. If the server simply accepts a public key without truly validating the identity of the connecting host, however, the server could easily give an attacker elevated access.
The mass assignment vulnerability, which is still largely unpatched, offers one example of an injected elevated trust exploit. In secure networks, users require root or admin privileges to append their own SSH keys to the authorized key file. Using the mass-assignment vulnerability, however, attackers create accounts that have the appropriate permissions. They then add their own SSH keys to gain the elevated privileges required to compromise the system.
Recycled Rogue Workloads
Cloud computing environments often reuse workloads. Amazon Web Services (AWS), for example, offers thousands of AMIs. However, you should exercise extreme caution when reusing a workload; educate yourself about the workload’s applications and configuration. In addition to rogue SSH keys, you may also find specific compromised packages.
For example, earlier this year hackers compromised thousands of web servers’ SSH daemons with a rootkit. The rootkit rendered companies’ key and password rotation policies futile: the SSH daemon simply yielded the new credentials to the attackers. The SSH rootkit completely replaced the ssh-agent and sshd binaries; only reinstalling SSH completely eliminated the threat.
Best Practices
Establish a baseline
Cloud computing has proliferated the use of SSH keys, and administrative efforts have not kept pace. Yet, when you fail to understand the SSH deployment in your organization – which keys give access to which systems and who has access to those keys – you risk losing intellectual property and, worse, losing control of the workloads.
Inventory the entire organization on a regular basis to discover SSH keys on workloads running in the cloud and in the datacenter. Establish a baseline of normal usage so that you easily detect any anomalous SSH behavior.
Enforce policies
Frequent credential rotation is a best practice, and you should make no exception with SSH keys. Unfortunately many organizations leave SSH keys on systems for years without any rotation. Although most cloud computing workloads are ephemeral, they are typically spun up from templates with existing SSH credentials, which are rarely rotated. Malicious actors can also crack vulnerable versions of SSH or SSH keys that use exploitable hash algorithms or weak key length.
To secure your environment, enforce cryptographic encryption policies that prohibit the use of weak algorithms and key lengths, implement version control, and mandate key rotation.
Scrutinize workload templates
If you choose to use prebuilt templates, implement an assessment process before the workload is used in production. Do not simply accept a pre-built workload template created by someone you do not know. First carefully inspect the template; ensure that the applications are patched, the workload configuration is secure, and that there are no rogue applications or keys that may be used as a backdoor.
Gavin Hill is the director, product marketing and Threat Research Center, at Venafi