What is Secure Shell? Why was it invented?
Secure Shell is a network protocol that was designed to operate network services securely over an unsecured network. But what does that mean? Back in the old days, imagine how cool it was to transfer a file from one machine to another. Or imagine being one of the first engineers to be able to interface with a server when you’re not sitting at the keyboard in the same location. Those tasks are so common today we can’t even imagine life without them. But these original network applications did not use encryption. So, if a bad guy gained access to your network he could ‘listen in’ to your sessions and see exactly what you were doing. SSH was invented to encrypt network services so malicious actors would not be able to eavesdrop on network traffic and see everything that was happening. This is especially important to ensure data confidentiality and integrity.
It’s a popular misconception that SSH is an implementation of Telnet and that SSH cryptography is provided by SSL. This is not true. SSH was designed as a replacement for Telnet and other insecure shell protocols such as Berkely rsh, rlogin and rexec protocols. All of these send information, including passwords, in plaintext.
SSH was invented in 1995. So the protocol has been around since Bill Clinton was the President, Braveheart won the Academy Award and Gangsta’s Paradise was the jam in your Walkman cassette player. The tool quickly gained in popularity. Towards the end of 1995, the SSH user base had grown to 20,000 users in fifty countries and in 2000, just five years later, the tool had over 2 million users.
Today Secure Shell is included with every distribution of Linux and Windows Server 2019. If you’re thinking “well Linux, isn’t that popular compared to Windows so that must mean that Secure Shell is not that popular” you’d be wrong.
What is SSH used for?
In addition to remote control and file transfer SSH has lots of really cool use cases.
SSH is very important in cloud computing to solve connectivity problems, avoiding the security issues of exposing a cloud-based virtual machine directly to the Internet. SSH tunnels are routinely used to provide a secure path over the Internet, through a firewall to a virtual machine.
How does SSH work?
WARNING: This is intended to provide a basic, high level explanation. This explanation will not be exhaustive and your OCD warning light is about to flash like mad.
Secure Shell is based on public-key cryptography. This public-key cryptography allows authentication (knowing that who you think you are talking to is really them) and encryption (private). There is a key involved called “the host key”. This key is used to identify the Secure Shell server. From the user side of things there are two ways to use Secure Shell. One is with a password and the other is with keys. If the password method is used then the user has to remember their username and password. If keys are used then the user does not have a password; instead they have a key that is installed on their PC and this key is what the Secure Shell server uses to identify the user. Regardless of the authentication method used, once the client authenticates to the Secure Shell server their connection is encrypted and they can execute any of the use cases we discussed above.
The first version of the SSH protocol was released in 1995 as freeware. In 1998, a vulnerability was described in SSH 1.5 which allowed the unauthorized insertion of content into an encrypted SSH stream due to insufficient data integrity protection in this version of the protocol. The SSH Compensation Attack Detector was introduced to fix this flaw. However, these updated implementations were found to contain a serious integer overflow vulnerability that allowed attackers to execute arbitrary code with the privileges of the SSH daemon, typically root.
In January 2001 a new vulnerability that allowed attackers to modify the last block of an IDEA-encrypted session. The same month, another vulnerability was discovered that allowed a malicious server to forward a client authentication to another server.
Because of these design flaws v1.x is now generally considered obsolete.
The IETF created a working group responsible for version 2 of the SSH protocol, and this group introduces a revised version of the protocol, SSH-2, that was incompatible with SSH-1. This version was adopted as a standard in 2006. features both security and feature improvements over SSH-1. SSH-2 uses Diffie–Hellman key exchange and strong integrity checking via message authentication codes to improve security. SSH-2 also includes the ability to run any number of shell sessions over a single SSH connection.
In January 2006, well after version 2.1 was established, RFC 4253 specified that an SSH server which supports both 2.0 and prior versions of SSH should identify its version as 1.99. This is not an actual version but a method to identify backward compatibility.
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 that 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. Susan leaving 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 have the ability to 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:
Key sprawl or a lack of SSH key management is a common situation that exacerbates other SSH security risks. Would you find it hard to believe that a company with 5,000 servers would have 600,000 keys? Or a company with 10,000 servers would have over 1,000,000 keys? SSH experts have worked with many organizations that have these numbers of active SSH keys; and remember that these keys don’t expire. This can be a big vulnerability.
Earlier in the article we discussed vulnerabilities connected to users’ SSH keys. There are also security risks connected with “host keys,” which are the other authentication method used to identify the Secure Shell server.
Before we talk about the security risks connected with SSH host keys, here’s how 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 he/she should trust this server because they should know the key. Once the user says, “Yes, I know that key and yes I trust you” then that key is added to what is called the known hosts file. So, the next time the user goes to that server, the server presents its key and 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 shown. This process is a really 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 malware in 2019 targeting SSH servers and 2020 hot on its heels one could see how just a single compromised key could lead to a free for all for bad guys if you would happen to be infected with one of these types of malware.
Here are examples of real world SSH threats:
Find out about your organization’s SSH security risks by signing up for this free risk assessment