The Terrapin Attack is the biggest SSH vulnerability that we have seen in decades. Terrapin splices TCP sequence numbers to truncate SSH extension negotiation. While this is a concern, effective exploitation of this vulnerability is very difficult, and mitigation is very easy! The paper notes that AES-GCM is not vulnerable to the attack:
AES-GCM (RFC5647) is not affected by Terrapin as it does not use the SSH sequence numbers. Instead, AES-GCM uses the IV obtained from key derivation as its nonce, incrementing it after sending a binary packet. In a healthy connection, this results in the nonce being at a fixed offset from the sequence number.
The original Encrypt-and-MAC paradigma from RFC4253 protects the integrity of the plaintext, thus thwarting our attack, which yields one pseudorandom block during decryption.
This means you can simply use the AES-GCM cipher in SSL communication by configuring your hosts to default to that protocol. The AES-GCM cipher has been supported in SSH since version 6.2 so pretty much all supported distributions going back to at least 2014 have an easy mitigation.
Mitigating on the server
Newer Servers that are using `update-crypto-policies` (RHEL, Alma, Rocky, Oracle, newer Ubuntu and Debian)
Newer operating systems that provide the command update-crypto-policies, create a new policy file and activate it. You can modify `DEFAULT` to something different if you are using a different policy, but “DEFAULT” works for most systems.
# cat /etc/crypto-policies/policies/modules/TERRAPIN.pmod cipher@ssh = -CHACHA20* ssh_etm = 0 # update-crypto-policies --set DEFAULT:TERRAPIN Setting system policy to DEFAULT:TERRAPIN Note: System-wide crypto policies are applied on application start-up. It is recommended to restart the system for the change of policies to fully take place.
Older Servers are not using `update-crypto-policies`
Simply add this to the bottom of /etc/ssh/sshd_config:
Match All Ciphers aes256-gcm@openssh.com
Note that Match all
is added in case you have other match blocks. Of course, if you prefer, you can exclude the Match all
line and insert the cipher above any match blocks so that it is a global option.
Forcing aes256-gcm is a bit of a hammer, it certainly works but may be more than you need. Ultimately only Chacha20 and ETM-based MACs need to be disabled, so modify this as you see fit.
Testing Server Mitigation
The Terrapin research team has published a scanning/test tool. There is GitHub page to compile it yourself, or pre-compiled binaries for the most common OS’s are available on the releases page. The result should look something like this. “Strict key exchange support” is unnecessary if the vulnerable ciphers are disabled. As you can see, it says “NOT VULNERABLE” in green:
Mitigating on the client
This can be done per user or system-wide. To configure it for all users on a system, add this to the bottom of /etc/ssh/ssh_config:
Ciphers aes256-gcm@openssh.com
To configure it for a single user, add this to the top of the SSH configuration in your home directory (~/.ssh/config)
Ciphers aes256-gcm@openssh.com
Mitigating Windows SSH Clients
Unfortunately, the following Windows packages do not support AES-GCM and cannot be mitigated in this way:
- PuTTY does not support AES-GCM
- Update: PuTTY now supports the
kex-strict
extension, but your server needs to support it.
- Update: PuTTY now supports the
- WinSCP does not support AES-GCM
If you use any of these then it would be a good idea to switch to an SSH client that supports AES-GCM.
Windows clients that support AES-GCM
Here are a few Windows clients that do support AES-GCM, in alphabetical order, by second letter:
The Fine Print
The examples above are one (very simple) way of dealing with this. Ultimately you need to disable the ETM and ChaCha20 ciphers. You can see what is configured in ssh as follows:
]$ ssh -Q mac|grep etm hmac-sha1-etm@openssh.com hmac-sha1-96-etm@openssh.com hmac-sha2-256-etm@openssh.com hmac-sha2-512-etm@openssh.com hmac-md5-etm@openssh.com hmac-md5-96-etm@openssh.com umac-64-etm@openssh.com umac-128-etm@openssh.com ]$ ssh -Q cipher|grep -i cha chacha20-poly1305@openssh.com
-Eric
From the developer’s website for PuTTY
https://www.chiark.greenend.org.uk/~sgtatham/putty/
Latest news
2023-12-18 PuTTY 0.80 released
PuTTY 0.80, released today, includes a fix for the Terrapin vulnerability in some SSH protocol extensions (aka CVE-2023-48795). The issue also needs patching in the server.
Hi Eric,
The SSH version on my device is: SSH-2.0-OpenSSH_8.2
I tried to fix Terrapin SSH Attack with some methods.
At the end of the ‘/etc/ssh/ssh_config’ and ‘/etc/ssh/sshd_config’ files, the following configuration was added:
Ciphers aes256-gcm@openssh.com
and restarted the sshd service.
But Terrapin-Scanner reports that the device still supports ChaCha20-Poly1305.
Later I also tried to change the added configuration to:
Ciphers -chacha20-poly1305@openssh.com
Couldn’t get the vulnerability fixed either.
The Report is:
Remote Banner: SSH-2.0-OpenSSH_8.2
ChaCha20-Poly1305 support: true
CBC-EtM support: false
Strict key exchange support: false
The scanned peer is VULNERABLE to Terrapin.
Am I overlooking something?
1. Try placing “Match All” above the ciphers line.
2. Are there any devices between the program doing the scanning and the server being scanned? For example, if a firewall or router is between them, then it is possible that you are scanning the router and not the device. Of course, if you can SSH to what you think it is, and it lets you in as you expect, then that assumption would be wrong.
3. Beyond that I recommend asking on the OpenSSH mailing list because it sounds like it is not behaving as intended: https://www.openssh.com/list.html
4. If you hire us for service, we could inspect it. Email or use the contact form if you’re interested.
Thanks for your reply, I have found the problem. My device is an embedded Linux device and the configuration files about ssh are addressed in ‘/etc/sshd/sftpd_config’ and ‘/etc/sshd/sftpd_config’. After finding the correct config files, I was able to disable the ChaCha20-Poly1305 and the problem was solved.
Awesome, I’m glad you were able to get it working!