OpenSSH logo

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].

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.

Related Articles:

Tumblr Fixes Security Bug that Leaked Private Account Info

Hacker: I'm logged in. New LibSSH Vulnerability: OK! I believe you.

Facebook States 30 Million People Affected by Last Month's "View As" Bug

Facebook Vulnerability Affecting 50 Million Users Allowed Account Takeover

WhatsApp Fixes Vulnerability That’s Triggered by Answering a Call.