This week, the libssh project announced a serious bug in versions of their library released in the last few years.
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 in which the server would expect to initiate authentication, the attacker could successfully authenticate without any credentials.
Some people are calling it the Jedi mind trick hack, in that you say, “I am authenticated” and the server agrees with you. Or, in xkcd terms:
Clearly, this rather fundamental failure to authenticate is a serious hole, and one that the bad guysTM are going to want to try and exploit now that they know about it.
The seriousness of it for the Internet as a whole is mitigated by the fact that libssh is not used on many Linux servers to handle ssh connections. (They use openssh instead), but libssh is used by some. (e.g. GitHub reported that they use but but were not affected. It is also used by various networked devices that have a Linux-based control plane, including some devices by F5 that are known to be vulnerable) Needless to say, figuring out if your server or network device is vulnerable and, if so, when and how to patch it, is going to be a non-trivial task.
Fortunately, ThreatSTOP protected networks have a bit more latitude if they are using any of our targets that include SSH attackers. (The standard “Inbound Attacks Tier 1” target and the expert ones such as the “TS Curated - SSH Crackers Attacks – IP” or “DenyHosts”) This is because scanners for this vulnerability will look exactly like scanners for almost any other SSH vulnerability. In fact, it is highly likely that they will be the exact same scanners that are used for regular SSH cracking.
Ready to try ThreatSTOP in your network? Want an expert-led demo to see how it works?