Protecting your SSH certificates is vital to maintaining a secure and successful machine identity management program. When SSH machine identities are properly secured, this can lead to key sprawl, lost keys, lack of policy enforcement, data breach, and much more.
Knowledge is power, so let’s look at the most common SSH vulnerabilities so you can be sure your organization is protected from them!
Most common SSH vulnerabilities
Secure Shell uses encryption algorithms. These algorithms change and as they age, they become more vulnerable. When they become vulnerable bad guys can take advantage of that to do bad stuff.
Also, remember how users can use keys rather than a password to login? These SSH keys never expire. So, imagine Susan is a system admin and she has access to several servers. She used SSH keygen to generate keys and she now can login to the systems via Secure Shell. Susan leaves the company, which doesn’t impact the servers at all. However, if nobody removes Susan’s keys from the servers, she still has access. Or what if a malicious actor got a copy of Susan’s keys? Or someone else’s keys? There would be evidence of these things in SSH logs, but only if someone at Susan’s company is monitoring those SSH logs.
Another very useful capability of SSH and the use of keys is the ability to pivot from one machine to the next. Imagine a sys admin logs into one server and performs a task. They then can pivot from one server to the next without having to logout and the login to the next server. They can then pivot from server 2 to 3, 3 to 4, on and on to perform whatever task they needed to do. Very useful right? But imagine if a bad guy gets access to one server. He can then pivot from server 1 to 2, 2 to 3, etc. It’s never that easy in the real world. The bad guy gets access to server 1 and then he/she hunts and pecks until they get access to another server and then repeat until they find something interesting/useful.
Other common SSH vulnerabilities are exposed via configuration and settings. In most organization system administrators can disable or change most or all SSH configurations; these settings and configurations can significantly increase or reduce SSH security risks. Here are examples of these common configuration settings that reduce security risks:
- Disabling password-based authentication - choosing this configuration makes brute-force password attacks impossible.
- Disabling root account remote login - This prevents users from logging in as the root (super user) account. If a user needs high level of privilege, there are things like sudo that will enable them to do this if their job requires this level of access.
- Allow or deny access based on user or IP address - this a Secure Shell server that supports a particular business unit or app team, only allow that app team to access the system.
- Port forwarding – (aka SSH Tunneling) is another useful capability for forwarding or tunneling application ports from client to server, or vice versa. Imagine a Linux box being able to listen for incoming / public requests and based on the type of request (file server, printer, email, et.) it knows where to send (tunnel) the traffic to another internal server. Very useful. But port forwarding requires careful configuration and hardening to make sure bad stuff from the internet is not forwarded into the private network.
SSH Machine Identity Management for Dummies
What is key sprawl?
Key sprawl, or a lack of SSH key management, is a common situation that increases other SSH security risks. Did you know a company with 5,000 servers can have as many as 600,000 keys? Or that a company with 10,000 servers would easily have over 1,000,000 keys? SSH experts at Venafi have worked with many organizations that have these numbers of active SSH keys. It’s vital to note that SSH keys don’t expire; while this can be convenient for SSH key management it is also a major vulnerability.
We discussed vulnerabilities connected to users’ SSH keys above. There are also security risks connected with “host keys,” which are the other authentication method used to identify the Secure Shell server.
How do automated secure shell processes work?
When a Secure Shell client logs into a server for the first time, the server presents this ‘host key’ and essentially says “hi, this is me. Here’s my key. Do you trust me?” The user is supposed to know if they should trust this server because they should know the key. Once the user says, “Yes, I know that key and, yes, I trust you” that key is added to what is called the known hosts file. The next time the user goes to that server, the server presents its key. Because the key is already in the known hosts file, the user now automatically trusts the server and the “Do you trust me” message is no longer displayed. This process is a good thing because it uniquely identifies each Secure Shell server.
However, the use of virtualization and automation tools that all organizations in the world use often create a significant problem because in many organizations there are hundreds or thousands or tens of thousands of different servers using with the same ‘host key. Unfortunately, this happens routinely in many, if not most organizations because servers are cloned after the host key was created. If one of those servers were to get compromised a bad guy can now impersonate any server that uses the same key by leveraging a man in the middle attack. With just over 20 new types of malwares in 2019 targeting SSH servers, and 2020 hot on its heels, one could see how even one compromised key could to infection with one of these types of malware, which would be potentially catastrophic.
Here are examples of real world SSH threats:
- Kaiji (May 2020) targeting IoT and Linux hosts trying to brute-force root account authentication
- Infamous Sony breach (2014) was done with the use of stolen SSH key
- In May 2019 it was found that Cisco Nexus 9000 series has hardcoded root authorized key
- Late 2019 Kinsing Malware attacks targeting container environments
- Even popular pen-testing solutions like Metasploit have tools to discover SSH keys and perform pivoting attack, so one should not be super bright to attack your organization
How to protect your SSH keys and certificates
Now that you know about all these SSH vulnerabilities and security threats, what can you do to protect your organization? Luckily for you, Venafi has you covered. SSH Protect is your one stop shop for SSH machine identity discovery, inventory, visibility, and management. With this platform you can easily see what keys are being used where on your network, who has access, and choose when to rotate them.
Get a FREE & Confidential SSH Risk Assessment from Venafi!
Related Posts