A groundbreaking study titled “Terrapin Attack: Breaking SSH Channel Integrity By Sequence Number Manipulation” has been released by researchers Fabian Bäumer, Marcus Brinkmann, and Jörg Schwenk from Ruhr University Bochum. The study reveals a significant vulnerability in the Secure Shell (SSH) protocol, a cornerstone of internet security, particularly in remote terminal login and file transfer.SSH, developed in 1995, is a protocol providing secure access to network services and is used extensively for administrative tasks on over 15 million servers worldwide. It ensures the confidentiality and integrity of messages sent between a client and a server, preventing message manipulation, replay, insertion, deletion, and reordering.
The Terrapin Attack:
The researchers have identified that the SSH Binary Packet Protocol, a key component of SSH, is no longer a secure channel due to new encryption algorithms and mitigations. This vulnerability allows for prefix truncation attacks, where encrypted packets at the beginning of the SSH channel can be deleted without detection. Breaking SSH channel integrity refers to compromising the security of the encrypted communication channel established by SSH. This could involve attacks that manipulate encrypted data in transit, causing unauthorized changes or information disclosure. Techniques might include sequence number manipulation or exploiting vulnerabilities in SSH’s encryption modes. Such breaches can allow attackers to intercept, decrypt, or alter sensitive data, undermining SSH’s primary goal of secure, confidential, and integrity-protected communication between clients and servers. This is a significant security concern, as SSH is widely used for secure remote access and data transfer. An internet-wide scan revealed that 77% of SSH servers support an exploitable encryption mode, with 57% listing it as their preferred choice. This widespread vulnerability underscores the critical nature of the Terrapin Attack.
Sequence Number Manipulation Attack
Sequence Number Manipulation in the context of SSH (Secure Shell) refers to a type of attack where an intruder interferes with the sequence numbers in packet headers used in SSH communications. In SSH, each packet is assigned a sequence number to ensure data integrity and proper order of packets. By manipulating these numbers, an attacker could potentially reorder, replay, or drop packets. This can lead to a variety of security issues, such as unauthorized data alteration or information disclosure, effectively breaching the integrity of the SSH channel. This kind of attack exploits vulnerabilities in how SSH handles and validates sequence numbers, potentially allowing an attacker to intercept or modify secure communications.An example of sequence number manipulation in SSH could be as follows: Suppose an attacker is able to intercept SSH packets between a client and server. They notice that each packet has a sequence number, which ensures packets are processed in the correct order. The attacker then decides to manipulate these numbers. For instance, they could increase the sequence number of a packet, causing the SSH protocol to believe that some packets were lost in transit. As a result, the server might request retransmission of these packets, or it might process the packets out of order, leading to errors or unexpected behavior. This manipulation could disrupt or compromise the integrity of the SSH communication channel.
Exploiting sequence number manipulation in SSH can be done in several ways. An attacker could:
- Reorder Packets: By altering sequence numbers, an attacker can change the order in which packets are processed. This could corrupt data or disrupt normal communication.
- Packet Injection: Manipulating sequence numbers might allow an attacker to inject malicious packets into the communication stream.
- Session Hijacking: By predicting or influencing sequence numbers, an attacker could take over an existing SSH session, gaining unauthorized access.
- Denial of Service (DoS): Disrupting the sequence of packets could lead to session termination or resource exhaustion, causing a denial of service.
Each of these methods could compromise the confidentiality, integrity, and availability of data in an SSH session.
Prefix Truncation Attack on the BPP
A Prefix Truncation Attack on the Binary Packet Protocol (BPP) in SSH involves an attacker manipulating encrypted SSH packets. The attacker may delete some encrypted packets at the start of an SSH channel, which can lead to misinterpretation or handling of the remaining data. This attack targets the way SSH handles packet processing and can potentially compromise data integrity and confidentiality. The effectiveness of such an attack depends on specific encryption modes and the SSH implementation’s handling of sequence numbers and packet integrity. An example of a Prefix Truncation Attack on the Binary Packet Protocol (BPP) in SSH might involve an attacker who intercepts SSH packets and removes the initial portion of the data in a packet before it reaches the destination. For instance, suppose an SSH session is transferring a sensitive file. The attacker could truncate the beginning of a packet, altering its content. When this modified packet is processed at the receiving end, due to missing or altered data, it could lead to incorrect or unexpected outcomes, such as file corruption or execution of unintended commands. This attack exploits vulnerabilities in how SSH processes and validates packet integrity.
A Prefix Truncation Attack on the Binary Packet Protocol (BPP) in SSH can be exploited by an attacker to disrupt the normal communication flow. By truncating the beginning of an encrypted SSH packet, the attacker makes the remaining content of the packet misinterpreted at the receiving end. This can lead to various issues like incorrect command execution, data corruption, or even creating vulnerabilities that the attacker can further exploit to gain unauthorized access or information. This type of attack targets the integrity and reliability of the data transmission in SSH sessions.
Analysis of Encryption Modes
The analysis of encryption modes in the context of SSH typically involves evaluating how different cryptographic algorithms and methods protect data confidentiality and integrity. This includes assessing each mode’s vulnerability to various types of attacks, such as sequence number manipulation or prefix truncation attacks. The analysis might categorize encryption modes based on their resistance to these attacks, identifying which are more secure and which might have potential vulnerabilities. Understanding the strengths and weaknesses of each encryption mode is crucial for maintaining the security and reliability of SSH communications. In the context of SSH encryption modes, they can be categorized based on their vulnerability to certain types of attacks:
- Not Vulnerable: Encryption modes in this category are considered secure against known attack vectors like sequence number manipulation or prefix truncation. They maintain data integrity and confidentiality effectively.
- Vulnerable And Perfectly Exploitable: These are modes that not only have vulnerabilities but also can be fully exploited by attackers. This means that an attacker can reliably manipulate or decrypt data.
- Vulnerable But Not Exploitable: Here, the encryption modes have theoretical vulnerabilities, but due to various constraints (like computational complexity or specific conditions not being met), these vulnerabilities cannot be practically exploited.
- Vulnerable And Probabilistically Exploitable: These modes are vulnerable, and exploitation is possible, but it depends on certain probabilistic factors. It means that an attacker has a chance of success, which is not guaranteed.
Each category reflects the level of security risk and potential for data compromise in SSH communications.
Breaking SSH Extension Negotiation
A “Breaking SSH Extension Negotiation Attack” targets the extension negotiation process in SSH. This process allows SSH clients and servers to agree on additional features or capabilities after the initial connection is established. In this type of attack, an adversary manipulates this negotiation phase to downgrade or disable certain security features. For example, the attacker might intervene in this phase to prevent the use of more secure algorithms or extensions, forcing the SSH session to use less secure options. This can open the door to further vulnerabilities and exploits, compromising the security of the SSH session. An example of a Breaking SSH Extension Negotiation attack could be where an attacker, positioned between the SSH client and server (man-in-the-middle), intercepts the extension negotiation messages. Suppose the client supports a secure, advanced encryption extension, and the server is compatible with it. The attacker could alter or block these negotiation messages so that both parties fall back to a less secure, default encryption method. This downgraded security state could then be exploited by the attacker to compromise the data transmitted in the SSH session.
Extension Downgrade Attack
An Extension Downgrade Attack in SSH involves an attacker deliberately downgrading the SSH session to use less secure extensions or algorithms. For instance, during the SSH handshake, if both client and server support a high-security extension, the attacker, through a man-in-the-middle position, could intercept and alter these negotiation messages. The client and server, believing the other doesn’t support the high-security option, would fall back to a less secure default. This downgrade leaves the SSH session vulnerable to further exploits that wouldn’t be possible with the more secure extensions. An example of an Extension Downgrade Attack: Imagine an SSH client and server both support a high-security encryption algorithm. An attacker, who can intercept the communication, alters the handshake messages to falsely indicate that the high-security algorithm is not supported by either the client or server. Consequently, both the client and server default to a less secure encryption method. This downgrade makes the SSH session vulnerable to other types of attacks, such as eavesdropping or data manipulation, which wouldn’t be as feasible with the stronger encryption.
Rogue Extension Negotiation Attack
A Rogue Extension Negotiation Attack in SSH involves an attacker introducing or negotiating unsupported or malicious extensions during the SSH session establishment. For example, an attacker might intercept the SSH handshake process and insert a negotiation for an extension that the server does not actually support or that introduces a vulnerability. This can lead to various security issues, such as unauthorized access or data compromise, especially if the server or client is not properly validating the extensions being negotiated. An example of a Rogue Extension Negotiation Attack in SSH could be when an attacker manipulates the SSH extension negotiation process to introduce a rogue extension. For instance, during an SSH session establishment, the attacker, positioned as a man-in-the-middle, injects a message suggesting the use of a custom, insecure extension. The client or server, not properly verifying the legitimacy of this extension, accepts it. This could allow the attacker to bypass certain security mechanisms or exploit vulnerabilities introduced by the rogue extension, compromising the security of the SSH session.
Real-World Implications: The study demonstrates several practical applications of this attack. It can fully break SSH extension negotiation, allowing attackers to downgrade public key algorithms for user authentication or disable countermeasures against keystroke timing attacks introduced in OpenSSH 9.5. An implementation flaw in AsyncSSH was also identified, which, combined with prefix truncation, allows attackers to redirect a victim’s login into a shell controlled by the attacker.
Rogue Session Attack
A Rogue Session Attack in SSH refers to a situation where an attacker initiates an unauthorized SSH session by exploiting vulnerabilities in the SSH server or client. For instance, the attacker might exploit a flaw in the server’s authentication process, allowing them to establish a session without proper credentials. This could enable the attacker to gain unauthorized access to the system, execute commands, or access sensitive data, all while appearing as a legitimate user. This type of attack poses a significant threat to the security of SSH-based systems. An example of a Rogue Session Attack in SSH could involve an attacker exploiting a vulnerability in the SSH server’s configuration. Suppose a server is configured to allow password-based authentication and has a weak or default password. An attacker could use this to gain access by repeatedly trying common passwords until they succeed. Once they gain access, they establish a rogue SSH session, allowing them to execute commands, access sensitive data, or even create backdoors for future access, all while appearing as a legitimate user on the network.
Mitigation:
The study identifies two primary causes for these attacks: the SSH handshake supporting unauthenticated optional messages and the failure to reset message sequence numbers when encryption is enabled. The researchers propose effective and backward-compatible changes to SSH to mitigate these attacks.
The researchers suggest the following countermeasures to address the vulnerabilities in SSH:
- Sequence Number Randomization: Implement randomization of sequence numbers at the start of each new SSH connection. This makes it harder for an attacker to predict or manipulate sequence numbers.
- Encrypted Length Field: Encrypt the length field of SSH packets. This prevents an attacker from inferring the length of the payload, which is crucial for certain types of attacks.
- Constant Time Packet Processing: Process all packets in constant time to avoid side-channel information leakage, which can be used in certain attack vectors.
- Remove Vulnerable MAC Algorithms: Discontinue the use of MAC algorithms that are vulnerable to truncation attacks, such as HMAC-MD5-96 and HMAC-SHA1-96.
- Rekeying After Packet Loss: Trigger a rekeying process if packet loss is detected, which could be indicative of tampering or an active attack.
- Limit Rekeying Frequency: Implement limits on the frequency of rekeying to prevent denial of service attacks that target the rekeying process.
- Improved Client and Server Behavior: Clients and servers should be more robust in handling errors and anomalies during the SSH handshake and connection phases.
These countermeasures aim to enhance the security and integrity of SSH communications by addressing the specific vulnerabilities and attack vectors identified in the research. The Terrapin Attack represents a significant challenge to the security of SSH, a protocol that has remained relevant for over 25 years without major redesign. This discovery calls for immediate attention and action from organizations and individuals relying on SSH for secure communications.
Information security specialist, currently working as risk infrastructure specialist & investigator.
15 years of experience in risk and control process, security audit support, business continuity design and support, workgroup management and information security standards.