Breaking SSH Channel Integrity: The Terrapin Attack Explained

TLDR: The Terrapin attack, tracked as CVE-2023-48795, is a prefix truncation vulnerability that allows an attacker to manipulate the SSH handshake. By injecting or removing specific messages, an attacker can downgrade the security of a connection without triggering integrity alerts. This flaw stems from the lack of integrity protection for the entire handshake transcript and the reuse of sequence numbers across different encryption contexts.

SSH is the bedrock of secure remote administration, and for years, we have treated it as a black box that just works. We assume that if the handshake completes, the channel is secure. The research presented at Black Hat 2024 on the Terrapin attack shatters that assumption. It proves that the protocol itself has a fundamental flaw in how it handles handshake integrity, allowing an adversary in the middle to silently downgrade the security of a session.

The Mechanics of the Flaw

At its core, Terrapin is a prefix truncation attack. The SSH handshake involves an exchange of version strings, followed by an exchange of supported algorithms, and finally, a key exchange. The vulnerability exists because the integrity of the handshake is not fully protected until the secure channel is established.

The researchers identified that the sequence numbers used to track messages are initialized to zero at the start of the handshake and are never reset. Crucially, these sequence numbers are not transmitted in the clear; they are implicit. When an attacker sits in the middle, they can inject or remove messages from the unencrypted portion of the handshake. Because the integrity check (the Message Authentication Code, or MAC) is only applied after the secure channel is activated, the attacker can manipulate the handshake transcript without the client or server realizing the sequence numbers have been desynchronized.

The impact is a downgrade attack. By removing specific messages, an attacker can force the client and server to negotiate weaker encryption algorithms or disable security features like RFC 8308 extension negotiation. The demo shown during the talk was particularly striking: by using a network tap to intercept the connection, the attacker could force the session to use less secure primitives, effectively stripping away the protections that modern SSH configurations are supposed to provide.

Why This Matters for Pentesters

If you are performing a red team engagement or a penetration test, you need to look for SSH implementations that do not support the new "Strict Kex" countermeasure. The attack is highly practical against implementations that rely on vulnerable encryption modes like CBC or CTR combined with standard MACs.

The technical requirement for the attack is the ability to perform an adversary-in-the-middle position. While this is often dismissed as "too hard" in a real-world scenario, it is a standard capability for anyone with access to the local network or the ability to perform ARP spoofing. Once in position, you are not trying to crack the encryption; you are manipulating the protocol state machine before the encryption even begins.

To test for this, you should check the SSH server's supported algorithms. If the server supports older, non-authenticated encryption modes or fails to negotiate the kex-strict-c-v00@openssh.com extension, it is likely vulnerable. You can use tools like nmap to enumerate the supported algorithms and identify if the server is running a version that hasn't been patched against CVE-2023-48795.

The Defensive Reality

The fix for Terrapin is a protocol-level change called "Strict Kex." This countermeasure forces the connection to terminate if any unexpected messages are received during the handshake. It also resets the sequence numbers to zero upon the activation of the secure channel, which effectively breaks the attacker's ability to manipulate the transcript.

Defenders must ensure that both the client and the server support and enforce Strict Kex. This is not just a server-side patch; it requires a coordinated update across your infrastructure. If you are managing a fleet of servers, prioritize updating your OpenSSH binaries. For those using other implementations, check the vendor advisories to see if they have implemented the Strict Kex extension.

What You Should Do Next

Do not assume your SSH traffic is safe just because it is encrypted. Terrapin highlights a dangerous reality: even well-vetted protocols can have logic flaws that bypass cryptographic protections. As a researcher or pentester, your next step is to audit your own environment. Run a scan against your internal infrastructure to identify which systems are still negotiating vulnerable key exchange algorithms.

If you find systems that do not support Strict Kex, they are a liability. The research is clear: the only way to stop this is to move to a protocol version that enforces strict handshake integrity. Stop relying on legacy configurations and start auditing your SSH algorithm preferences today. The era of trusting the SSH handshake blindly is over.