Securing SSH on EC2: What are the real threats?

Every compliance audit will ask you to securing SSH, and every time a scanner checks the configuration or CSPM of your cloud account you’ll be warned for it. For example, if you don’t secure SSH on EC2, you’ll certainly get a critical alert stating that one of your Security Groups has its SSH port (22) open to the world.

When this happens, you may think: Have I been pwned?

And you wouldn’t be at fault, since internet information and marketing materials are often quite alarming on this topic. But is it really THAT bad?

In this article, we’ll honestly explain the real threats that you are susceptible to when you have this misconfiguration.

What is SSH on EC2?

The Secure Shell Protocol (SSH) is the standard for remotely managing a server/machine, and replaces telnet as the secure alternative. This is a main entry point for attackers, since once you can access via SSH, you are several steps closer to gaining control of the full machine. It is therefore important to protect and audit SSH logins.

When talking about AWS, SSH is enabled by default on EC2 instances. As soon as you spin up a machine, SSH access is configured via a RSA key pair. And it’s rather easy to connect via an SSH client if you have access to those keys. However, this ease of access also makes it convenient for attackers. AWS explains how to securing SSH on EC2 following best practices. In summary:

• Don’t expose the SSH port to the world.
• Don’t allow the root user to use an SSH terminal.
• Force all users to log in with an SSH key pair, and then deactivate password authentication.

What are the problems with opening SSH connections from untrusted sources?

This is the main answer we explore in this article. Let’s dive into a few examples:

• Increase of the exposed attack surface.
• Brute force password attacks.
• Key Pair Leaks.

CIS Benchmark – 0.0.0.0/0

If you are a seasoned cloud engineer focused on security or compliance, you may be already familiar with the famous CIS Benchmark and the best security practices. For the rest of you, here is how this standard covers securing SSH on cloud providers.

Passing these controls is necessary to meet compliance, so your team is probably leveraging some tools to help check for misconfigurations. There are many open source tools that can help you monitor your cloud security posture (CSPM) and troubleshoot further problems, with Prowler being one of the most famous ones.

If we go deeper into the controls, this is one that alerts us when we open the port in the AWS CIS Benchmark:

• 4.1 Ensure no security groups allow ingress from 0.0.0.0/0 to port 22 (AWS)

CIS explained the impact as, “Removing unfettered connectivity to remote console services, such as SSH, reduces a server’s exposure to risk.”

This is not only for AWS. The other two public cloud providers, GCP and Azure, have the same control.

• 3.6 Ensure that SSH access is restricted from the internet (GCP)
• 6.2 Ensure that SSH access is restricted from the internet (Azure)

This is the main reason for most of the triggered alarms you see.

Thus, the goal of this control is clear, as it reduces a server’s exposure to risk. But if one of these alarms is triggered, does this mean we are hacked at the moment the port is exposed? Let’s look at the real risks.

The reality of exposing SSH

Depending on the CSPM or the configuration of your EC2 machine, an attacker may take control of more or less of your resources. The final result depends on the combination of misconfigurations.

We would like to explain the three scenarios in which your SSH port is accessible:

AWS keeps the SSH daemon installed on all official AMIs up to date, so it is not feasible to exploit a known vulnerability if we launch a new EC2.

SSH access without credentials

Two things could have happened here. Either the person who set it up wants to see the world burn or they are a honeypot; these are the only reasons to leave your machine unprotected. It’s the worst-case scenario, and it’s almost a guarantee that any bot or spider will have access to your EC2 in hours.

SSH open with user/password authentication

This scenario is more common than the previous one, but in the case of EC2, you need to configure it manually. As a user, you may be motivated to configure your machines in this way to be able to access via SSH from anywhere. And you will create the credentials with a false feeling of being safe. Here’s the problem; in this specific scenario, with SSH open to the world behind simple credentials like a username and password, the security depends entirely on the robustness of your password.

This combination of exposure and poor authentication allows the attacker to perform brute force attacks using different tools. Here, we explain three examples with several open source tools:

• Nmap, one of the most famous port scanning tools, has the ability to execute brute force attacks through scripts, Here is an example:

  nmap -p 22 --script ssh-brute --script-args userdb=users.lst,passdb=pass.lst --script-args ssh-brute.timeout=4s <target>

• Metasploit is a pentesting framework with several modules. One of them is for brute force attacks, and you can set the parameters to exploit a server.

  msf > use auxiliary/scanner/ssh/ssh_login
  msf auxiliary(ssh_login) > set RHOSTS <target>
  msf auxiliary(ssh_login) > set USERPASS_FILE /usr/share/metasploit-framework/data/wordlists/root_userpass.txt
  msf auxiliary(ssh_login) > set PASSWORD /usr/share/metasploit-framework/data/wordlists/rockyou.txt
  run
  

• Hydra is a tool that gives researchers and security consultants the possibility to show how easy it would be to gain unauthorized access from remote to a system.

  hydra -L /usr/share/wordlists.rockyou.txt -P /usr/share/wordlists/rockyou.txt <target-IP> -t 4 ssh

This type of attack can start as soon as the SSH port is exposed. According to a report by Smart Honeypot, the first SSH brute force attack occurs in less than 12 hours. Therefore, if you use this type of authentication for SSH access, you should use tools that prevent part of brute force attacks such as fail2ban.

SSH open and key pair authentication

This is the default configuration. In this scenario, your private key isn’t stored in AWS and can only be retrieved when it’s created. The threat could be leaking your key pair by mistake or by an insider. This is something that can happen but is not unique to SSH access.

The creation of a key pair is similar to that of a Linux system if your AMI is based on Linux or Amazon and the public key is stored in the ~/.ssh/authorized_keys folder, and that’s all.

The main issue is how to manage the key pairs. If you use GitHub to store it, tools like DumpsterDiver or git-secrets are handy to scrap your files or repositories to find certificates.

Cryptographic stuff

The key pair generation is based on RSA or Ed25519 standards. The probability of generating two different key pairs accessing the same instance is negligible. Therefore, a brute force attack is not a realistic attack.

Final words

Reducing your attack surface is one of the principal security best practices, and we’d like to explain a bit more about the real threats when you expose SSH. You are not hacked instantly BUT it’s one step attackers need to gain remote access, for this purpose, it is necessary to secure SSH anyway.

Combining this misconfiguration with another one will create serious problems. However, we recommend securing SSH, and never exposing SSH to accept connections from anywhere, to avoid unnecessary security incidents.