OpenSSH vulnerability means your keys are OpenPREY

Two vulnerabilities have been discovered (and fixed) in OpenSSH which could have been exploited by hackers to force clients to leak cryptographic keys.

OpenSSH - a suite of security-related network-level utilities
OpenSSH - a suite of security-related network-level utilities

Two vulnerabilities have been discovered (and fixed) in OpenSSH which could have been exploited by hackers to force clients to leak cryptographic keys and potentially expose users to man-in-the-middle attacks.

OpenSSH is one of the most widely used open-source implementations of the Secure Shell Protocol. The vulnerabilities which were patched on Thursday were present in the default configuration of OpenSSH. All users and administrators are advised to update as soon as possible.

SSH keys are a more secure alternative to passwords: you generate a public and private key pair, give the remote server your public key, and keep the private key on your own computer. Then when you next login, the SSH server and client use the keys to identify and authorise you. However, if someone swipes your private key, they can log in as you.

Versions 5.4 to 7.1 of the OpenSSH client are the ones in trouble – a feature enabled by default called ‘Roaming' allows for a restart of an SSH session after a connection was interrupted, but the roaming code contains both an information sharing bug (CVE-2016-0777) and a buffer overflow bug (CVE-2016-0778).

The roaming feature itself is not supported by servers and is meant for the client side – however, hackers could implement it server-side and exploit the information sharing bug to steal the keys.

And to cope with a connection break, the client keeps a buffer in memory that contains the user's private keys. Qualys, the firm that discovered these flaws, say it is possible to extract the cryptographic data, either partially or completely.

To kill off the client info-leak bug, industry experts are recommending an immediate patch and adding the line ‘UseRoaming no' to SSH config files.

In an advisory, the OpenSSH team said, "For OpenSSH >= 5.4 the vulnerable code in the client can be completely disabled by adding 'UseRoaming no' to the global ssh_config(5) file, or to user configuration in ~/.ssh/config, or by passing -oUseRoaming=no on the command line."

Version 7.1p2 of OpenSSH has now been released and it fixes the issue. The problem is that it's now down to IT bods to push all patches to end users, and as we've seen with Heartbleed, that can take a while.

In an email to SCMagazineUK.com, Wolfgang Kandek, CTO of Qualys which originally found the bug, spoke on the severity of it.“It is an Information Disclosure bug, so on the CVSS scale, it probably it does not rank as critical. However, the information disclosed are SSH keys, which are widely used for automation of system administration tasks and interactive logins. Gaining access to these keys would allow an attacker to pose as owner of the keys, often then with system administration privileges. System administrators can typically install anything they want on the target system including backdoors and malware."

He went on to explain that the roaming feature is, “an experimental feature in OpenSSH, only implemented in the client part at the moment. Implemented fully, it would add robustness to SSH sessions and allow one to reconnect. As it is not fully implemented it should be transparent to turn it off in the OpenSSH config file, which is the recommended mitigation for users that cannot patch at this point in time.”

Speaking on the attack possibilities, Kandek says, “An attacker has to control the SSH server to implement the attack. This means the attacker is already at system administrator level on the server that users connect to, which is already an exceptional security situation and should be pretty rare. But if the attacker has control of the SSH server, he can implement the exploit and then gain access to the private keys of the users – these private keys can then be used to impersonate the user and log into other systems. Since SSH is often used to automate system administration processes, getting a such a private key would provide very broad access to an infrastructure.”

In response, Qualys recommends that users, “Patch as quickly as possible. If you cannot patch immediately, set Use Roaming to Off. This should be easy for personal systems, but probably needs testing in automated scenarios to ensure that no unwanted side effects occur – these are unexpected but it makes sense to test that everything still works as normal." 

He warned that if you are going to generate new SSH keys, make sure you have fixed the vulnerability first so you don't end up leaking the keys again. 

Catalin Cosoi, chief security strategist at Bitdefender, recommends immediately updating vulnerable clients. “Although this vulnerability cannot be exploited remotely, we urge all system administrators, tech support staff, and general end-users who connect to potentially untrusted SSH servers to update any vulnerable clients immediately. Other than connecting to untrusted or compromised SSH servers, other attack avenues include DNS manipulations to forward traffic from a legitimate server to a compromised one, social engineering, or even honeypot SSH servers planted by hackers to read the private keys from legitimate ones.”

When asked how old the flaw is, Jacob Ginsberg, senior director of products at Echoworx said, “The vulnerability was introduced in version 5.4 which was released in March of 2010. I believe it went unnoticed for so long because the vulnerability only exists on the end-user side, and was not found in the version used by servers.”

When asked if this is a common problem for open source software, Ginsberg said, “It is a problem common to all software, not just open source. Closed source software may be seen as more secure because it is created in a more secure, closed environment that obfuscates aspects of the software from the wider public. However, the onus of detecting any flaws and addressing them is now almost solely the responsibility of the developer, who may be quick to respond but also may not be. Everyone has access to the guts of open source software, so while it can be examined for vulnerabilities more easily, a wider community is now available to address them.”

Commenting by email to SC, Brian Spector, CEO of MIRACL said, “It went unnoticed because it is an 'experimental' feature, and as such, it probably never got the scrutiny it deserved, because system administrators should never be deploying experimental features, whether in closed source or open source software, into a live production environment.”