An academic study has shown how it's possible for someone to snoop on certain devices' SSH connections and, with a bit of luck, impersonate that equipment after silently figuring out the hosts' private RSA keys.

By impersonating these devices, in a man-in-the-middle attacks using those deduced private host keys, the spy would be able to quietly observe users' login details and, by forwarding the connections to the real equipment, monitor those users' activities with the remote SSH servers. SSH is typically used to log into a device and control it via a command-line interface though there are other uses.

We're told the private host RSA keys can be obtained by passively surveiling connections from clients to a vulnerable device's SSH server: accidental or naturally occurring computational errors during signature generation can be observed and exploited to calculate the SSH server's ideally secret private host key.

By naturally occurring errors we mean errors caused by cosmic rays and other little glitches that flip bits, and by accidental we mean poorly implemented RSA signature generation algorithms. You'd think the former would occur so rarely that no one would be able to take advantage of it realistically, and the latter would already be known about, but we're assured that if you monitor enough SSH connections to a vulnerable SSH server, you'll eventually see one that you can exploit.

It's important to state here that the software libraries OpenSSL and LibreSSL, and thus OpenSSH, are not known to be vulnerable to the aforementioned key deduction method. That means, in our view, the vast majority of devices, servers, and other equipment on the internet are not at risk, and what you're left with is some Internet-of-Things and similar embedded gear susceptible to attack. It also only affects RSA keys.

Details

The study [PDF] was carried out and written up by Keegan Ryan, Kaiwen He, George Arnold Sullivan, and Nadia Heninger of University of California, San Diego (Kaiwen He is also at MIT.) The technique the team used to discern the private RSA keys stemmed from TLS-smashing research by Florian Weimer in 2015 as well as work in 2022 by a couple of the San Diego paper authors and other research going back decades to the 1990s.

Infosec guru Thomas Ptacek, who spoke highly of the 2023 study's co-author Nadia Heninger, shared a summary of the RSA key paper here if you need an easy-to-understand breakdown of the issue. We also owe a hat-tip to ex-Register vulture Dan Goodin, who alerted us via Ars Technica on Monday to the UC San Diego paper.

Essentially, when a client connects to a vulnerable SSH server, during their negotiations to establish secure and encrypted communications, the server will generate a digital signature for the client to check to ensure it is talking to the server it expects to be talking to.

That signature calculation can be glitched randomly or accidentally, as we described above, in a way that clever algorithms can work out from the bad signature the server's private RSA key, which is used in the signature generation. A countermeasure is to ensure the signature is correct before emitting it to the client; OpenSSL and LibreSSL already do this.

As the paper's authors put in their abstract:

"A passive adversary can quietly monitor legitimate connections without risking detection until they observe a faulty signature that exposes the private key," the team concluded. "The attacker can then actively and undetectably impersonate the compromised host to intercept sensitive data."

The boffins said they scanned the internet, and scoured previously collected SSH scan data, to measure the prevalence of vulnerable signatures, and claimed their dataset of some 5.2 billion SSH records, covering more than seven years of observations, contained more than 590,000 invalid RSA signatures.

Using their lattice key recovery technique, the academics said more than 4,900 of those flawed signatures revealed the factorization of the corresponding RSA public key, which they used to derive the private RSA keys to 189 of those public keys.

During their research, the authors found four manufacturers whose products were vulnerable to this type of key sleuthing: Cisco, Zyxel, Hillstone Networks, and Mocana. The researchers disclosed the issue to Cisco and Zyxel, and note both vendors "investigated promptly." 

Cisco determined that its ASA and FTD software fixed the issue in 2022, and, prior to the paper's publication, "was investigating mitigations" for IOS and IOS XE software. 

Meanwhile, Zyxel concluded the flaw only affected its end-of-life firmware, and by that point it had begun using the non-vulnerable OpenSSL, which as we said is immune to this issue. The researchers say they were unsuccessful in attempts to contact Hillstone Networks and Mocana, and instead submitted the issue to the CERT Coordination Center.

An SSH server implementation declaring itself as "SSH-2.0-SSHD" is also said to be vulnerable, and this may be in use by some enterprise-grade Java applications. As the key-deducing technique revolves around PKCSv1.5, DNSSEC that uses PKCSv1.5-RSA signatures may also be at risk.

They also noted that the dataset of signatures in IPsec connections wasn't large enough to conclude whether this protocol is vulnerable to a similar key leak: "Given the rarity of vulnerable signature faults, we are not able to conclude much about IPsec implementations from our data, and believe this question deserves further study." ®

https://www.theregister.com//2023/11/14/passive_ssh_key_compromise/