Pierluigi Paganini August 29, 2018

Qualys experts discovered that OpenSSH is still vulnerable to Oracle attack, it is affected by the CVE-2018-15919 flaw at least since September 2011.

Security experts from Qualys discovered that OpenSSH is still vulnerable to Oracle attack, it is affected by the CVE-2018-15919 flaw at least since September 2011.

A few days ago the security expert Darek Tytko from securitum.pl has reported a similar username enumeration vulnerability in the OpenSSH client. The flaw tracked as CVE-2018-15473 affects all versions of the software that was released since 1999. The vulnerability could be exploited by a remote attacker to guess the usernames registered on an OpenSSH server.

Researchers from Qualys discovered that another username enumeration vulnerability affects the latest version of OpenSSH, the issue was tracked as CVE-2018-15919.

Qualys researchers discovered the vulnerability while analyzing a commit in the OpenBSD source code.

“While properly reviewing the now-famous OpenSSH commit https://github.com/openbsd/src/commit/779974d35b4859c07bc3cb8a12c74b43b0a7d1e0 we discovered another username-enumeration vulnerability in auth2-gss.c (enabled by default on at least Fedora, CentOS, and Red Hat Enterprise Linux).” reads the security advisory.

“This vulnerability affects OpenSSH versions from 5.9 (September 6, 2011) to the recently released 7.8 (August 24, 2018), inclusive. It is quite similar to CVE-2018-15473 (it is not a timing attack), but it is also markedly different (code excerpts from OpenSSH 7.8p1)”

The issue resides in the auth2-gss.c module that is enabled by default on many Linux distros, including CentOS, Fedora, and Red Hat Enterprise Linux.

When a user tries to authenticate, an attacker receives the same packet whether the user is valid or not as explained in the report.

• “if the user is valid, then “server_caused_failure” is set, “failures” is not incremented, and the attacker can attempt the GSSAPI authentication indefinitely;
• if the user is invalid, then “server_caused_failure” is not set, “failures” is incremented (at line 412), and the server will disconnect the attacker (at line 417) after max_authtries authentication attempts (6, by default).”

If the user is valid, then ‘server_caused_failure’ is set,” this is not true when the user that does not exist.

Experts explained that the number of attempts for an invalid user is limited to six, while if a valid user is provided the attacker can attempt the GSSAPI authentication indefinitely.

The latter case allows the attacker to run brute-force attacks on the password.

Experts published the following proof-of-concept code for the CVE-2018-15919 flaw:

diff -pruN openssh-7.8p1/gss-genr.c openssh-7.8p1-poc/gss-genr.c
--- openssh-7.8p1/gss-genr.c    2018-08-22 22:41:42.000000000 -0700
+++ openssh-7.8p1-poc/gss-genr.c        2018-08-22 22:41:42.000000000 -0700
@@ -286,6 +286,7 @@ ssh_gssapi_check_mechanism(Gssctxt **ctx
 
        ssh_gssapi_build_ctx(ctx);
        ssh_gssapi_set_oid(*ctx, oid);
+       return 1;
        major = ssh_gssapi_import_name(*ctx, host);
        if (!GSS_ERROR(major)) {
                major = ssh_gssapi_init_ctx(*ctx, 0, GSS_C_NO_BUFFER, &token, 
diff -pruN openssh-7.8p1/sshconnect2.c openssh-7.8p1-poc/sshconnect2.c
--- openssh-7.8p1/sshconnect2.c 2018-08-22 22:41:42.000000000 -0700
+++ openssh-7.8p1-poc/sshconnect2.c     2018-08-22 22:41:42.000000000 -0700
@@ -701,6 +701,7 @@ userauth_gssapi(Authctxt *authctxt)
        ssh_dispatch_set(ssh, SSH2_MSG_USERAUTH_GSSAPI_TOKEN, &input_gssapi_token);
        ssh_dispatch_set(ssh, SSH2_MSG_USERAUTH_GSSAPI_ERROR, &input_gssapi_error);
        ssh_dispatch_set(ssh, SSH2_MSG_USERAUTH_GSSAPI_ERRTOK, &input_gssapi_errtok);
+       return 1;
 
        mech++; /* Move along to next candidate */

According to the experts from Qualys, the OpenSSH maintainers do not consider the username enumeration vulnerability as critical and for this reason, it hasn’t planned a fix in a short time.

“Open-source developer Damien Miller working on OpenSSH says that system libraries do not treat this type of information disclosure as a threat because usernames are considered the non-secret part of user identity, useless to an attacker without the accompanying password.” states Bleeping Computer.