Attackers use many means to crack the shell (secure shell) of SSH keys. Port scanning the IPv4 range to scout for open SSH connections, collecting exposed private SSH keys, and exploiting security around SSH key management (where user OPSEC is frequently lacking) are a few of the ways attackers gain access to vulnerable systems.
A recent report, Venafi disclosed that most organizations have not implemented SSH security policies or restricted SSH access configurations because they do not understand the risks of SSH and how it affects their security posture.
A study of over 410 IT security professionals by the company also found:
- 61 percent of respondents do not limit or monitor the number of administrators who manage SSH.
- 54 percent of respondents do not limit the locations from which SSH keys can be used.
- 91 percent of the respondents said they do not have a complete and accurate inventory of all SSH keys so there is no way to determine if keys have been stolen, misused or should not be trusted.
In preparation for an attack, one of the first steps an attacker will take, is to probe open ports. To expose running software and services on each port, attackers perform enumeration via banner grabbing, collect details of the remote system and the services running on its open ports—via network tools like CURL, Dmitry, Netcat, or Nmap and botnets.
I’m sure you’ve heard about security through obscurity via SSH port relocation (moving SSH to a higher port) thus offering a lower threat frequency. There is one tiny caveat to port relocation though—if an organization is specifically targeted by the attacker, port relocation offers zero protection.
An attacker will simply set up and automate a full port scan of the organizations IP range and the non-standard SSH port will be unmasked.
Exposed SSH Keys
Exposed private SSH keys is no laughing matter. Who can forget the Booz Allen lead senior engineer who left 28 GBs of sensitive Pentagon files on an Amazon server (with no server password protection)—thus exposing his security credentials and private SSH keys.
Five months later, Mark Maunder, CEO at Wordfence reported seeing “a new attacker start mass-scanning websites for private SSH keys.” Though scanning for private SSH keys is nothing new—the massive spike in scanning activity by attackers was alarming.
Attackers also know that many large organizations harbor far more SSH keys than they should have when compared to the number of servers and user accounts contained within an organization.
In one large (unmentioned) financial institution SSH inventory, Tatu Ylonen's company found more than 3 million keys, granting access to approximately 15,000 servers—averaging out to a whopping 200 keys per server. Ylonen's example above clearly depicts a case of bad key management.
Attackers will continue to scan for system and service vulnerabilities and for SSH keys to exploit—that’s a given.
When organizations fail to limit and monitor the number of administrators who manage SSH, fail to limit the locations from which SSH keys can be used and fail to inventory and manage all organization SSH keys—this certainly poses a significant risk to any organization’s infrastructure and increases the attack surface for continued exploitation by the bad guys.
If your organizations SSH security posture has slumped—SSH attacker incursion is imminent. It’s time to increase and strengthen your organizations SSH security posture now. Tomorrow may be too late.