SSH’s Vulnerability: The Impact of CVE-2023-48795

In the ever-evolving world of cybersecurity, staying one step ahead of potential threats is critical.

One such threat that has recently emerged is represented by CVE-2023-48795, also known as the Terrapin Attack.

This vulnerability poses a significant risk to Secure Shell (SSH) clients and servers, potentially allowing nefarious actors to bypass security measures and access sensitive information.

In this blog post, we delve into the details of CVE-2023-48795, exploring how it operates, its potential impact, and most importantly, how you can protect your systems against this looming cybersecurity threat.

How the Terrapin Attack Exploits OpenSSH Extensions

The SSH transport protocol, a security measure found in OpenSSH and other products, has been identified to have a vulnerability referred to as the Terrapin attack (CVE-2023-48795).

This flaw allows remote attackers to bypass certain integrity checks, leading to the omission of some packets from the extension negotiation message.

The consequence of this is that a client and server may establish a connection with downgraded or disabled security features.

The root cause lies in the SSH Binary Packet Protocol (BPP) implemented by these extensions mishandling the handshake phase and the use of sequence numbers.

For instance, this flaw enables an effective attack against SSH’s use of ChaCha20-Poly1305 and CBC with Encrypt-then-MAC. It occurs in [email protected] and [email protected] MAC algorithms if CBC is used.

The Role of a Man-in-the-Middle Attacker in the Terrapin Attack Exploitation

The SSH server on the remote end is susceptible to a prefix truncation attack called Terrapin.

In this scenario, a remote attacker can act as a man-in-the-middle and bypass integrity checks, thus weakening the security of the connection.

It’s important to note that this vulnerability only affects remote SSH servers that support either ChaCha20-Poly1305 or CBC with Encrypt-then-MAC and do not have strict key exchange countermeasures in place.

The plugin does not check for vulnerable software versions.

The Mechanics of Man-in-the-Middle Attacks in Terrapin Exploits

In a typical Man-in-the-Middle (MitM) attack scenario, the attacker has the potential to bypass the chosen cryptographic protocol.

This is done by intentionally omitting the EXT_INFO message that is generally utilised for negotiating various protocol extensions, without alerting either the client or server.

Under normal circumstances, any packet deletion would be detected by the client when it receives the subsequent binary packet from the server, due to sequence number discrepancies.

However, the attacker cleverly sidesteps this detection by inserting a specific packet during the handshake process, thereby manipulating sequence numbers.

The exact content of this injected packet varies depending on the cryptographic cipher being targeted.

ChaCha20-Poly1305

Here, the MitM introduces an SSH2_MSG_IGNORE message before the handshake is completed.

This alteration in sequence numbers facilitates the MitM to remove the EXTINFO from within the secure channel.

CBC-EtM

In this case, the MitM injects an UNKNOWN message prior to the conclusion of the handshake.

Similar to the previous scenario, this enables the attacker to strip the EXTINFO from the secure channel.

However, the success rate here is probabilistic and hinges on two different approaches to using MACs (Message Authentication Codes): EaM (Encrypt-and-MAC) and EtM (Encrypt-then-MAC).

The Elevated Risk Posed by Encrypt-then-MAC (EtM) Mode

EtM, where the MAC is computed over the ciphertext, poses a greater risk. In this mode, the packet length is not encrypted allowing the MAC to be checked before decryption.

If an attacker truncates the ciphertext under this mode using Terrapin, they can manipulate the unencrypted length, likely bypassing MAC verification and enabling packet truncation.

Specifically, this allows the MitM attacker to strip the EXTINFO from within the secure channel, mirroring the scenario with ChaCha20-Poly1305.

Probabilistic Success Rate of Attacks in CBC-EtM Cipher

In CBC-EtM, the MAC is calculated over the sequence number, the unencrypted packet length, and the ciphertext of the packet.

The success rate of the attack is probabilistic due to the potential risk of MAC failure when truncation occurs (i.e., when the EXT-INFO packet is sliced).

The outcome largely depends on the specific details of the cryptographic implementation.

Potential Consequences of Signature Downgrade Attacks

Executing an attack on OpenSSH to highlight the potential impact of this vulnerability might lead to issues with user authentication, as detailed in this section.

The following code, extracted from OpenSSH 9.5p1, illustrates how the message is constructed:

static int
kex_send_ext_info(struct ssh *ssh)
{
	int r;
	char *algs;

	debug("Sending SSH2_MSG_EXT_INFO");
	if ((algs = sshkey_alg_list(0, 1, 1, ',')) == NULL)
		return SSH_ERR_ALLOC_FAIL;
	/* XXX filter algs list by allowed pubkey/hostbased types */
	if ((r = sshpkt_start(ssh, SSH2_MSG_EXT_INFO)) != 0 ||
	    (r = sshpkt_put_u32(ssh, 3)) != 0 ||
	    (r = sshpkt_put_cstring(ssh, "server-sig-algs")) != 0 ||
	    (r = sshpkt_put_cstring(ssh, algs)) != 0 ||
	    (r = sshpkt_put_cstring(ssh,
	    "[email protected]")) != 0 ||
	    (r = sshpkt_put_cstring(ssh, "0")) != 0 ||
	    (r = sshpkt_put_cstring(ssh, "[email protected]")) != 0 ||
	    (r = sshpkt_put_cstring(ssh, "0")) != 0 ||
	    (r = sshpkt_send(ssh)) != 0) {
		error_fr(r, "compose");
		goto out;
	}
	/* success */
	r = 0;
 out:
	free(algs);
	return r;
}

Under the server-sig-algs, a series of arguments are attached to the packet. This list is significant for one of the available methods for public key-based authentication.

This list explicitly outlines the supported signature algorithms, which essentially dictates whether communication using a specific signature is possible.

In the absence of this list, the server and client are unable to utilize the most recent signature algorithms, such as rsa-sha2-512 that employs SHA2 hashing – SHA512, in accordance with RFC 8308.

To illustrate the downgrade attack, we will employ the Terrapin Proof of Concept (PoC) and compel the client to establish a connection with the server using password-based authentication (as opposed to the more common key-based authentication).

This method of connection is less secure than key-based authentication and can be manipulated to create the conditions that lead to the secondary impact of this attack.

We will initiate the attack by injecting an IGNORE packet and eliminating the EXT_INFO message – thus connecting to the MitM server rather than the standard SSH server.

Consequently, our public key, which was previously recognized and accepted, is now disregarded – leading to the usage of an alternative authentication method.

Normal Connection vs. Signature Downgrade Attack in OpenSSH Server Logs

To comprehend the mechanics and impact of a signature downgrade attack on OpenSSH, it’s beneficial to examine the server debug logs. It’s here that we can discern how this type of attack differs from a standard connection.

When we look at a normal connection (where the public key is accepted), the server debug logs display the following sequence of events:

debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth]
debug1: SSH2_MSG_KEX_ECDH_INIT received [preauth]
debug1: rekey out after 134217728 blocks [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: Sending SSH2_MSG_EXT_INFO [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: rekey in after 134217728 blocks [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user user service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: userauth-request for user user service ssh-connection method publickey [preauth]
debug1: attempt 1 failures 0 [preauth]
debug1: userauth_pubkey: publickey test pkalg rsa-sha2-512 pkblob RSA SHA256:PkY4eNr7FRIZn31XNF+4J71s2Fs+5r7CVGFH5o5ck1E [preauth]

However, when we initiate a connection to the MitM server and execute a signature downgrade, the server debug logs change as follows:

debug1: SSH2_MSG_KEX_ECDH_INIT received [preauth]
debug1: rekey out after 134217728 blocks [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: Sending SSH2_MSG_EXT_INFO [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: rekey in after 134217728 blocks [preauth]
debug1: KEX done [preauth]
debug1: userauth-request for user user service ssh-connection method none [preauth]
debug1: attempt 0 failures 0 [preauth]
debug1: userauth-request for user user service ssh-connection method keyboard-interactive [preauth]
debug1: attempt 1 failures 0 [preauth]
debug1: keyboard-interactive devs  [preauth]
debug1: auth2_challenge: user=user devs= [preauth]

If you’re running an OpenSSH client in debug mode during this process, you’ll encounter the following error message:

debug1: send_pubkey_test: no mutual signature algorithm

The reason for this error message is that the ‘server-sig-algs’ is absent from the EXT_INFO message. This omission prevents the client from using key-based authentication.

The absence of ‘server-sig-algs’ implies that the client and server cannot agree on a mutual signature algorithm, thus leading to the fallback on other, less secure authentication methods.

Bypassing Keystroke Timing Obfuscation

Keystroke timing information can potentially expose sensitive data. By analyzing the exact length of a user’s password and the precise timing between each keystroke, nefarious actors can potentially crack the password.

To mitigate this risk, OpenSSH version 9.5p1 introduced a new security feature known as ‘keystroke timing obfuscation’.

This innovative feature obscures the timing of keystrokes by sending traffic at fixed intervals – by default, every 20 milliseconds. This is a significant departure from the previous approach, which transmitted data immediately after each key press.

However, for this obfuscation to be effective, both the client and server must have this feature implemented, which means they must both be running at least OpenSSH version 9.5p1.

The compatibility information that enables this feature is relayed through the EXT_INFO message. Unfortunately, this message can be removed using the Terrapin attack.

When examining a Wireshark capture of a typical connection using OpenSSH 9.5p1, you can see this feature in action.

The time displayed near the packet numbers represents the seconds elapsed from the previous displayed packet. You’ll notice a consistent difference of 20-21 milliseconds, demonstrating the obfuscation feature at work.

However, a malicious actor could inject an IGNORE packet and strip the EXT_INFO message, thus directing the connection to a Man-in-the-Middle (MitM) server instead of the usual SSH server.

A Wireshark capture of this compromised SSH connection can reveal vital details.

Even when both the client and server are running OpenSSH 9.5p1, the timing obfuscation can be bypassed.

This is evident from the inconsistent timings for each packet being sent in the connection.

It’s important to note that when keystroke timing obfuscation isn’t used, or is bypassed in the case of OpenSSH 9.5p1, a signature downgrade can be effectively employed to crack the password.

This highlights the critical importance of this security feature and the potential risks if it’s compromised.

Decoding the Significance of Terrapin Attacks in the Cybersecurity Landscape

The unearthing of the Terrapin Attacks, specifically CVE-2023-48795, casts a spotlight on the susceptibility of even seemingly secure protocols like SSH.

This revelation underscores the critical necessity for robust and progressive vulnerability management strategies, including regular patching and prioritization of vulnerabilities, particularly in hybrid enterprise ecosystems.

SSH is renowned for its security and ease of installation, making it a popular choice across a diverse range of operating systems. This includes not only the devices used by administrators but also the servers that enable remote connectivity to enterprise networks.

Essentially, the emergence of Terrapin Attacks implies that the security of SSH, a vital part of the remote access infrastructure that privileged access administrators depend upon to thwart sniffing attacks, has been compromised.

This serves as a stark reminder that no system is impervious to threats, making it crucial for organizations to maintain vigilant cybersecurity practices and stay abreast of evolving threat landscapes.

This could involve investing in advanced cybersecurity solutions, conducting regular audits, and fostering a culture of cybersecurity awareness across all levels of the organization.

Identifying the Susceptible Software Versions

Versions of OpenSSH preceding 9.6, along with a host of other software and libraries, are exposed to potential threats.

This list includes well-known names such as LibSSH, PuTTY, AsyncSSH, Dropbear SSH, Transmit, paramiko, and golang-go.crypto – all of which are susceptible to potential vulnerabilities.

OpenSSH’s Approach to Mitigate the Terrapin Attack

The Terrapin Attack, as detailed in the original technical research paper, posed a significant security threat.

To address this, the researchers proposed two primary countermeasures – sequence number reset and verification of the entire handshake process.

Sequence Number Reset

The first countermeasure aims at resetting the client or server sequence numbers to zero when the encryption keys are activated. This step neutralizes the manipulations that were previously described and can potentially impact the encryption.

Handshake Process Verification

The second countermeasure is designed to enhance security by thoroughly verifying the entire handshake process between the client and server.

This verification process helps detect any manipulation attempts by a potential Man-in-the-Middle attacker.

It includes the exchange of a Message Authentication Code (MAC) of the complete transcript at the beginning of the secure channel, akin to TLS FINISHED messages.

To tackle the issue, OpenSSH introduced a new “strict KEX” protocol that implements the following:

If any packet not of the expected or correct type is received, or if the first packet is not SSH2_MSG_KEXINIT, the connection should be terminated.

Unexpected packets include messages like SSH2_MSG_DEBUG and SSH2_MSG_IGNORE, which are typically valid during the connection but can facilitate the attack.

After sending or receiving an SSH2_MSG_NEWKEYS message, the sequence number for packets should be reset to zero.

This rule is applicable throughout the duration of the connection, not just immediately after the SSH2_MSG_NEWKEYS message.

These fixes were incorporated in OpenSSH version 9.6p1, and they closely align with the recommendations made by the researchers.

As highlighted in the SSH release notes, either of these changes should be sufficient to thwart the Terrapin Attack.

This demonstrates OpenSSH’s commitment to continuous improvement and its proactive approach to maintaining the security integrity of its software.

Mitigation Strategies for the SSH Transport Protocol Vulnerability

To mitigate this issue, it is recommended to contact the vendor for an update with strict key exchange countermeasures or disable the affected algorithms.

The Terrapin Attack, represented by CVE-2023-48795, poses a significant threat to the security of SSH clients and servers. However, it’s possible to mitigate this vulnerability without necessarily upgrading your systems.

For OpenSSH servers and clients, the primary solution lies in disabling the vulnerable ChaCha20-Poly1305 cipher. This can be achieved by modifying the configurations as follows:

# In /etc/ssh/ssh(d)_config
Ciphers [email protected]

Please pay attention to the ‘-‘ at the beginning of the chacha20 cipher string. Once you’ve made these adjustments, you’ll need to restart your SSH server for the changes to take effect.

Additionally, ensure that any aes(128|192|256)-cbc ciphers are not explicitly enabled in your OpenSSH configuration when using the default MACs, as these ciphers are disabled by default.

For those leveraging Paramiko, the ChaCha20-Poly1305 cipher is not supported.

Hence, to mitigate CVE-2023-48795, disable the aes(128|192|256)-cbc and any Encrypt-then-MAC (EtM) MACs when connecting using Paramiko. This mitigation strategy is applicable from Paramiko version 2.6 onwards.

Here’s an illustrative example:

import paramiko

SERVER_IP = '127.0.0.1'

ssh_client = paramiko.SSHClient()
ssh_client.set_missing_host_key_policy(paramiko.AutoAddPolicy())
ssh_client.connect(SERVER_IP, disabled_algorithms={'ciphers': ['aes128-cbc', 'aes192-cbc', 'aes256-cbc'], 'macs': ['[email protected]', '[email protected]']})

These mitigation strategies are beneficial for those who cannot immediately upgrade to a newer version of OpenSSH or Paramiko.

However, upgrading to the latest versions remains the most effective way to protect your systems from CVE-2023-48795 and other potential vulnerabilities.

Conclusion

Understanding CVE-2023-48795, or the Terrapin Attack, is crucial for maintaining the security integrity of your SSH clients and servers.

While it presents a significant challenge, countermeasures are available that can effectively mitigate this vulnerability.

From upgrading to the latest versions of OpenSSH and Paramiko, to adjusting configuration settings, various strategies can be employed to protect your systems.