The misuse and exposure of SSH keys once again came to the forefront in the past weeks. On Feb 20, FireEye-Mandiant M-Trends report 2020 provided evidence of insider threats leveraging SSH as part of an asset destruction scheme. The report states, “Forensic analysis identified malicious SSH connections from an unauthorized device to Linux servers hosting a critical security service.” SSH was also mentioned under the “Breaching the cloud” section as exfiltration method. “VPC flow logs recorded a large volume of data being transferred via SSH to the virtual server in the Netherlands.”
Combine the new findings from FireEye-Mandiant with the recent reality of TrickBot—which was the #1 malware Campaign in 2019—and it is clear that SSH has become the path of least resistance for attackers. Here some of the reasons why that may be true:
- Rapid adoption of DevOps and cloud often exposes SSH
The pressure for continuous development is driving increased and perhaps unsafe usage of SSH by both ITOPS as well as developers. Palo Alto’s Unit 42 2020 Cloud Threat Report provided some specific metrics on this and reported that 76% of cloud workloads expose SSH (up 20%). This is, of course, a very risky practice as attackers can steal passwords or permanent private keys that are inadvertently left on endpoint devices.
- SecOps has a hard time monitoring SSH
SSH is a blessing as it allows strong encryption, has been widely adopted (one of the most adopted protocols outside HTTP/HTTPS) and offers a lot of flexibility in usage—it’s interactive and secures file transfer and automation. However, once data is encrypted, it becomes very expensive for SecOps teams to monitor the data inside the encrypted channel. Some SecOps users have given up on it completely and it is not uncommon to hear comments such as, “If it is encrypted it must be good.”
- Setting up a key lifecycle is not an IT priority
A recent Forbes Insights SecOps Survey illustrated how much SecOps teams hate approval processes. Rating # 2 on the list of things SecOps like least was Obtaining Change Approvals. Assigning, Auditing and Approving SSH Keys can be part of this apparently arduous workflow.
- Vendor Misconfigurations abound
You don’t have to wait for your own IT teams to create an SSH vulnerability. Many vendors will do it for you by leaving identical manufacturing root keys on the to be installed device. These keys are easy to get to by just opening a new box but can also be found on the internet.
- SSH Mitigation can be difficult and time consuming
Once an SSH key gets compromised and the attacker gains access, mitigating all SSH keys can be very hard. Most organizations don’t have an inventory of their SSH keys and revoking all keys will more than likely stop certain critical IT processes. The situation is often characterized as “the sleeping dragon” an analogy which is also used by protesters who chain themselves together to make law enforcement efforts super hard.
In short, the proliferation of SSH has been on the rise for a while. But now the adoption of cloud and DevOps has helped to make SSH a primary target for adversaries. InfoSec teams who need a step-by-step approach to carefully mitigate these unnecessary risks can start with a Standards-Based Policy and Procedure Framework like NIST 800-53 or NIST IT 7966.