Threat Level: green Handler on Duty: Didier Stevens

SANS ISC: Internet Storm Center - SANS Internet Storm Center Internet Storm Center


Sign Up for Free!   Forgot Password?
Log In or Sign Up for Free!

Latest Diaries

OpenSSH user enumeration (CVE-2018-15473)

Published: 2018-08-20
Last Updated: 2018-08-20 21:11:40 UTC
by Didier Stevens (Version: 1)
0 comment(s)

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 existance 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 existance 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

0 comment(s)

If you have more information or corrections regarding our diary, please share.

Recent Diaries

Video: Peeking into msg files - revisited
Aug 19th 2018
1 day ago by DidierStevens (0 comments)

Back to the 90's: FragmentSmack
Aug 17th 2018
3 days ago by Remco (1 comment)

Truncating Payloads and Anonymizing PCAP files
Aug 16th 2018
4 days ago by Xme (2 comments)

More malspam pushing password-protected Word docs for AZORult and Hermes Ransomware
Aug 15th 2018
4 days ago by Brad (0 comments)

Microsoft August 2018 Patch Tuesday
Aug 14th 2018
6 days ago by Johannes (0 comments)

New Extortion Tricks: Now Including Your (Partial) Phone Number!
Aug 13th 2018
1 week ago by DidierStevens (2 comments)

View All Diaries →

Latest Discussions

Port 41302 UDP
created Aug 16th 2018
4 days ago by Alvaro (2 replies)

Pfsense Dshield Log sending Issue
created Aug 10th 2018
1 week ago by Anonymous (0 replies)

Splunk query returns fewer results than expected
created Jul 30th 2018
3 weeks ago by Anonymous (0 replies)

Threat Feed Feedback
created Jul 26th 2018
3 weeks ago by TravisMcW (0 replies)

Windows Long File Path
created Jul 19th 2018
1 month ago by Shishir (0 replies)

View All Forums →

Latest News

View All News →

Top Diaries

Wide-scale Petya variant ransomware attack noted
Jun 27th 2017
1 year ago by Brad (6 comments)

Using a Raspberry Pi honeypot to contribute data to DShield/ISC
Aug 3rd 2017
1 year ago by Johannes (16 comments)

Maldoc with auto-updated link
Aug 17th 2017
1 year ago by Xme (2 comments)

Second Google Chrome Extension Banker Malware in Two Weeks
Aug 29th 2017
11 months ago by Renato (0 comments)

Detection Lab: Visibility & Introspection for Defenders
Dec 15th 2017
8 months ago by Russ McRee (2 comments)