lambdafu

Our attack exploits that SSH does not authenticate the entire handshake, but only parts of it, and that sequence numbers carry over to the encrypted channel. This allows an attacker to insert a message into the handshake while dropping one from the secure channel. Here is an example where the attacker uses IGNORE to drop EXT_INFO. This downgrades client authentication algorithms, and disables keystroke timing countermeasures in OpenSSH 9.5.

In AsyncSSH v2.14.0 and earlier, the attacker can even control EXT_INFO, or log the victim into an attacker controlled shell. Affected are ChaCha20-Poly1305 and Encrypt-then-MAC modes like CBC-EtM and CTR-EtM. These are supported by 77% of SSH servers on the internet - 57% list one of them as their preferred choice. Fixing this requires changes to the specification. OpenSSH implements a new "strict kex" countermeasure that has been adopted by other vendors. Check your vendor for updates!

Using recent versions of the attack by Albrecht/Heninger, we can calculate the private key from 58 PuTTY P-521 signatures with a 50% probability (59 sigs: 94% success, 60 sigs: 100% success). https://eprint.iacr.org/2020/1540 Shout out to Julian Nowakowski for helping us understand the math!

@floris Thanks! It brings a bit of color into the world for sure. 🐢

Each (EC)DSA signature needs a secret number only used once ("nonce"). If the nonce is revealed, reused, or in biased (not fully random), an attacker can use the signatures to recover the private key, which is bad. So, randomness and secrecy of nonces is super important.

Many programs use random nonces 🎲, but some, including PuTTY, generate them deterministically 🧮from the private key and the message to be signed. PuTTY uses SHA-512(ID || SHA-512(x) || SHA1(m)) modulo group size as a pseudo-random nonce. Can you see a problem? 🤔

For DSA (160 bit) and ECDSA P-256/P-384, the modulo is so small that a 512 bit number wraps around often, and the output looks pseudo-random. Not so for P-521! Here the modulo is a no-op, and the high 9 bits of the nonce are always zero! This is enough to allow an attack!

The attack on ECDSA with biased nonces is a standard technique. An attacker collects at least 521/9≈58 signatures from signed Git commits or victim logins into the attacker's SSH server. A bit of math allows the attacker to calculate the private key offline.

PuTTY 0.81 has been fixed to use a more secure nonce generation (RFC6979 by Thomas Pornin). Filezilla Client 3.67.0 also includes a fixed version of PuTTY. Git Tortoise and WinSCP also ship with a bundled PuTTY, but no update is available yet. 🤞

@hanno Yes, GCM derives the invocation counter only from the IV and a counter that starts at zero, ignoring the SSH standard. The RFC explains that because it is a constant offset from the actual sequence number, that should not be an issue. But in fact, this prevents the attack!

@hanno We added it to the FAQ, thanks for the suggestion!