SSH shaken, not stirred by Terrapin vulnerability
A vulnerability in the SSH protocol can be exploited by a well-placed adversary to weaken the security of people’s connections, if conditions are right.
In a successful man-in-the-middle attack, the adversary may be able to force SSH clients to use weaker authentication methods and disable some defense mechanisms. It is hard right now to pin down the true realistic impact of the flaw because it all depends on individual client-server configurations, implementations of the protocol, and other variables. SSH is mainly used to connect into remote systems to use or administer them via a command-line interface.
The technique, dubbed the Terrapin Attack, is described in a technical write-up shared this week by Fabian Bäumer, Marcus Brinkmann, and Jörg Schwenk, who are computer scientists at Germany’s Ruhr University Bochum. In October, after discovering the vulnerability, they privately disclosed the details to SSH client and server developers to address. Now it’s all public with patches and info coming out.
The trio have released accompanying proof-of-concept scripts and other materials on GitHub if you’re interested in the low-level details. There’s also an open source tool that can be used to determine whether your SSH client or server is vulnerable to Terrapin.
As a result of this study’s findings, SSH software updates should be making their way to users, and there are mitigations available in the meantime. This isn’t one to panic over, because someone will need to man-in-the-middle (MITM) your vulnerable connection rather than directly attack your server; it’s a downgrade attack primarily rather than a decryption or command injection issue; and there are ways to immediate protect yourself from Terrapin attacks.
There are three issues to be aware of: CVE-2023-48795, which is the generic exploitable protocol-level SSH vulnerability; and CVE-2023-46445 and CVE-2023-46446 specific to the Python SSH client AsyncSSH, which has an estimated 60,000 daily downloads.
In AsyncSSH’s case, it was found the open source code had implementation errors specific to that client that could be exploited with a Terrapin-style attack to, for instance, cause a victim to unknowingly log into an attacker-controlled shell account rather than their own. It’s an example of how different clients and servers may be vulnerable to Terrapin in different ways. AsyncSSH was patched to address CVE-2023-46445 and CVE-2023-46446 in version 2.14.1, and the generic CVE-2023-48795 in 2.14.2.
How the Terrapin Attack works
Terrapin (CVE-2023-48795) is a prefix truncation attack, and allows a MITM attacker to downgrade the security of an SSHv2 connection during extension negotiation.
It’s similar to an issue spotted in TLS 1.3 by Cédric Fournet in 2015 and fixed at the draft stage.
As the university trio put it this week, a successful Terrapin attack can “lead to using less secure client authentication algorithms and deactivating specific countermeasures against keystroke timing attacks in OpenSSH 9.5.” In some very specific circumstances, it could be used to decrypt some secrets, such as a user’s password or portions of it as they log in, but this is non-trivial and will pretty much fail in practicality.
Let’s get to the nitty gritty. We’ll keep it simple; for the full details, see the paper. When an SSH client connects to an SSH server, before they’ve established a secure, encrypted channel, they will perform a handshake in which they exchange information about each other in plaintext. Each side has two sequence counters: one for received messages, and one for sent messages. Whenever a message is sent or received, the relevant sequence counter is incremented; the counters thus keep a running tally of the number of sent and received messages for each side.
As a MITM attack, Terrapin involves injecting a plaintext ‘ignore’ message into the pre-secure connection, during the handshake, so that the client thinks it came from the server and increments its sequence counter for received messages. The message is otherwise ignored. Then once the secure channel is established, the MITM attacker blocks the server from sending a message to the client about additional defenses. It doesn’t matter that the message is encrypted: the attacker just prevents it from arriving, and the client never sees nor acts on it.
Because a plaintext ignore message was inserted earlier, the client still ultimately has the expected number of received messages, and the server thinks it’s sent the correct number of messages.
Even though a message was intercepted and blocked by the MITM attacker during initialization, the send and receive sequence counters appear correct on both sides, which is vital because these counts are subsequently used to verify the integrity of the handshake process. If the counts are correct, the connection is allowed to continue. That’s why the ‘ignore’ message is inserted, so that when the extension message is blocked in the secure channel, the client and server are none-the-wiser.
This is depicted in the following diagram from the Terrapin paper – the sequence numbers are bold at the point they are verified:
Arbitrary numbers of ‘ignore’ messages can be inserted to knock out messages from the server to client during connection establishment. As you can see in the technical write-up, you can be a bit tricky with the order of the injected and blocked messages to pull off more complex attacks. Through this it’s possible to mess with the connection’s set up, downgrade the security used, disable extensions, and potentially exploit deeper weaknesses in specific client or server implementations.
That all said, the encryption algorithm used for the secure channel is crucial as to whether an SSH connection can be successfully attacked or not.
ChaCha20-Poly1305 is said to be “vulnerable and perfectly exploitable” by Terrapin due to the way sequence numbers are used in key derivation. There isn’t a cryptographic weakness in this algorithm, just in the way it’s used for SSH.
CBC-Encrypt-then-MAC (CBC-EtM) is also vulnerable and “probabilistically” exploitable, we’re told, though depending on the implementation, the attack may fail. The CTR-Encrypt-then-MAC algorithm is vulnerable but isn’t practically exploitable.
More than three-quarters (77 percent) of public-facing SSH servers support “at least one mode that can be exploited in practice,” the university trio said, and 57 percent of those set an exploitable algorithm as the preferred choice.
To patch or mitigate?
The boffins were quick to say that this isn’t a flaw that requires folks to down tools and address as a priority.
“The attack requires an active man-in-the-middle attacker that can intercept and modify the connection’s traffic at the TCP/IP layer,” they said. “Additionally, we require the negotiation of either ChaCha20-Poly1305, or any CBC cipher in combination with Encrypt-then-MAC as the connection’s encryption mode.”
Keeping an eye out for patches or updates is a good bet, and installing them when able to: if you’re on Linux, for instance, these should come in via your usual distro update method.
OpenSSH 9.6 was released on Monday, which among other things addressed Terrapin with a strict key exchange protocol that, if both the server and client support, should thwart these attacks.
“Connecting a vulnerable client to a patched server, and vice versa, still results in a vulnerable connection,” the academics noted.
Meanwhile, Putty 0.8 was released this week to address Terrapin. libssh 0.10.6 and libssh 0.9.8 were also emitted to defend against the technique. We imagine there will be others.
Besides installing updates, admins can mitigate attacks by disabling the affected encryption modes in the configuration of their SSH servers, and use non-vulnerable algorithms such as AES-GCM instead.
There is a risk that if the server is configured improperly or one’s client don’t support the config, access to the server may be lost, the researchers warned. Older versions of OpenSSH (6.2 and 6.3) are also vulnerable to a buffer overflow when using AES-GCM, so watch out there.
“Terrapin is not a simple software bug that can be fixed with an update to a single library or component,” the trio concluded. “Instead, clients and servers need to be updated to protect the connection against prefix truncation attacks. This means we need to raise awareness of the issue across all SSH client and server implementations, which is a considerable effort.” ®
READ MORE HERE