While this is a vulnerability, it seems the worst it can do is expose
whether the username exists on the target system. Not the worst type of
vulnerability, but nice to see it's been found.

https://www.bleepingcomputer.com/news/security/vulnerability-affects-all-openssh-versions-released-in-the-past-two-decades/

Vulnerability Affects All OpenSSH Versions Released in the Past Two Decades
By Catalin Cimpanu

August 22, 2018 07:01 AM 2

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.

Posted on Rocksolid Light.

fail2ban is your best friend...

Posted on def4.i2p