Enterprises around the world rely on the SSH protocol to remotely administrate their computer systems. Often SSH is used to transmit data to conduct actions which require the highest of administrative privileges.
Various SSH applications use some of the strongest ciphers available, such as AES128-CBC, Blowfish-CBC, and AES256-CTR. So assuming that the implementation is good, SSH is pretty darn tough to crack. That’s why so many cybersecurity professionals like that technology.
So someone who performs a man-in-the-middle attack on an SSH transmission would have to work tirelessly to turn that ciphertext into useful plaintext. But what if the attacker could avoid all of that work that will likely get them nowhere? What if they could go up to the door and say, “Hey, I live here. Hand me the key.” And then the key is handed to them, just like that. No authentication challenge whatsoever was necessary.
That is just what happened to libssh, a popular SSH implementation. A recently reported vulnerability can be exploited to subvert authentication.
Secure Your SSH Machine Identities With SSH Protect
libssh Vuln: Authenticate Without Credentials
“libssh versions 0.6 and above have an authentication bypass vulnerability in the server code. By presenting the server an SSH2_MSG_USERAUTH_SUCCESS message in place of the SSH2_MSG_USERAUTH_REQUEST message which the server would expect to initiate authentication, the attacker could successfully authenticate without any credentials.”
The vulnerability has existed for about four years. Wow, that’s a lot of risk exposure! I wonder if any cyber attackers knew about it during all of that time?
NCC Group’s Peter Winter-Smith discovered the bug. As reported in Ars Technica, Winter-Smith said:
“The issue is basically a bug in the libssh library, not to be confused with the similarly named libssh2 or OpenSSH projects (especially the latter) which results from the fact that the server uses the same state machine to authenticate clients and servers.
The message dispatching code that processes messages either in client mode or server mode (it’s the same function) doesn’t make sure that the message type received is suitable for the mode it’s running in. So, for example, the server will dispatch messages which are only intended by design for processing client side, even when running in server mode.
The SSH2_MSG_USERAUTH_SUCCESS message is used by the server to inform the client that they were authenticated successfully, it updates the internal libssh state machine to mark the client as being authenticated with the server. What I found was that if the exact same message is sent to the server it updates the state machine to tell the server the client is authenticated.
Technically: I would say that it’s surprising how fairly straightforward bugs with serious consequences can still lurk, and sometimes it pays to take a step back from fuzzing to try to understand how a protocol implementation works.”
Straightforward bugs with serious consequences? That reminds me of 2014’s Heartbleed OpenSSL bug. That was a simple syntax error, and it rendered some OpenSSL implementations pointless.
Other SSH vulnerabilities to watch for
Despite the overall strength of SSH security, there are some SSH vulnerabilities that can leave you exposed. Here are some that you need to watch for and prepare to defend against.
- Exposed Services. Exposing an application service to the internet is a common misconfiguration that allows access to an internal system from anywhere and acts as a common attack vector. Attackers leverage external-facing remote services as a point of entry to an application hosted in the cloud, aiming to compromise the underlying instance.
- Advanced Persistent Threats. Attackers can use already compromised SSH keys and credentials on applications with exposed SSH services. Attackers can gather SSH keys and credentials from source control, public repositories or open buckets or steal them from machines compromised in parallel or unrelated campaigns, or even purchase them on remote access markets where they are sold as-a-service.
- SSH Backdoors. SSH is used by both developers and attackers to ensure their access to the server. Attackers who were able to compromise a machine, can enable the SSH service to allow SSH communication and by that establish persistence on the target. This ensures them to also blend in in legitimate traffic, avoid detection and pass through any firewalls that are in place, since SSH port 22 is normally allowed.
- Encrypted Channel. Adversaries may use legitimate and preinstalled remote access services such as SSH to establish an interactive command and control channel to target systems within networks, since these are normally allowed by application control within a target environment.
Who was impacted by the libssh vulnerability?
One of the most notable users of libssh is GitHub. Due to the way they use libssh, the vulnerability didn’t affect them. GitHub Security said on Twitter:
“While we use libssh, we can confirm that http://GitHub.com and GitHub Enterprise are unaffected by CVE-2018-10933 due to how we use the library.
We use a custom version of libssh; SSH2_MSG_USERAUTH_SUCCESS with libssh server is not relied upon for pubkey-based auth, which is what we use the library for. Patches have been applied out of an abundance of caution, but GHE was never vulnerable to CVE-2018-10933.”
Thankfully a patch has been developed, and libssh developers have released it on their website. libssh users must update to either version 0.8.4 or version 0.7.6.
Regardless of how quickly organizations are able to patch it, this vulnerability raises important questions about SSH key security. “A compromised SSH key in the wrong hands can be extremely dangerous,” said Nick Hunter, senior technical manager for Venafi in a previous Venafi blog, “Cybercriminals can use them to access systems from remote locations, evade security tools, and often use the same key to access more systems. Based on these results, it’s very clear that most organizations have not implemented SSH security policies and restricted SSH access configurations because they do not understand the risks of SSH and how it affects their security posture."
How to protect against SSH vulnerabilities
Here are some common practices you can use to defend your organization against exposure from SSH vulnerabilities, such as that found in libssh.
- Own all keys between jump server and asset: Maintain a solid inventory of all assets and their keys used from the jump host. These are your prime routes to and from, so they need to be inventoried and each key pair must be unique. Keys pointing to other assets outside the zone should be known and if their specific purpose can’t be determined, they should be removed.
- Monitor key deployment: Remote users will and should deploy new keys on the jump server. It is critical to monitor this at all times and get insights into when and where keys are generated and by whom. It may also be a good practice to regularly clean up keys from the remote users to the jump server, as their exposure there is very high. Also, any new key installed on the jump server from a suspicious location (i.e. a geo where company is not active) should be detected, removed and investigated.
- Eliminate unused or orphaned keys: Any key inside the “perimeter” not in use for a certain time period (let’s say 90 days) or keys where the private part is unknown should be removed. Full stop
- Rotate: Rotation is part of a cybersecurity defense mechanism and reduces the risk that when a key part gets into the wrong hands, it may fall victim of nefarious use after the rotation. During these challenging times, SSH keys inside the perimeter should be rotated on a higher frequency. Weekly for “root” or highly privileged keys, monthly for all others looks acceptable practice.
- Report and Communicate: Just as any part of the IT infrastructure, SSH usage should be reported on. Regularly. Building a set of metrics and sharing them with peers (Risk, InfoSec) helps create a mindset and perhaps an incentive to building out stronger SSH policies.
(This post has been updated. It was originally published on October 18, 2018.)
Get a FREE & Confidential SSH Risk Assessment from Venafi!
Related posts