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:
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.
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.
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 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.
Remember to download the runZero Research Report to learn more about the state of asset security.
About Version 2 Digital
Version 2 Digital is one of the most dynamic IT companies in Asia. The company distributes a wide range of IT products across various areas including cyber security, cloud, data protection, end points, infrastructures, system monitoring, storage, networking, business productivity and communication products.
Through an extensive network of channels, point of sales, resellers, and partnership companies, Version 2 offers quality products and services which are highly acclaimed in the market. Its customers cover a wide spectrum which include Global 1000 enterprises, regional listed companies, different vertical industries, public utilities, Government, a vast number of successful SMEs, and consumers in various Asian cities.
About runZero
runZero, a network discovery and asset inventory solution, was founded in 2018 by HD Moore, the creator of Metasploit. HD envisioned a modern active discovery solution that could find and identify everything on a network–without credentials. As a security researcher and penetration tester, he often employed benign ways to get information leaks and piece them together to build device profiles. Eventually, this work led him to leverage applied research and the discovery techniques developed for security and penetration testing to create runZero.
)
)
)
)
)
)
)
)
)
