The Secure Shell (SSH) implementation library, the Libssh, is affected by a four-year-old severe vulnerability that could be exploited by attackers to completely bypass authentication and take over a vulnerable server without requiring a password.
The flaw is an authentication-bypass vulnerability that was introduced in Libssh version 0.6 released in 2014,
The issue tracked as CVE-2018-10933 was discovered by Peter Winter-Smith from NCC Group, it ties a coding error in Libssh.
The exploitation of the flaw is very trivial, an attacker only needs to send an “SSH2_MSG_USERAUTH_SUCCESS” message to a server with an SSH connection enabled when it expects an “SSH2_MSG_USERAUTH_REQUEST” message.
“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 authentciate without any credentials.” reads the security advisory.
The library fails to validate if the incoming “successful login” packet was sent by the server or the client, and also fails to check if the authentication process has been successfully completed.
This means that if a remote attacker sends the “SSH2_MSG_USERAUTH_SUCCESS” response to libssh, the library considers that the authentication has been successfully completed.
Thousands of vulnerable servers are exposed online, by querying the Shodan search engine we can see that more than 6,500 servers are affected by the issue.
But before you get frightened, you should know that neither the widely used OpenSSH nor Github’s implementation of libssh was affected by the vulnerability.
The Libssh maintainers addressed the flaw with the release of the libssh versions 0.8.4 and 0.7.6.
Experts pointed out that GitHub and OpenSSH implementations of the libssh library are not affected by the flaw.
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.
— GitHub Security (@GitHubSecurity) October 17, 2018