The GRC Perspective on SSH User Keys
Used as the tool of choice for administrators around the world to remotely access servers and network devices as well as securely transfer data between applications, SSH has been quietly and efficiently doing its job providing encrypted, trusted access for the last two decades. Yet the power it actually harnesses is widely unknown and, consequently, creating a major gap in our identity access postures and risk to the resilience of our enterprises. The SSH protocol is one of the security industry's greatest known unknowns.
When it comes to SSH user keys, several things stand out. For one, it is the only form of access that can be provisioned without oversight. Second, SSH user keys, unlike SSL certificates, have no expiration dates. So they continue to provide access until they are eliminated from the systems on which they reside. And finally, SSH user keys provide access not only for user-based access but also for service accounts, which move data between applications for critical transactions.
In thinking about GRC, three primary issues can easily come back to haunt us with respect to SSH user keys:
The Root of the Problem
In the land of IT administration, root access is one of our necessary evils. However, when not controlled correctly, it represents the greatest resilience risk. When it comes to SSH keys, here’s the blind spot that exists. When setting up any SSH user key, it is possible to put what is known as an IP Source restriction on a key, which will determine from what IP source the key may authenticate from and what destination server it has access to. Unfortunately, in over 90 percent of the cases, when root keys are being generated, the IP source restriction is simply forgotten. What does this mean? In the worst case, if we have public-facing servers or services and that private key is acquired maliciously or accidentally, it can now access that asset from anywhere.
Controlling Who Does What
Preserving the segregation of duties related to SSH user keys is vital, and there are three components related to it.
Jump host architecture work-arounds
A common sentiment regarding interactive access related to SSH user keys is, “We have this under control. All the users are required to go through our privileged access management solution and are controlled from there.” Very frequently, jump server architectures are used to control users’ access to a destination server. The challenge here is that a user can generate themselves an SSH user key on that destination server and bypass the jump server in the future. That in itself would bypass any monitoring capabilities of that jump server and would potentially make actions taken by the user more difficult to track. More concerning than this is if that user has the possibility to elevate privilege from that server and from there deploy new keys.
Tunneling between environments
Another difficulty with SSH user keys is the connectivity from non-production environments to production environments. This happens for both interactive access and non-interactive access. With interactive users, the challenge is closely related to the bypassing of jump server architecture. The user comes through the jump host to the non-production environments as usual, uses tunneling (a sub-channel of the SSH protocol) to tunnel across to a production server and from there may drop in a new key pair, which will permit access again directly from their desktop to a production environment. Now, this is a real red flag in most regulated IT environments, but it happens much more frequently than you may expect.
Improperly using transitive trust and agent forwarding capabilities
What is transitive trust? It’s about how deeply a single key or user may be able to penetrate the infrastructure using key-based authentication. Again, when SSH user keys do not have IP source restrictions or forced commands dictating what a user may do during a session, it becomes a question of how far that user can continue to gain access within the environment with their privileges. So in this case, the user may access one server, elevate privilege, drop in new keys and gain access to another server. From there, they may use the sub-channels of the SSH protocol to create connectivity back to their home desktops or other servers, bypass corporate firewall policies and exfiltrate critical data without being noticed.
Keys Must Be Monitored
The monitoring of key-based authentication is a critical aspect related to solid SSH user key and access management. All privileged access must be controlled and monitored according to the majority of compliance mandates; however, key-based authentication is ignored, as is where SSH user keys are authenticated from – and how frequently. Fortunately, this information sits at our fingertips and as long as VERBOSE logging is enabled on the SSH server, the logs for key-based authentication can be easily captured. This information is essential in us gaining control of our environments, whereas without key-based activity monitoring, we are unable to assess whether keys are obsolete or not. Remember, SSH user keys do not have expiration dates, so you may find that up to 90 percent of the keys in your environment are no longer being used.
SSH user keys are slated to become a hot auditing topic. Any doubt about this reality will be laid to rest with a reading of the article Looting of the Fox: The Story of Sabotage at Shapeshift, by CEO Erik Vorhees. It details how SSH user keys were misused to steal from his company. Long ignored and abused by users, these keys are a crucial component of security – and savvy cyber criminals know it. Organizations that continue to overlook this aspect of their infrastructure do so at the risk of their safety and compliance.
About the Author
Matthew McKenna, Chief Strategy Officer, SSH Communications Security, brings over 10 years of high technology sales, marketing and management experience to SSH Communications Security and is responsible for all revenue-generating operations.
Edited by Peter Bernstein