Terrapin Attack: Breaking SSH Channel Integrity by Sequence Number Manipulation

Terrapin Attack: Breaking SSH Channel Integrity by Sequence Number Manipulation

Speakers: Unknown

Conference: Black Hat USA

YouTube: https://www.youtube.com/watch?v=JZiEaF7XT4o

Overview

This talk introduces the Terrapin Attack, a novel prefix truncation attack that compromises the integrity of the Secure Shell (SSH) protocol's encrypted channel. Presented at Black Hat USA, the research behind this attack was published by the speaker and their colleagues, Marcus Brinkmann and Jörg Schwenk, at the USENIX Security Symposium. The Terrapin Attack exploits vulnerabilities in the SSH handshake when specific modern encryption modes, namely ChaCha20-Poly1305 and AES-GCM, are used. By manipulating sequence numbers during the key exchange, a man-in-the-middle (MITM) attacker can effectively remove an arbitrary number of messages from the beginning of the secure channel without detection, leading to severe consequences such as authentication bypass or a downgrade of the connection's security features.

The significance of the Terrapin Attack lies in its ability to undermine the fundamental security guarantees of SSH, a protocol widely relied upon for secure remote access and data transfer. For organizations and individual users, this means that even with strong cryptographic algorithms in use, a sophisticated MITM attacker could potentially gain unauthorized access to systems or force connections into less secure configurations. The talk not only details the technical intricacies of the attack but also highlights broader implications regarding the integration of modern cryptographic primitives into established, older protocols and the challenges of protocol standardization within communities like SSH.

Background

▶ Watch: Terrapin Attack introduction and Bob/Mallory scenario (0:00)

SSH stands as a cornerstone of secure remote administration and data transfer, providing an encrypted channel over an untrusted network. Its robust design typically ensures confidentiality, integrity, and authenticity for data exchanged between a client and a server. The protocol operates in two main phases: the key exchange (Kex), where cryptographic keys are established, and the authentication phase, where the client proves its identity to the server. Following successful key exchange and authentication, a secure channel is established, encrypting all subsequent application data.

The problem addressed by the Terrapin Attack stems from the interaction between SSH's established handshake mechanisms and the specific requirements of modern Authenticated Encryption with Associated Data (AEAD) ciphers, such as ChaCha20-Poly1305 and AES-GCM. These ciphers are designed to provide both confidentiality and integrity, often relying on a nonce (number used once) to ensure that identical plaintext blocks produce different ciphertexts, preventing certain types of attacks. In SSH, the packet sequence number is typically incorporated into this nonce. While highly effective, the integration of these ciphers into SSH's existing structure, particularly how sequence numbers are handled during the SSH_MSG_NEWKEYS message exchange, created an exploitable flaw.

The talk illustrates this vulnerability through a narrative involving Bob, a system administrator, and Mallory, a malicious trainee. Bob uses SSH to manage production and test servers, with sudo rights on the production environment. Mallory, lacking production access and sudo rights on the test server, aims to elevate his privileges. Mallory achieves this by installing a network tap to gain MITM capabilities over Bob's SSH connections. This setup provides the necessary adversarial conditions for the Terrapin Attack to unfold, demonstrating how even seemingly minor protocol ambiguities or implementation details can be leveraged by an attacker with a network presence. The scenario underscores the real-world impact of such vulnerabilities, where an attacker can bypass stringent access controls by manipulating the underlying secure communication channel.

Key Findings

▶ Watch: Demonstrating a normal, secure SSH connection as Bob (3:30)

The primary finding presented in the talk is the Terrapin Attack, a novel prefix truncation attack against the SSH protocol. This attack allows a man-in-the-middle (MITM) attacker to remove an arbitrary number of messages from the beginning of the SSH secure channel without detection by either the client or the server. The core of the vulnerability lies in how SSH implementations handle sequence numbers in conjunction with certain modern AEAD (Authenticated Encryption with Associated Data) ciphers, specifically ChaCha20-Poly1305 and AES-GCM.

The attack leverages the fact that these AEAD ciphers use a combination of a fixed nonce and the packet sequence number to construct the unique nonce for each encrypted packet. During the SSH key exchange, after the initial ephemeral key agreement, a SSH_MSG_NEWKEYS message is exchanged, signaling a transition to the new keys and resetting the explicit packet sequence numbers to zero for the secure channel. However, the implicit sequence number used as part of the AEAD nonce in some implementations does not reset consistently or is not protected by the SSH_MSG_NEWKEYS message itself. This desynchronization creates a window for manipulation.

The speaker identified two main attack variants:

1. Authentication Bypass / Session Hijacking: As demonstrated in the talk, Mallory can use the Terrapin Attack to bypass Bob's user authentication. By truncating specific messages, Mallory can either trick Bob into authenticating to a different server (e.g., a test server instead of a production server) while Mallory gains access to the intended production server, or directly hijack Bob's session after authentication. The demo specifically showed Mallory gaining control over what appeared to be Bob's session on the test server, implying a successful usurpation of authentication.

1. Security Downgrade: The attack can also be used to downgrade the security features of an SSH connection. A prominent example is the disabling of strict Kex (Strict Key Exchange). strict Kex is a critical countermeasure designed to prevent key exchange downgrade attacks by ensuring that no non-key-exchange messages are processed before the SSH_MSG_NEWKEYS message. By truncating the message that signals strict Kex support, an attacker can effectively disable this protection, forcing the client and server to proceed with a less secure key exchange or allowing further manipulation of the connection's parameters.

The specific requirements for Mallory's attack to work are:

• A man-in-the-middle (MITM) position between the SSH client and server.
• The use of ChaCha20-Poly1305 or AES-GCM encryption modes. These modes are prevalent in modern SSH deployments due to their performance and strong security properties.
• An SSH client or server implementation that is vulnerable to the sequence number manipulation during the SSH_MSG_NEWKEYS transition. The demonstration used Async SSH, a Python implementation, but the underlying issue affects the protocol specification and various other implementations.

The successful identification and demonstration of the Terrapin Attack underscore the complex challenges of maintaining protocol integrity, especially when integrating new cryptographic paradigms into existing, widely deployed systems. It highlights how subtle interactions between different protocol layers and cryptographic primitives can lead to significant security vulnerabilities.

Technical Deep Dive

▶ Watch: Mallory intercedes with a man-in-the-middle TCP proxy (4:20)

The Terrapin Attack exploits a subtle yet critical flaw in how SSH handles sequence numbers when employing Authenticated Encryption with Associated Data (AEAD) ciphers like ChaCha20-Poly1305 and AES-GCM. To understand this, we first need to review the relevant aspects of the SSH protocol.

In SSH, after the initial TCP handshake, the client and server engage in a key exchange (Kex) process. This involves exchanging public keys, performing Diffie-Hellman key agreement, and deriving shared session keys. A crucial step in this process is the exchange of the SSH_MSG_NEWKEYS message. This message signifies that both parties have successfully computed the new session keys and are ready to switch to them for encrypting subsequent traffic. Critically, upon sending and receiving SSH_MSG_NEWKEYS, the packet sequence numbers for the secure channel are reset to zero. These sequence numbers are vital for maintaining packet order, detecting replayed packets, and, importantly for this attack, contributing to the nonce for AEAD ciphers.

AEAD ciphers combine encryption and message authentication code (MAC) into a single operation. For security, they require a unique nonce for each packet. In SSH, this nonce is typically constructed by combining a fixed component derived during key exchange with the packet's explicit sequence number. The problem arises because, while the explicit packet sequence number is reset to zero after SSH_MSG_NEWKEYS, the implicit sequence number used for the AEAD nonce might not be reset consistently across all implementations, or the integrity protection provided by SSH_MSG_NEWKEYS itself is insufficient.

The Terrapin Attack proceeds as follows:

1. MITM Position: The attacker (Mallory) must be in a man-in-the-middle position, able to intercept and modify traffic between the SSH client (Bob) and server.

1. Vulnerable Cipher Suite: The client and server must negotiate an AEAD cipher like ChaCha20-Poly1305 or AES-GCM. These are common modern choices for SSH.

1. Sequence Number Manipulation: During the key exchange phase, before the SSH_MSG_NEWKEYS message is exchanged, Mallory injects specially crafted messages. The most effective messages for this are SSH_MSG_UNIMPLEMENTED or SSH_MSG_DISCONNECT.

• When the client or server receives one of these injected messages, it processes it and, critically, increments its outgoing packet sequence number.
• Mallory injects these messages in such a way that they are processed only by one side (e.g., injected from Mallory to the client, or from Mallory to the server, but not both at the same time to avoid immediate detection).
• For example, Mallory could inject SSH_MSG_UNIMPLEMENTED messages from the server to the client. The client receives these, increments its incoming sequence number, and responds with its own SSH_MSG_UNIMPLEMENTED messages, incrementing its outgoing sequence number. Mallory then intercepts and drops the client's responses. The key is that the sequence numbers are incremented before the SSH_MSG_NEWKEYS message.

1. SSH_MSG_NEWKEYS Exchange: Eventually, the legitimate SSH_MSG_NEWKEYS messages are exchanged. At this point, the explicit packet sequence numbers for newly encrypted packets are reset to zero. However, the crucial flaw is that the implicit sequence number component used to construct the AEAD nonce for the first few packets after NEWKEYS is not properly synchronized or reset. Because Mallory caused one side's sequence number to increment more than the other's before the NEWKEYS exchange, the subsequent AEAD nonces become desynchronized.

1. Prefix Truncation: This desynchronization allows Mallory to effectively "shift" the starting point of the secure channel. If Mallory caused one side's sequence number to increment by N extra packets, Mallory can then silently drop the first N packets sent by that side after NEWKEYS without triggering an integrity error. This is because the receiver's expected nonce will match the nonce of a later packet, effectively truncating the beginning of the channel. The AEAD cipher will still verify the integrity of the remaining (truncated) message stream, making the attack undetectable to the honest parties.

Countermeasure: strict Kex

The talk emphasizes strict Kex (Strict Key Exchange) as the primary countermeasure against this attack. strict Kex enforces that no application-level messages (i.e., messages other than those directly related to key exchange) are processed before both parties have exchanged and processed the SSH_MSG_NEWKEYS message. This ensures that the sequence numbers cannot be manipulated by injected SSH_MSG_UNIMPLEMENTED or SSH_MSG_DISCONNECT messages in the critical window before the secure channel is fully established and its integrity guaranteed.

The speaker noted that the SSH protocol community lacks a formal working group at the IETF, meaning OpenSSH often acts as the de facto standard setter. OpenSSH has implemented strict Kex to address this vulnerability, and other implementations are expected to follow suit. This highlights a broader issue in protocol evolution and standardization within the SSH ecosystem.

Demo / Proof of Concept

▶ Watch: Summary of attack variants and required conditions (6:00)

The demonstration provided a clear, albeit simplified, illustration of the Terrapin Attack's impact. The scenario involved three primary entities: Bob (the legitimate system administrator), Mallory (the malicious trainee), and two SSH servers – Surf Pod 01 (production) and Surf test 01 (test).

The setup for the demo involved:

• Servers: Two Docker containers were used, each running an SSH server configured to listen on port 22. Crucially, these servers ran Async SSH, a Python implementation of the SSH protocol. The speaker explicitly noted the importance of using Async SSH, implying it was a vulnerable implementation at the time of discovery.
• Client: Bob's client was also running Async SSH, albeit via a convenience wrapper script.
• Attacker: Mallory's presence was simulated by introducing a TCP proxy between Bob's client and the SSH servers. This proxy allowed Mallory to intercept, modify, and inject packets, effectively establishing a man-in-the-middle (MITM) position.

The demonstration proceeded in several steps:

1. Normal Operation (Without Mallory): Bob first connected to Surf Pod 01 (the production server) directly, authenticating with the password "secret." A normal shell prompt appeared, confirming Bob's identity (whoami output: bob) and demonstrating sudo access (sudo whoami output: root). This established the baseline of expected behavior.

1. Mallory's Intervention (Via TCP Proxy): Next, Bob was instructed to connect through Mallory's TCP proxy. The client was configured to only trust the actual SSH service public key, meaning certificate pinning or host key verification was still active, and Mallory could not simply present a fake server. The initial connection through the proxy took "a little bit longer," but otherwise, the connection appeared to proceed normally from Bob's perspective. Bob again received a shell prompt, and could execute whoami (showing bob) and sudo whoami (showing root).

1. The Reveal: The critical moment of the demo came when the speaker revealed the true state of affairs. Despite Bob seeing a prompt that read Bob at SRE test 01 and believing he was logged in as himself with root privileges, the speaker stated: "what you see at the bottom the prompt Bob at SRE test 01, it's not actually Bob that is that's logged in, but Mallory."

This reveal demonstrates a potent authentication bypass or session hijacking capability. While the exact mechanics of Mallory's takeover weren't fully visualized step-by-step in the brief demo, the implication is clear: Mallory, leveraging the Terrapin Attack, was able to manipulate the SSH handshake and secure channel to either:

• Trick Bob into connecting to the less-privileged Surf test 01 server while Mallory simultaneously gained unauthorized access (perhaps as Bob) to the intended Surf Pod 01 production server.
• More directly, Mallory may have intercepted Bob's authentication messages, truncated them, and then injected his own authentication, effectively taking over Bob's session or authenticating as Bob to the Surf test 01 server. The prompt Bob at SRE test 01 suggests a successful login to the test server, but the speaker's statement "it's not actually Bob that is that's logged in, but Mallory" implies Mallory is in control, masquerading as Bob.

The demo effectively showcased the stealthy nature of the Terrapin Attack, where the user perceives a normal, secure connection while an attacker has compromised its integrity and potentially gained unauthorized access or control.

Defensive Implications

▶ Watch: Discussion on SSH protocol standardization and OpenSSH (6:50)

The Terrapin Attack presents significant defensive implications for anyone relying on the SSH protocol, from individual users to large enterprises. The core message for defenders is the urgent need to address the underlying vulnerability through updates and configuration changes.

1. Patch and Update SSH Implementations: The most critical defensive action is to ensure that all SSH clients and servers are updated to versions that incorporate the necessary patches. The vulnerability primarily affects implementations using ChaCha20-Poly1305 or AES-GCM ciphers without proper protection against sequence number manipulation during the key exchange. As the speaker noted, OpenSSH, being the de facto standard, has implemented the strict Kex (Strict Key Exchange) countermeasure. Users of OpenSSH clients (e.g., ssh on Linux/macOS) and servers (e.g., sshd) should update to versions that include this fix. Other SSH implementations (like Async SSH used in the demo, PuTTY, libssh, etc.) also need to be updated. Defenders should consult their specific SSH software vendors or project maintainers for the relevant patch information and release versions.

1. Enable strict Kex: While many updated implementations will enable strict Kex by default, it's prudent for administrators to verify its activation. strict Kex ensures that no non-key-exchange messages are processed before the SSH_MSG_NEWKEYS message, thereby closing the window for sequence number manipulation. If an SSH environment allows for older, unpatched clients or servers to connect, there might be interoperability challenges or a need for phased updates.

1. Cipher Suite Prioritization (Temporary Mitigation): If immediate patching is not feasible, a temporary mitigation could involve reconfiguring SSH clients and servers to prioritize cipher suites that are not vulnerable to Terrapin (i.e., avoiding ChaCha20-Poly1305 and AES-GCM, or at least ensuring they are used only with strict Kex enabled). However, this is a less ideal solution as it might involve reverting to older, potentially less performant, or less secure (against other attacks) ciphers. It's crucial to understand that this is a stop-gap measure, and patching remains the ultimate solution.

1. Network Monitoring and MITM Detection: The Terrapin Attack requires a man-in-the-middle (MITM) position. Defenders should enhance network monitoring to detect potential MITM activity, such as unusual routing, ARP spoofing, DNS hijacking, or unexpected certificate warnings. While the attack itself is designed to be stealthy at the SSH protocol layer, the initial establishment of a MITM position might leave traces.

1. Review Protocol Configurations: Beyond just cipher suites, administrators should review their entire SSH configuration for best practices. This includes strong authentication methods (e.g., public key authentication instead of passwords), limiting sudo access, and implementing principle of least privilege. While these don't directly prevent Terrapin, they reduce the overall attack surface and potential damage if an SSH session is compromised through other means.

1. Understand Protocol Evolution Challenges: The talk highlights that "adding modern cryptography to older protocols can go wrong" and the challenges with SSH standardization (OpenSSH's role as a de facto standard). This implies that defenders should stay informed about ongoing research into SSH and other critical protocols, as new vulnerabilities can emerge from complex interactions between protocol layers and cryptographic primitives. Relying solely on the "standard" without understanding its evolution can be risky.

By taking these defensive steps, organizations can significantly reduce their exposure to the Terrapin Attack and bolster the overall security posture of their SSH infrastructure.

Key Takeaways

• Terrapin Attack is a Prefix Truncation Vulnerability: The attack breaks SSH channel integrity by allowing a man-in-the-middle (MITM) attacker to remove an arbitrary number of messages from the beginning of the secure channel without detection.
• Vulnerability in AEAD Ciphers and Sequence Numbers: The attack exploits how ChaCha20-Poly1305 and AES-GCM encryption modes interact with SSH's sequence number handling during the SSH_MSG_NEWKEYS exchange, leading to desynchronized nonces.
• Severe Attack Consequences: Terrapin enables critical attacks such as authentication bypass (allowing an attacker to impersonate a legitimate user) and security downgrades (e.g., disabling strict Kex to facilitate further attacks).
• strict Kex is the Primary Countermeasure: The most effective defense is the implementation and enforcement of strict Kex (Strict Key Exchange), which prevents non-key-exchange messages from being processed before the secure channel is fully established.
• Update All SSH Implementations: Users and administrators must update their SSH clients and servers (e.g., OpenSSH, Async SSH, PuTTY, libssh) to patched versions that include strict Kex or other fixes for this vulnerability.
• Challenges of Protocol Evolution: The attack underscores the difficulties in integrating modern cryptographic primitives into established, complex protocols and the challenges of protocol standardization, where de facto standards (like OpenSSH) play a critical role in security updates.

About the Speaker(s)

The talk on the Terrapin Attack was presented by one of the co-authors of the research paper, which was published with colleagues Marcus Brinkmann and Jörg Schwenk at the USENIX Security Symposium. While the specific speaker's name was not provided in the metadata, their expertise lies in deep protocol analysis and cryptographic vulnerabilities within widely used security protocols like SSH. Their work highlights the ongoing need for rigorous security research and careful implementation of cryptographic primitives to maintain the integrity of critical communication infrastructure.