The Secure Shell (SSH) protocol is an encrypted network protocol used to access an interactive shell and perform file transfers between systems over untrusted networks. SSH is the de facto management protocol for non-Windows machines (and even some Windows systems), replacing the Telnet protocol from days past.
The most recent version of the protocol, SSH-2, was standardized in 2006 and provides a high level of security when configured correctly. runZero analyzed aspects of SSH in the ecosystem to explore how SSH is being deployed in the real world.
My voice is my passport. Verify me. #
The Secure Shell protocol consists of three phases. First, a secure transport is negotiated, similar to TLS. After the transport key negotiation is complete, the client attempts to authenticate, specifying one of a handful of known methods, and the server replies indicating whether the authentication succeeded and what remaining authentication methods are available if not. Finally, after successful authentication, a session is opened. This session enables access to channels, which in turn provide interactive shells, port forwarding, agent forwarding, and file transfer capabilities, among other options.
The three most common authentication mechanisms are:
Of the three mechanisms, publickey is by far the most secure and considered best practice. This type of authentication also supports key certificates, which provide even stronger security for key issuance and revocation. In publickey authentication, a user’s public key is stored in their profile on the destination system and only someone with the corresponding private key can authenticate. This prevents compromise through password-guessing attacks.
FIGURE 1 - A partial screenshot of runZero showing the results of an SSH scan.
In our survey of SSH endpoints, 54% support both password and publickey authentication. This is the default for many modern SSH services, and allows the optional use of a strong public key while allowing for the ease of password setup. In general, best practices recommend that the password mechanism be used only to set up public key authentication, after which it should be disabled. Leaving password authentication enabled exposes systems to password enumeration attacks and the potential for weak passwords set by users.
Password authentication is more common on storage and networking devices, where accounts are less likely to be associated with individual persons. Often, though, these systems still support publickey authentication, which should always be preferred over password authentication where possible.
Looking at the big picture, 95% of SSH endpoints offer publickey authentication. Whether these systems are configured to use it is another question entirely. What is perhaps somewhat disheartening is that, while 95% of endpoints support the most secure mechanism, approximately 92% still support some form of password authentication as well.
FIGURE 2 - Distribution of SSH authentication method combinations.
Dupes and Duplicity #
SSH servers identify themselves by way of an SSH host key pair. Just as key pairs allow users to prove their identity, so too do host keys allow servers to prove their identity to users. Or at least prove their possession of the correct key.
This functionality is critically important. Without it, users could be tricked into thinking that they had logged into a totally different, possibly spoofed or malicious, system, with obvious security ramifications. However, unlike TLS, most SSH servers are not configured to use any form of Public Key Infrastructure (PKI) or other chain-of-trust to establish proof of server identity. Such functionality is available, but is not in widespread use.
Instead, most SSH clients will use a technique called Trust on First Use (TOFU). In this scheme, the client will trust a host key the first time it receives it for a given host. Going forward, if the host key changes, the SSH client can alert the user to the problem. While this doesn’t allow the user to confirm the host’s identity, it at least allows them to confirm that the host’s identity hasn’t changed.
ubuntu@u2404-infra-02: ̃$ ssh 192.168.50.127 The authenticity of host ‘192.168.50.127(192.168.50.127)’ can’t be established. ED25519 key fingerprint is SHA256:wdNLQA-2vyp6Qv+8T7Ac2rF6vRJz34P5RCQo9VJAa+Ms. This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])? █
While host keys are ostensibly used to uniquely identify a host, oftentimes multiple hosts have the same host key. This is sometimes intentional, such as when automatically provisioning many ephemeral systems. Unfortunately, it can also happen accidentally, such as during virtual machine image cloning, and this can have very undesirable consequences since it undermines the concept of key trust.
We performed a limited audit to see how frequently host keys were being reused across our data set. We identified more than 350 instances where the same host key was shared across unrelated environments. Further exploration across the wider Internet revealed thousands of additional shared host keys. These are often the result of a vendor generating keys as part of an operating system (OS) image instead of regenerating them when the OS first boots or is provisioned for the customer. In the case of publicly available VM images or hardware, malicious actors could collect the key pairs from the images and use them in attacks. The real world impact would be that malicious actors with certain network access could perform spoofing or meddler-in-the-middle attacks to force users or automation to interact with them instead of the intended targets.
FIGURE 3 - Reuse of individual keys across our data set by device type.
Auditing SSH key reuse #
runZero scans attempt to collect information for all SSH key types. This allows our customers to audit the keys types in use as well as how the specific keys are used across their environments.
FIGURE 4 - A partial screenshot of runZero showing the SSH key information collected.
runZero has a Service attributes report that can help our customers audit key reuse. There are two ways to access this report. The first way is to go to the Reports section and run the Service attributes report for a specific key field. We recommend using the sha256 hash for the key type. For example, in the case of RSA keys the service attribute ssh.hostKeyRSA.sha256.
FIGURE 5 - A partial screenshot of runZero showing how to launch the Service attributes report.
FIGURE 6 - A partial screenshot of runZero showing the output of the Service attribute report for ssh.hostKeyRSA.sha256.
Customers can then click on the key hash on the left to see where it is used. This is a Service report so it is important to keep in mind that the same key may be seen across multiple services or addresses on the same asset.
The second way to view the report is by viewing the SSH service on an asset and clicking the magnifying glass next to the attribute name (green square in Figure 7). This will take customers directly to the report.
FIGURE 7 - A partial screenshot of runZero showing the attribute name and value.
Clicking on the magnifying glass next to the value (blue square in Figure 7) will show every place that this particular key is used.
Remember to download the runZero Research Report to learn more about the state of asset security.
Not a runZero customer yet? Start a free trial and gain complete asset inventory and attack surface visibility in minutes.
