SSH protects the world’s most sensitive networks. It just got a lot weaker

Sometime around the start of 1995, an unknown person planted a password sniffer on the network backbone of Finland’s Helsinki University of Technology (now known as Aalto University). Once in place, this piece of dedicated hardware surreptitiously inhaled thousands of user names and passwords before it was finally discovered. Some of the credentials belonged to employees of a company run by Tatu Ylönen, who was also a database researcher at the university.

The event proved to be seminal, not just for Ylönen's company but for the entire world. Until that point, people like Ylönen connected to networks using tools which implemented protocols such as Telnet, rlogin, rcp, and rsh. All of these transmitted passwords (and all other data) as plaintext, providing an endless stream of valuable information to sniffers. Ylönen, who at the time knew little about implementing strong cryptography in code, set out to develop the Secure Shell Protocol (SSH) in early 1995, about three months after the discovery of the password sniffer.

As one of the first network tools to route traffic through an impregnable tunnel fortified with a still-esoteric feature known as "public key encryption," SSH quickly caught on around the world. Besides its unprecedented security guarantees, SSH was easy to install on a wide array of operating systems, including the myriad ones that powered the devices administrators used—and the servers those devices connected to remotely. SSH also supported X11 forwarding, which allowed users to run graphical applications on a remote server.

Ylönen submitted SSH to the Internet Engineering Taskforce in 1996, and it quickly became an almost ubiquitous tool for remotely connecting computers. Today, it’s hard to overstate the importance of the protocol, which underpins the security of apps used inside millions of organizations, including cloud environments crucial to Google, Amazon, Facebook, and other large companies.

“Password sniffing attacks were very common at that time, with new incidents reported almost weekly, and arguably it was the biggest security problem on the Internet at the time,” Ylönen wrote in an online interview. “I did intend SSH to become as widely used as possible. It was critically needed for securing networks and computing systems, and it for the most part solved the password sniffing problem.”

Now, nearly 30 years later, researchers have devised an attack with the potential to undermine, if not cripple, cryptographic SSH protections that the networking world takes for granted.

Meet Terrapin

Named Terrapin, the new hack works only when an attacker has an active adversary-in-the middle position on the connection between the admins and the network they remotely connect to. Also known as a man-in-the-middle or MitM attack, this occurs when an attacker secretly positioned between two parties intercepts communications and assumes the identity of both the recipient and the sender. This provides the ability to both intercept and to alter communications. While this position can be difficult for an attacker to achieve, it’s one of the scenarios from which SSH was thought to have immunity.

For Terrapin to be viable, the connection it interferes with also must be secured by either "ChaCha20-Poly1305" or "CBC with Encrypt-then-MAC," both of which are cipher modes added to the SSH protocol (in 2013 and 2012, respectively). A scan performed by the researchers found that 77 percent of SSH servers exposed to the Internet support at least one of the vulnerable encryption modes, while 57 percent of them list a vulnerable encryption mode as the preferred choice.

At its core, Terrapin works by altering or corrupting information transmitted in the SSH data stream during the handshake—the earliest stage of a connection, when the two parties negotiate the encryption parameters they will use to establish a secure connection. The attack targets the BPP, short for Binary Packet Protocol, which is designed to ensure that adversaries with an active position can't add or drop messages exchanged during the handshake. Terrapin relies on prefix truncation, a class of attack that removes specific messages at the very beginning of a data stream.

Fabian Bäumer, one of three researchers from Germany’s Ruhr University Bochum who devised Terrapin, described this approach in an email:

The Terrapin attack is a novel cryptographic attack targeting the integrity of the SSH protocol, the first-ever practical attack of its kind, and one of the very few attacks against SSH at all. The attack exploits weaknesses in the specification of SSH paired with widespread algorithms, namely ChaCha20-Poly1305 and CBC-EtM, to remove an arbitrary number of protected messages at the beginning of the secure channel, thus breaking integrity. In practice, the attack can be used to impede the negotiation of certain security-relevant protocol extensions. Moreover, Terrapin enables more advanced exploitation techniques when combined with particular implementation flaws, leading to a total loss of confidentiality and integrity in the worst case.

During the handshake, BPP keeps track of the number of messages exchanged between the client (typically operated by a remote admin) and the SSH daemon (the server app that facilitates the connection on the network). In a paper published Monday, in coordination with a disclosure by some three dozen SSH apps that are affected by Terrapin, the researchers included the two images below. The first shows the flow of a normal handshake; the second illustrates the handshake flow when altered by Terrapin.

The researchers wrote:

In this work, we focus on the integrity of the SSH handshake and the resulting secure channel, as shown in Figure 1. After an initial exchange of version information directly over TCP, the BPP exchanges packets, each containing precisely one message. Initially, the BPP is used without encryption or authentication for the duration of the key exchange until the NEWKEYS message. Afterward, the encryption and authentication keys are used to form a secure channel, with the intent to protect the confidentiality and integrity of the ordered stream of all following messages. Note that technically, the secure channel consists of two separate cipher streams, one for each direction, and that the order of message arrival is only guaranteed for each direction separately.

In its current incarnation, Terrapin involves three vulnerabilities:

• CVE-2023-48795
• CVE-2023-46445
• CVE-2023-46446

CVE-2023-48795 is the general flaw in the SSH protocol allowing for the prefix truncation attack. CVE-2023-46445 and CVE-2023-46446, meanwhile, reside in an app named AsyncSSH, which implements the SSH protocol. While the latter two implementation flaws don’t affect the SSH protocol directly, they can only be exploited when coupled with Terrapin, and as such demonstrate the adverse effects that can result from Terrapin. (The AsyncSSH vulnerabilities have been fixed in version 2.14.1.)

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, tne 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:

 

1. The attacker uses the RcvIncrease technique to increase C.Rcv by one, e.g., by injecting an IGNORE message to the client before NEWKEYS.

2. 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 [email protected] encryption algorithm, or any encryption algorithm suffixed -cbc in combination with any MAC algorithm suffixed [email protected]. The images below contrast the varying attack flow required to target each algorithm.

Besides Bäumer, the other two Ruhr University researchers who penned the paper are Marcus Brinkmann and Jörg Schwenk.

So what now?

People who want to know if the SSH client or server they use is vulnerable to Terrapin can use a custom scanner developed by the researchers. It connects to a server or monitors the incoming client connection to determine whether one of the vulnerable encryption modes is available and if the countermeasure requiring a strict key exchange is supported. The scanner doesn’t perform a full-fledged handshake or carry out the attack.

As noted earlier, assessing the risk severity and patch urgency posed by the Terrapin vulnerability will vary from user to user and organization to organization. Anyone using AsyncSSH should patch right away. While the researchers didn’t focus much time on the dozens of other widely used SSH implementations, it’s entirely possible that some of them may also harbor currently undetected vulnerabilities that can be exploited using Terrapin.

That said, anyone who uses any app implementing SSH should check with the developer for guidance, including whether the app is affected by Terrapin and, if so, the conditions under which it is vulnerable to exploitation and whether a fix is available.

While the risk Terrapin poses varies, it invalidates proofs published in 2016 that concluded such attacks weren’t possible. The real lesson is that practical evaluations, like the one provided in Monday’s research, are crucial for revealing previously overlooked flaws in such proofs.

“In any case, proofs need to be updated over time to reflect changes and extensions to the protocol,” the researchers wrote. “Although we suggest backward-compatible countermeasures to stop our attacks, we note that the security of the SSH protocol would benefit from a redesign from scratch, guided by all findings and insights from both practical and theoretical security analysis, in a similar manner as was done for TLS 1.3.”