Our analysis of active scan data revealed five unique SSH version strings that produced signatures resulting in factored keys, detailed in Table 3. The most prevalent software version is the “Zyxel SSH server” with 4873 vulnerable signatures followed by “SSHD” with 87. “Mocana SSH 5.3.1” and “Cisco-1.25” both generated a single vulnerable signature. We examined the behavior of hosts using these version strings over time. In particular, once a private key is exposed by a faulty signature, how long does the host continue to use that key? We also want to classify the nature of the errors; that is whether the error is permanent (all future signatures are faulty) or transient (the host generates valid signatures after the fault).
Credit:
Ryan, et al.
Version strings in SSH signatures identifying four vendors revealing private keys.
Credit:
Ryan, et al.
Credit:
Ryan et al.
Classifications of potentially faulty hosts using their public key and classified host versions based on whether they never, always, or intermittently produced signatures exposing private keys.
Credit:
Ryan et al.
Once attackers have possession of the secret key through passive observation of traffic, they can mount an active Mallory-in-the-middle attack against the SSH server, in which they use the key to impersonate the server and respond to incoming SSH traffic from clients. From there, the attackers can do things such as recover the client’s login credentials. Similar post-exploit attacks are also possible against IPsec servers if faults expose their private keys.
The root cause of the faults is not well understood. Some researchers have linked it to flaws in cryptographic accelerators in one study from Zyxel and Hillstone, two of the manufacturers identified in this month’s study.
Paper co-author Ryan wrote:
We think there are multiple different underlying causes for the faults we observed in different vendor implementations, because of how some devices were able to recover by generating correct signatures after generating a faulty signature, but other devices did not.
These are challenging issues to debug as well. Without having the exact software version and physical devices that created the faulty signatures, there’s not many leads to investigate, and vendors are limited to ensuring proper mitigations against fault attacks are in place in the latest firmware versions.
So we don’t have information specific to what caused the faults we observed, but we can speculate about a number of different possible causes: software bugs resulting in incorrect math operations in rare conditions, software bugs resulting in memory corruption, failing NVRAM or other hard disk storage, or bit errors in DRAM or other memory.
Whether or not an attacker can induce such faults depends on the root cause. For example, Rowhammer is an example of an attack where the attacker may be able to remotely trigger bit flips in DRAM. For an implementation with a memory safety vulnerability, an attacker could hypothetically remotely trigger a heap overflow that corrupts key data stored in memory.
The important thing is that a single flip of a bit—in which a 0 residing in a memory chip register turns to 1 or vice versa—is all that’s required to trigger an error that exposes a secret RSA key. Consequently, it’s crucial that the countermeasures that detect and suppress such errors work with near-100 percent accuracy. Ryan also said that secret keys in post-quantum algorithms may be similarly vulnerable to exposure caused by computational errors.
