A vulnerability affects all versions of the OpenSSH client released in the past two decades, ever since the application was released in 1999.
The security bug received a patch this week, but since the OpenSSH client is embedded in a multitude of software applications and hardware devices, it will take months, if not years, for the fix to trickle down to all affected systems.
Username enumeration bug discovered in OpenSSH
This particular bug was analyzed last week by security researchers from Qualys who spotted a commit in OpenBSD's OpenSSH source code for a bug report submitted by Darek Tytko from securitum.pl.
After analyzing the commit, researchers realized that the code inadvertently fixed a security bug lying dormant in the OpenSSH client since its creation.
This bug allows a remote attacker to guess the usernames registered on an OpenSSH server. Since OpenSSH is used with a bunch of technologies ranging from cloud hosting servers to mandate IoT equipment, billions of devices are affected.
As researchers explain, the attack scenario relies on an attacker trying to authenticate on an OpenSSH endpoint via a malformed authentication request (for example, via a truncated packet).
A vulnerable OpenSSH server would react in two very different ways when this happens. If the username included in the malformed authentication request does not exist, the server responds with authentication failure reply. If the user does exist, the server closes the connection without a reply.
This small behavioral detail allows an attacker to guess valid usernames registered on a SSH server. Knowing the exact username may not pose an immediate danger, but it exposes that username to brute-force or dictionary attacks that can also guess its password.
Because of OpenSSH's huge install base, the bug is ideal for both attacks on high-value targets, but also in mass-exploitation scenarios.
Bug patched last week. PoC code in the wild.
The bug —tracked as CVE-2018-15473— has been patched in the stable version of OpenSSH —1:6.7p1-1 and 1:7.7p1-1— and the 1:7.7p1-4 unstable branch. Patches have also trickled down to Debian, and most likely other Linux distros.
Proof-of-concept code for testing if servers are vulnerable (or attacking them, depends on what side of the barricade you are) has been made available in various locations [1, 2, 3].
Just released a new exploit for CVE-2018-15473 OpenSSH Username Enumeration! You can find it here: https://t.co/EWn4PSyo4F pic.twitter.com/xs7S6eQkG6
— Justin Gardner (@Rhynorater) August 21, 2018
Didier Stevens of NVISO Labs has published a step-by-step tutorial on testing servers against this bug. The blog post also contains information on logging OpenSSH events that may expose attempts of exploiting this bug against vulnerable servers.
Mitigations also available
Sysadmins who can't install patches for various reasons can apply various mitigations, such as disabling OpenSSH authentication and using an alternative means for logging into remote devices.
If this isn't an option and the OpenSSH client is the only way to connect to devices, sysadmins can disable OpenSSH's "public key authentication" method, which is where the vulnerable code resides.
This means sysadmins won't be able to use OpenSSH authentication keys and will have to type their username and password every time they log in via OpenSSH onto a device.
Comments
jikamens - 5 years ago
>If this isn't an option and the OpenSSH client is the only way to connect to devices, sysadmins can disable OpenSSH's "public key authentication" method, which is where the vulnerable code resides. This means sysadmins won't be able to use OpenSSH authentication keys and will have to type their username and password every time they log in via OpenSSH onto a device.
Wow, did you even READ The NVISO summary you linked to? In the very next sentence after it mentions that disabling public key authentication will block this vulnerability, it says, "Of course, we only recommend to disable public key authentication if you don’t use it. If you use it, don’t switch to password authentication, but keep using public key authentication! This is not a remote code execution vulnerability, it is an information disclosure vulnerability."
Disabling public key authentication in favor of username / password authentication is a TERRIBLE idea. Just really, really terrible. Please update your article to reflect this!
LeighdePaor - 5 years ago
One could also enable 2FA using Google Authenticator, it is fairly straightforward although every user would need a smart device. Mitigation: most people using certificate enabled ssh remote connections already have smart devices.
Example: https://www.digitalocean.com/community/tutorials/how-to-set-up-multi-factor-authentication-for-ssh-on-ubuntu-16-04