SSH (Secure Shell) is a secure way to remotely connect to and communicate with servers, but the way in which the keys are handled can lead to access security issues and the potential exposure of sensitive data.
SSH keys are used to log into servers (more secure than just a username and password). These keypairs include a public key and private key that are cryptographically secure and used to authenticate a client to an SSH server. The private key should be kept secret - if compromised, the private key alone can allow attackers to log into servers or systems. The public key is kept on the server that you want to authenticate into.
Website owners or developers may accidentally upload their SSH private key to their public website, or commit their private keys into website source code via Github or SVN (subversion) repositories. Once uploaded, an attacker can scan public sites for SSH keys and get access to your servers.
Issues With SSH Security Management
A recent study from Threat Stack found that 73 percent of Amazon Web Services (AWS) users left their remote SSH service exposed to the public internet on their cloud instances.
A configuration error like this allowed attackers to log into servers from anywhere, bypassing traditional network controls, such as firewalls and virtual private networks (VPNs).
The study also found that 62% of AWS users at the companies analyzed were not using multi-factor authentication (MFA), also known as two-factor authentication (2FA) - an additional way to verify users’ identities through a variety of different methods. Amazon lists those different options on their website about MFA.
Additionally, the study revealed that less than 13% of companies kept their software up to date - some of the unpatched systems were kept online for more than three years.
According to Threat Stack, despite the enterprise investment on advanced, sophisticated security solutions, most of them are not taking full advantage of the most basic security tools already available to them.
Mismanaged SSH Keys
A survey from Venafi, as reported by InfoSecurity Magazine found that 61% of IT security professionals don’t practice least privilege - that is, they don’t limit or even monitor the number of admins who manage SSH.
Another 90% of respondents don’t have a complete and accurate inventory of all SSH keys, which can make it difficult to keep track of misuse or which keys should be trusted.
Examples of SSH Key Exposure
Back in May, it was reported that a leading U.S. government contractor exposed more than 60k unclassified sensitive files on a publicly accessible AWS server - including unencrypted passwords to sensitive government systems, contractor credentials, vulnerability reports on government source code, and more.
Plaintext data in the AWS S3 bucket also included the public and private SSH keys of an engineer working at the government contractor, and admin credentials to one of their data center’s operating systems.
While U.S. government servers hosted on Amazon are usually segregated on the GovCloud (an isolated AWS region protected by advanced cryptography and physical security), this particular AWS S3 bucket was not. The files were connected to the US National Geospatial-Intelligence Agency (NGA), which provides battlefield and drone surveillance imagery.
More recently, security researchers have reported a single entity that has been scanning systems, seeking out SSH private keys that can be used to compromise websites, according to Wordfence. Attackers are searching for the terms root, ssh or id_rsa to find public web directories that contain the private SSH keys.
For more information on SSH security best practices, check out Ari’s Blog.