Understanding the Terrapin Attack
The Terrapin attack, also known as CVE-2023-48795, is a potential threat to the security of SSH connections. It operates by truncating the extension negotiation message (as per RFC8308) that is exchanged between the client and the server. This could potentially compromise the security of your connection, but not in all cases.
Here’s an in-depth analysis.
Which clients/servers are vulnerable?
Almost all implementations are susceptible to this attack, except those that have implemented a specific fix.
Are all my SSH servers at risk of a Terrapin Attack?
Not necessarily, or if so, only to a very limited extent. The possible attacks and their requirements are discussed in the following sections.
What kind of attacks can be executed?
There are three types of Terrapin attacks that can be performed:
1. Exploiting a vulnerability present in the AsyncSSH server.
2. Disabling the keystroke timing countermeasures implemented by any server. However, many servers don’t implement these measures due to the complexity and low success rate of exploitation, especially when strong passwords are used.
3. Forcing some weak algorithms, mainly SHA-1, on any server. Although SHA-1 is considered weak, it’s not vulnerable when used within the SSH protocol, thus the security risk is extremely limited.
What does it take to execute a Terrapin attack?
The Terrapin attack requires a man-in-the-middle attack, meaning the attacker needs access to the client or server local network. A client connecting to a rogue Wi-Fi in a public place is sufficient. If a server can only be accessed in SSH from the company network or a VPN, the attack can only be performed by an insider.
How can I protect my SSH server from the Terrapin Attack?
Here are some solutions:
1. Upgrade your clients and servers to support « strict key exchange ». Most servers, especially those embedded in a Linux distribution, currently do not support this protocol extension. Both the client and the server need to support this extension to be secure.
2. Disable all weak algorithms on your server. This ensures that even if the Terrapin attack succeeds, it won’t be able to downgrade your security.
3. Enforce strong passwords or key authentication. This blocks the exploitation of the Terrapin attack.
4. Disable the algorithms that make the Terrapin attack possible: ChaCha20-Poly1305 and CBC-Encrypt-then-MAC. Instead, keep the strongest ones: aes256-gcm & hmac-sha2-512.
5. Restrict SSH access from the Internet. By enforcing a VPN connection before reaching your server, you block all attacks from the outside world; only an insider could perform the attack.
Implement these general-purpose best practices for enhanced security, regardless of the Terrapin attack, with the exception of the first recommendation.
Hardening Guidelines
The ability to enable or disable algorithms is inherently product-dependent. For the purpose of this discussion, we’ll focus on Linux, given its widespread usage.
There are typically two methods to configure cryptographic algorithms: through the sshd service or via system-level policies. Each method has its own benefits.
sshd Configuration (/etc/ssh/sshd_config):
– This approach is universal and applicable across all platforms.
– It requires the specification of permitted algorithms; it does not allow for the disabling of specific ones.
System Cryptographic Policies:
– Not all platforms offer this feature.
– It allows for the enabling and disabling of algorithms.
– This feature provides the flexibility to manage settings exclusively for SSH or globally for all protocols, such as disabling SHA-1 across all protocols.
– It serves as a centralized hub for managing all your cryptographic policies.
– The policies are divided into multiple files, facilitating easy and flexible deployment.
– Note: On certain platforms, the policies may not be able to manage the OpenSSH internal ciphers; in such cases, reliance on the sshd configuration is necessary.
It’s possible to integrate both options, such as disabling all weak algorithms in the policies and whitelisting permitted algorithms in the sshd configuration.
Finally, to verify the impact of your changes, use the following command: `ssh -vv 127.0.0.1`. The result of all accepted algorithms will be displayed on the lines « debug2: ciphers stoc: » & « debug2: MACs stoc: ».
Want to stay up to date with the latest threats? Subscribe to our SOC newsletter.
Check out our website.
