Skip to main content
banner image
venafi logo

Secure Shell (SSH) Security, Vulnerabilities and Exploitation

Secure Shell (SSH) Security, Vulnerabilities and Exploitation

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.  

  • 100% of the world’s supercomputers run on Linux.  Out of the top 25 websites in the world, just two are not running Linux. 
  • 96% percent of the world’s top one million servers run on Linux. 
  • 90% of all cloud infrastructure operates on Linux. 
  • AccirYou can then look at Censys data (https://censys.io/) to see how many hosts on the internet are using SSH.  Over 18 MILLION as of July 10, 2020.  18 million!!  And keep in mind that this 18 million is just internet traffic.  This does not include the Secure Shell sessions that are used on internal networks.  The number of sessions on internal networks will be much larger than internet traffic.

 

What is SSH used for?

In addition to remote control and file transfer SSH has lots of really cool use cases.

  • Remote login
  • Executing remote commands
  • Automatic logins
  • Backup
  • Copy and mirror files
  • Port forwarding
  • Remote file transfer
  • A full-fledged encrypted VPN  for OpenSSH servers and clients that support this feature
  • Tunneling
  • Proxying
  • Remote monitoring and management of servers using the tools listed above

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.

 

SSH History

 

Version 1.x

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.

 

Version 2.x

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. 

 

V1.99

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.

 

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 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:

  • 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 really 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.

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:

  1. Kaiji (May 2020) targeting IoT and Linux hosts trying to brute-force root account authentication
  2. Infamous Sony breach (2014) was done with the use of stolen SSH key
  3. In May 2019 it was found that Cisco Nexus 9000 series has hardcoded root authorized key
  4. Late 2019 Kinsing Malware attacks targeting container environments
  5. 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

Find out about your organization’s SSH security risks by signing up for this free risk assessment

 

 

Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud


Venafi Cloud manages and protects certificates



* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
(@%+^!#$?:,(){}[]~`-_)
* Please fill in this field
* Please fill in this field
* Please fill in this field
*

End User License Agreement needs to be viewed and accepted



Already have an account? Login Here

×
get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more