Skip to main content
banner image
venafi logo

SSH Vulnerability Allows Authentication without a Password

SSH Vulnerability Allows Authentication without a Password

SSH Vulnerability
October 18, 2018 | Guest Blogger: Kim Crawley

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.
 

Learn more about threats facing SSH key management. Read our eBook.
 

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.


Related posts

Subscribe to our Weekly Blog Updates!

Join thousands of other security professionals

Get top blogs delivered to your inbox every week

See Popular Tags

You might also like

quantum cryptography qubit image

Quantum Computing Threatens All Current Cryptography

trump encryption

Will the Trump Administration Succeed in Banning End-to-end Encryption?

HTTP, man-in-the-middle attack, HTTPS, TLS, TLS certificate, phishing attack

Can Attackers Use a New HTTP Exploit to Bypass Your TLS?

About the author

Guest Blogger: Kim Crawley
Guest Blogger: Kim Crawley
Read Posts by Author
get-started-overlay close-overlay cross icon
get-started-overlay close-overlay cross icon
Venafi Risk assessment Form Image

Sign up for Venafi Cloud


Venafi Cloud manages and protects certificates



* Please fill in this field Please enter valid email address
* Please fill in this field Password must be
At least 8 characters long
At least one digit
At last one lowercase letter
At least one uppercase letter
At least one special character
(@%+^!#$?:,(){}[]~`-_)
* Please fill in this field
* Please fill in this field
* Please fill in this field
*

End User License Agreement needs to be viewed and accepted



Already have an account? Login Here

×
get-started-overlay close-overlay cross icon

How can we help you?

Thank you!

Venafi will reach out to you within 24 hours. If you need an immediate answer please use our chat to get a live person.

In the meantime, please explore more of our solutions

Explore Solutions

learn more

Email Us a Question

learn more

Chat With Us

learn more
Chat