真的，宇宙射线会导致部分 SSH 服务器的私钥泄露
密钥 SSH
![](/data/attachment/album/202311/16/115713c1i4nfkv3w1n1gb3.png)



> 
> 如果你是 OpenSSL、LibreSSL、OpenSSH 的用户，你可以坐下来看看了，因为这不会影响你。
> 
> 
> 


最近一项学术研究展示了如下情况：对于某些特定设备，他人可以监听其 SSH 连接，然后借助一些运气在无声无息中破译出主机的私有 RSA 密钥，从而冒充该设备。


冒充这些设备后，通过使用推断出的主机密钥私钥实施的中间人攻击，间谍可以安静地记录用户的登录信息，同时，通过将这些连接转发给真正的设备，他们还可以监控用户在远程 SSH 服务器上的活动。尽管 SSH 还有其他功能，但其主要应用场景仍然是用户登录到设备并通过命令行接口进行控制。


据悉，可以通过被动监视从客户端到易受攻击设备的 SSH 服务器的连接，获得主机的 RSA 密钥私钥：无论是在签名生成过程中的偶发运算错误，还是因宇宙射线等微小故障产生的自然错误，都可以被观察和利用来推算 SSH 服务器的主机密钥私钥，这本应是保密的。


虽然可能认为自然错误发生的概率很小，偶发错误可能已为众所周知，但实际上只要你连续观察足够多的到有漏洞的 SSH 服务器的 SSH 连接，你就有可能发现一个你可以利用的。


重要的一点是，软件库 OpenSSL 和 LibreSSL，以及 OpenSSH，都未发现存在上述密钥推导问题的漏洞。由此，我们认为，网上的大部分设备、服务器和其他设备都不会受到影响，只有特定的物联网设备和类似的嵌入式设备可能会对此种攻击敏感。此外，这种问题也仅影响 RSA 密钥。


### 细节


由加利福尼亚大学圣地亚哥分校的 Keegan Ryan、Kaiwen He（他同时也在麻省理工学院任职）、George Arnold Sullivan 以及 Nadia Heninger 基于早期的一些研究，完成并撰写了这项研究。他们采用的技术，旨在揭示 RSA 密钥私钥，该技术源于 Florian Weimer 在 2015 年对 TLS 的突破性研究，以及 2022 年圣地亚哥论文的几位作者以及其他研究者的一些工作，这些工作可追溯到 1990 年代。


信息安全专家 Thomas Ptacek 曾高度赞扬了 2023 年研究的合著者 Nadia Heninger，并在此分享了 RSA 密钥分析论文的摘要，以便于理解这个问题。我们同时也要感谢曾在 Register vulture 工作的 Dan Goodin，他在周一通过 Ars Technica 向我们报告了 UC 圣地亚哥论文的消息。


基本上，当客户端尝试连接到一个容易受到攻击的 SSH 服务器时，它们在协商建立全面安全加密通信的过程中，服务器将会生成一个数字签名以供客户端检查，以确保其正在与预期的服务器通信。


如我们之前所述，这个签名的计算过程可能会随机或意外地产生错误，聪明的算法可以从错误的签名中推导出服务器的私有 RSA 密钥，此密钥用于签名生成。对此的一种防范措施是在将签名发送给客户端前确保其计算正确；OpenSSL 和 LibreSSL 已经在实施这种防范。


正如论文作者在他们的摘要中提到的：



> 
> “我们证明了一种可能性：若 SSH 服务器在进行签名计算过程中出现自然故障，一名被动的网络攻击者便有机会获得其私有 RSA 主机密钥。
> 
> 
> 在之前的研究中，我们通常认为这对于 SSH 协议是不可行的，因为签名中包含了一些信息，比如 Diffie-Hellman 共享密钥，这些信息对于被动的网络观察者来说无法获得。
> 
> 
> 然而，我们证明了，在 SSH 中经常使用的签名参数下，如果出现了签名错误，我们便能有效地使用 <ruby> 格攻击 <rt>  lattice attack </rt></ruby> 来恢复私钥。
> 
> 
> 我们对 SSH、IKEv1、IKEv2 协议进行了安全分析，在此场景下，我们利用我们的攻击方法在现实环境中挖掘出几个存在漏洞的独立实现中的数百个被攻破的密钥。
> 
> 
> 


“一个被动的对手可以安静地监控合法的连接，不用冒被检测的风险，直到他们观察到一个包含私钥的错误签名。”研究团队做出了这样的结论：“然后，攻击者可以主动且不会被检测地冒充被攻破的主机，从而截取敏感数据。”


研究人员表示，他们已经扫描了整个互联网，并翻查了以前收集的 SSH 扫描数据，以测量易受攻击的签名的流行程度。他们声称，他们的数据集涵盖了 52 亿条 SSH 记录和超过七年的观察，其中包含了超过 59 万个无效的 RSA 签名。


通过他们的格密钥恢复技术，学者们表示，其中超过 4900 个错误的签名揭示了对应 RSA 公钥的因子分解。他们利用这些信息，推导出了 189 个公钥的私有 RSA 密钥。


在他们的研究中，作者们发现，思科、Zyxel、山石网科和 Mocana 这四个制造商的产品都可能受到这种密钥侦测攻击。研究者已经向思科和 Zyxel 报告了这个问题，观察到两家供应商都迅速进行了调查行动。


思科判定其 ASA 和 FTD 软件在 2022 年已经解决了此问题，且在这篇论文发布之前，公司正在对其 IOS 和 IOS XE 软件进行调查，看看如何应对此问题。


同一时间，Zyxel 发现这个缺陷只影响到了它那些已停止服务的固件，并且它已经开始使用不受此问题影响的 OpenSSL。研究人员表示，他们没有成功地与山石网科和 Mocana 取得联系，所以决定把这个问题提交给了 CERT 协调中心。


据称，自诩为 “SSH-2.0-SSHD” 的 SSH 服务器实现也可能受到攻击，这可能会影响到一些企业级的 Java 应用。有鉴于这个密钥推导技术的关键在于 PKCSv1.5，使用 PKCSv1.5-RSA 签名的 DNSSEC 可能也在风险之中。


他们还指出，他们在 IPsec 连接中收集到的签名数据集不大，所以无法确定此协议是否也可能受到类似的密钥泄漏攻击。他们表示：“鉴于易受攻击的签名故障很罕见，根据我们的数据，我们无法对 IPsec 实现得出多少结论，我们认为这个问题值得进一步研究。”



> 
> 更新：已经与山石网科取得联系，官方确认该问题已在 2015 年发布的相关版本中修复，之后的版本也不存在相关问题。
> 
> 
> 具体详情可以咨询山石网科客服或查看如下链接： 
> 
> 
> [https://www.hillstonenet.com.cn/security-notification/2015/07/28/dsfyj/](https://www.hillstonenet.com.cn/security-notification/2015/07/28/dsfyj/ )  
> 
> 
> 


*（题图：MJ/f94093f0-9ffe-4cf1-82fb-cdac1427e923）*




---


via: <https://www.theregister.com/2023/11/14/passive_ssh_key_compromise/>


作者：[Jessica Lyons Hardcastle](https://www.theregister.com/Author/Jessica-Lyons-Hardcastle) 译者：[ChatGPT](https://linux.cn/lctt/ChatGPT) 校对：[wxy](https://github.com/wxy)


OK
# Passive SSH server private key compromise is real ... for some vulnerable gear

## OpenSSL, LibreSSL, OpenSSH users, don't worry – you can sit this one out

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](https://eprint.iacr.org/2023/1711.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](https://www.redhat.com/en/blog/factoring-rsa-keys-tls-perfect-forward-secrecy) 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](https://news.ycombinator.com/item?id=38162996) 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](https://arstechnica.com/security/2023/11/hackers-can-steal-ssh-cryptographic-keys-in-new-cutting-edge-attack/) 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](https://goteleport.com/blog/ssh-handshake-explained/#4-ssh-elliptic-curve-diffie-hellman-reply) 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:

We demonstrate that a passive network attacker can opportunistically obtain private RSA host keys from an SSH server that experiences a naturally arising fault during signature computation.

In prior work, this was not believed to be possible for the SSH protocol because the signature included information like the shared DiffieHellman secret that would not be available to a passive network observer.

We show that for the signature parameters commonly in use for SSH, there is an efficient lattice attack to recover the private key in case of a signature fault.

We provide a security analysis of the SSH, IKEv1, and IKEv2 protocols in this scenario, and use our attack to discover hundreds of compromised keys in the wild from several independently vulnerable implementations.

"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](https://crypto.stackexchange.com/questions/31593/lattice-based-attack-on-rsa) 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.

[Does Windows have a very weak password lurking in its crypto libraries?](https://www.theregister.com/2023/10/26/windows_password/)[ROBOT crypto attack on RSA is back as Marvin arrives](https://www.theregister.com/2023/09/26/robot_marvin_rsa/)[Signal adopts new alphabet jumble to protect chats from quantum computers](https://www.theregister.com/2023/09/20/signal_adopts_new_alphabet_jumble/)[Google Chrome to shield encryption keys from promised quantum computers](https://www.theregister.com/2023/08/12/google_chrome_kem/)

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." ®

12