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.
libssh is a popular SSH implementation, and a recently reported vulnerability can be exploited just like that.|
“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.
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 quickly can you repair vulnerabilities with your SSH keys?
Learn more about machine identity protection. Explore now.