A GitHub commit was the start of the disclosure of a vulnerability in OpenSSH (CVE-2018-15473) that leads to username disclosure.

It's not that a special command or packet will dump all the usernames. Rather, a specially crafted authentication packet must be send with the username to test, and from the reply/lack of reply you'll know if that username exists or not on said server.

After establishing an encrypted connection, a client can send a SSH2_MSG_USERAUTH_REQUEST (type publickey) message to an OpenSSH server with a malformed packet. The malformation is a string that is larger than the message, for example. When the userauth_pubkey function processes this message, it will first check if the username exists. If it does not, it returns value 0 immediately. Otherwise, the key provided in the message is checked, and a positive test leads to authentication (return value 1), otherwise the return value will be 0.

The functions that act on message SSH2_MSG_USERAUTH_REQUEST and call the appropriate authentication functions (like userauth_pubkey), will eventually send back a message to the client: authenticated (SSH2_MSG_USERAUTH_SUCCESS) or not (SSH2_MSG_USERAUTH_FAILURE).

But function userauth_pubkey can be forced into doing something else than returning 0 or 1: it can be forced to trigger a call to function fatal. This function generates a fatal alert event that is logged, and then it terminates the OpenSSH process without sending anything back to the client. This behavior can be triggered by sending a SSH2_MSG_USERAUTH_REQUEST (type publickey) message with a string that "claims" to be larger than the message itself, for example (strings encoded in messages are composed of 2 elements: a 4-byte, big-endian integer, encoding the length of the string, and a variable-length array of bytes, with the content of the string).

This is exactly what PoC Python program ssh-check-username.py does: it sends a SSH2_MSG_USERAUTH_REQUEST (type publickey) message with a username plus an algorithm string that is not properly encoded. If the username does not exist, SSH2_MSG_USERAUTH_FAILURE is send back to the client. If the username exists, the message is parsed further before the public key verification occurs. This parsing uncovers a malformed string, and the program decides to abort without sending back any message. This is how the PoC Python can check the existence of a username: if it receives SSH2_MSG_USERAUTH_FAILURE, the username does not exist, and if it receives no message and the connection is closed, then the username exists.

This vulnerability exists in the public key authentication function, but also in the host authentication and gss authentication functions. Fixing this consists essentially in reversing the actions performed by these functions: first do a full parsing of the message, then check for the existence of a username.

You can mitigate these vulnerabilities before patches have been released and applied, by disabling the vulnerable authentication methods, like public key authentication. But please do this only if you don't use public key authentication. If you do, then continue to use it, don't disable it! It is, after all, "just" an information disclosure vulnerability that can confirm the existance of a username.

It's also possible to monitor your authentication logs for exploitation of this vulnerability. A fatal event will be logged, with a message like "ssh_packet_get_string: incomplete message". This message can vary according to your OpenSSH version (this example message is taken from a Ubuntu machine) and according to the exploit used. This example message is generated when the Python PoC exploit is used.

The message does not contain any identifier of the attacker. If you want IP addresses, you can increase your LogLevel from INFO to VERBOSE, but be aware that it will increase the amount of events and that you need the capacity to handle the increase in events.

If you are interested, I have a PCAP file. The first stream is a successful username check, the second stream a failed one.

Didier Stevens
Senior handler
Microsoft MVP
blog.DidierStevens.com DidierStevensLabs.com