New libSSH vulnerability gives root access to servers

A libSSH vulnerability that went undisclosed for nearly five years can give malicious actors an easy access to administrative control over devices through SSH server processes.

Peter Winter-Smith, security consultant at NCC Group, discovered the authentication bypass flaw (CVE-2018-10933) in libSSH -- a library used to implement the SSH protocol in both client and server applications -- and disclosed it to the libSSH team in late June. The patch was developed in mid-September and the update package was released Oct. 16.

Winter-Smith wrote on Twitter that the cause of the libSSH vulnerability "is that the libSSH server and client share a state machine, so packets designed only to be processed by and update the client state can update the server state." In practice, Winter-Smith said the most straightforward attack would be an authentication bypass, but "the entire state machine is at flaw here so there may be other, more subtle, methods of exploitation."

Amit Serper, head of security research at Cybereason, based in Boston, clarified that the libSSH vulnerability specifically affected SSH server software processes -- not necessarily server computers -- that run on "embedded devices and many proper computers as well."

Will Dormann, vulnerability analyst at CERT/CC, noted that GitHub uses libSSH in SSH server mode, but GitHub confirmed its environment is not affected by the libSSH vulnerability.

We use a custom version of libssh; SSH2_MSG_USERAUTH_SUCCESS with libssh server is not relied upon for pubkey-based auth, which is what we use the library for.  Patches have been applied out of an abundance of caution, but GHE was never vulnerable to CVE-2018-10933.

— GitHub Security (@GitHubSecurity) October 17, 2018

The libSSH vulnerability was introduced with version 0.6 of the library, released on Jan. 8, 2014, and Serper said his latest check via Shodan found more than 6,000 devices at risk of exploit, many of which are embedded devices such as printers, routers, modems and NAS devices. However, Serper said detecting an exploit of this issue could be tricky.

"You can SSH into your device (assuming that you get a native Linux shell) and see who's connected. You can also look at the list of currently running processes and see if you can spot any weird processes that shouldn't be there," Serper wrote via Twitter direct message. "However, this advice is not a good one since not many people know what exactly should or should not be running on their embedded device. The trivial thing is to look at traffic on the SSH port. Because if by default, for example, no one connects to your NAS through SSH and all of a sudden there's a spike then there's something going on."

Serper said detecting an exploit was made more difficult because many affected embedded devices don't keep logs because of limited storage space.

Winter-Smith added in his advisory that servers not vulnerable to an authentication bypass attack via the libSSH vulnerability "may still be vulnerable to other unexpected state manipulation issues, so it is imperative that all services built on top of libSSH are updated."

Winter-Smith said the best mitigation for servers would be to update the libSSH library to version 0.7.6 or higher. Serper said disabling SSH might be possible on some embedded devices.

"If there is no option to turn off the SSH on the product (for example some routers don't have the option to turn off SSH) sometimes it's possible to forward the SSH port to a non-existent IP in the LAN," Serper wrote. "I'd also suggest to scan your own IP with Shodan and see if SSH is exposed with libSSH."