Risk assessment
Assessing the full severity of the protocol flaw that makes Terrapin possible is hard at this early stage because it depends on a series of variables that change from network to network and that the researchers aren’t privy to.
For the time being, the researchers have devised two ways to wield the prefix truncation attack. One way downgrades some of the extensions parties of OpenSSH and other SSH apps can use to secure connections. For instance, the extension downgrade can disable a countermeasure available starting in October’s release of OpenSSH version 9.5. The extension prevents keystroke timing, a class of attack that can accurately predict typed words by measuring inter-keystroke timings. Terrapin can also override an older extension parameter specifying the use of the SHA2 cryptographic hash function. As a result, SSH will instead use the weaker SHA1.
Another way that Terrapin allows the exploitation of the previously unknown vulnerabilities was mentioned earlier regarding AsyncSSH, an SSH implementation for Python with an estimated 60,000 downloads per day. One of the vulnerabilities, CVE-2023-46445, can be exploited to replace the extension information message sent by the server, letting the attacker control its content. This is a bit more severe than just dropping the message (as in the general attack). Exploits work when a client using AsyncSSH connects to a server using any type of SSH software while the two transmit an “EXTINFO” message, as spelled out in the SSH protocol.
The advisory for CVE-2023-46445 explains:
The rogue extension negotiation attack targets an AsyncSSH client connecting to any SSH server sending an extension info message. The attack exploits an implementation flaw in the AsyncSSH implementation to inject an extension info message chosen by the attacker and delete the original extension info message, effectively replacing it.
A correct SSH implementation should not process an unauthenticated extension info message. However, the injected message is accepted due to flaws in AsyncSSH. AsyncSSH supports the server-sig-algs and global-requests-ok extensions. Hence, the attacker can downgrade the algorithm used for client authentication by meddling with the value of server-sig-algs (e.g. use of SHA-1 instead of SHA-2).
Terrapin allows the exploitation of CVE-2023-46446 when a client using any SSH app connects to a sever running AsyncSSH. Exploits allow an attacker to control the remote end of an SSH client session by either injecting or removing packets or emulating the shell established.
“In the worst case, the AsyncSSH server starts a shell for the authenticated user upon connection, switching the user to the authenticated one,” the advisory for CVE-2023-46446 states. “In this case, the attacker can prepare a modified shell beforehand to perform perfect phishing attacks and become a MitM at the application layer. When the username of the authenticated user is not used beyond authentication, this vulnerability does not impact the connection’s security.”
In the absence of Terrapin, an attempt to exploit either AsyncSSH vulnerability would result in an error that would cause the connection to fail before a secure channel could be established. This safeguard is removed as a result of the prefix truncation, which realigns sequence numbers to allow for message injection in the first place.
The truncation is possible because of the way that SSH goes about ensuring the integrity of the connection handshake. To prevent any messages from being injected or removed during this crucial phase, the BPP assigns a sequence number to each one. Both the client and server maintain distinct counters that start at zero and are incremented each time a binary packet is sent or received. As denoted by the numbers in bold shown in the diagram above, the number of messages sent by the client (denoted by Snd in the client column) must equal the number of messages received by the server (denoted by Rcv in the server column). Similarly, the number of server Snds must be equal to the number of client Rcvs.
In SSH, sequence numbers can only be incremented. By contrast, protocols such as TLS, IPsec, and IKE will reset sequence numbers to zero once an encrypted session is established, avoiding manipulation of sequence numbers by a malicious party within the secure channel. Instead, SSH sequence numbers are monotonically increased and are independent of the encryption state.
The effects of manipulating SSH sequence numbers during the handshake carries over once the secure channel has been established. This prevents SSH connections from failing even when sequence number counters have been manipulated. In the paper, the researchers explain:
The attack takes two steps:
- The attacker uses the RcvIncrease technique to increase C.Rcv by one, e.g., by injecting an IGNORE message to the client before NEWKEYS.
- The attacker deletes the first message SC1 sent by the server.
We first analyze this attack with regard to handshake authentication and sequence numbers. As the key exchange does not protect the handshake transcript from inserting IGNORE messages, handshake authentication is not broken. Before the first step, we have C.Rcv = C.Snd. After the first step, we have C.Rcv = S.Snd + 1, but during the handshake this manipulation is not detected. After the second step, we have C.Rcv = S.Snd, and sequence numbers are back in sync.
It remains to be shown that the attacker can delete the message from the channel, which requires knowing its length, and that its deletion does not affect the MAC verification and decryption output for the following messages. This analysis depends on the encryption mode ….
(NS, NC)-Prefix Truncation Attack. In a single attack, the attacker can generally delete an arbitrary number of NS initial messages sent from the server and NC initial messages sent from the client. This is straightforward: Instead of inserting one IGNORE message to the client before NEWKEYS, the attacker inserts NS such messages to the client and NC to the server. Consequently, instead of deleting the first message from the server, the attacker deletes NS initial messages from the server and the NC initial messages from the client.
Note that the single message attack above is the specific case of a (1, 0)-prefix truncation attack.
The researchers note that they aren’t the first people to describe a prefix truncation attack on a network protocol by manipulating sequence numbers. In 2015, researcher Cédric Fournet envisioned a similar attack on a draft of the upcoming version 1.3 of TLS. Fournet’s technique increased sequence numbers by fragmenting messages rather than injecting them as Terrapin does. (Terrapin injects an IGNORE message to asymmetrically increase the sequence number on one side of the communication.) Fournet’s attack was deemed theoretical because the manipulation in this case was likely to cause TLS handshakes to fail. The possibility of a successful exploit nonetheless prompted engineers to follow Fournet’s advice to revert back to 1.2’s practice of resetting record-layer sequence numbers to 0 whenever new keys were installed.
In response to recommendations provided by the researchers ahead of the publication of Monday’s paper, the developers of SSH software, including the nearly ubiquitous OpenSSH, have updated their implementations to support an optional strict key exchange. It provides for sequence number resets and also prevents an attacker’s capability to inject packets during the initial unencrypted handshake. For the fix to take effect, both client and server must support this backward-compatible change.
Terrapin works against any SSH implementation supporting and configured to offer the chacha20-poly1305@openssh.com
encryption algorithm, or any encryption algorithm suffixed -cbc in combination with any MAC algorithm suffixed -etm@openssh.com
. The images below contrast the varying attack flow required to target each algorithm.
Enlarge / An illustration of an extension downgrade attack targeting SSH using the ChaCha20-Poly1305 algorithm. The adversary in the middle injects an IGNORE message before the handshake concludes. The change in sequence numbers allows the AitM to strip the EXTINFO from within the secure channel.