OpenSSH Patches Flaw That Lets Attackers Steal Private Keys
Flaw exists in an a feature that is turned on by default in all OpenSSH clients between versions 5.4 and 7.1, says Qualys
January 15, 2016
![](https://eu-images.contentstack.com/v3/assets/blt6d90778a997de1cd/bltc94608acf452fd67/655cf371ab171e040a838b2a/329050_DR23_Graphics_Website_V5_Default_Image_v1.png?width=1280&auto=webp&quality=95&format=jpg&disable=upscale)
OpenSSH has patched a vulnerability that could allow an attacker to steal the private cryptographic keys that are used by client computers to authenticate access to different systems.
The flaw exists in an undocumented feature in all OpenSSH versions between 5.4 and 7.1, security vendor Qualys, which discovered the flaw, and OpenSSH, said in two separate advisories this week. An attacker that exploited the issue would potentially be able to steal the private keys of users and then impersonate them to log into other systems.
“The information disclosed [is] SSH keys, which are widely used for automation of system administration tasks and interactive logins,” Qualys CTO Wolfgang Kandek said in a statement, accompanying the alert.
“Gaining access to these keys would allow an attacker to pose as [the] owner of the keys, often then with system administration privileges,” Kandek noted. Such access would allow the attackers to install anything they wanted on the vulnerable system including malware and backdoors.
One big caveat though is that in order to exploit the flaw, an attacker has to have actual administrative control of an SSH server, he said. It is only when a user with a computer running OpenSSH connects to a malicious SSH server, or a server that has been compromised, that the vulnerability can be exploited. The likelihood of that happening should be pretty rare, Kandek noted.
The problem exists in OpenSSH client code starting from version 5.4 that provides what OpenSSH described as “experimental support” for resuming SSH-connections that may have been interrupted.
According to Kandek, the goal in including the “roaming” support was to ensure that if the connection between an SSH server and client terminated unexpectedly, the client is able to reconnect and resume the interrupted SSH session. The roaming support is enabled by default on all OpenSSH client versions from 5.4 to 7.1 but is not available on SSH servers. Even so, an attacker with administrative access to an SSH server would be able to exploit the flaw.
Amol Sarwate, director of engineering and head of vulnerability research for Qualys says that flaws like these show how client-side vulnerabilities are not exclusive to software like Adobe, but also to command line software such as OpenSSH.
“Most people forget that when they are connecting to a server using OpenSSH client, the server can adversely affect you using such client-side vulnerabilities,” he says.
OpenSSH is the most commonly used protocol by administrators and server operators to connect to a remote machine in Linux and Unix environments, Sarwate adds.
One way an attacker could exploit the flaw on a large scale is to host a malicious SSH server and get users with OpenSSH clients to connect to it, by blogging about the server or emailing the address to the target audience, Sarwate says. “When victim machines connect to the server using the OpenSSH client, they will be compromised.”
Both Qualys and OpenSSH urged users to apply the patch immediately. In its alert OpenSSH said that turning off the Use Roaming function in the OpenSSH client is also another way to mitigate the risk posed by the vulnerability.
About the Author
You May Also Like
State of AI in Cybersecurity: Beyond the Hype
October 30, 2024[Virtual Event] The Essential Guide to Cloud Management
October 17, 2024Black Hat Europe - December 9-12 - Learn More
December 10, 2024SecTor - Canada's IT Security Conference Oct 22-24 - Learn More
October 22, 2024