Terrapin SSH Attack
-
Hi there,
Fabian Bäumer (one of the authors from Terrapin) here. Just replying here to let you know that a workaround requires both, ChaCha20-Poly1305 and -etm MAC algorithms, to be disabled. If you only disable one of them (patch 1 and 2), the other one may still be exploitable if enabled.
-
@Skrillor said in Terrapin SSH Attack:
Just replying here to let you know that a workaround requires both, ChaCha20-Poly1305 and -etm MAC algorithms, to be disabled. If you only disable one of them (patch 1 and 2), the other one may still be exploitable if enabled.
On my firewall, results from the published vulnerability scanner seem to indicate that disabling chacha alone (patch 1) is sufficient. Are there other potential mitigating factors?
-
@dennypage had you disabled etm? when you disabled chacha..
I just ran the scanner against pfsense, where I ran the etm patch, but still says vuln since I did not disable chacha
Remote Banner: SSH-2.0-OpenSSH_9.4 ChaCha20-Poly1305 support: true CBC-EtM support: false Strict key exchange support: false ==> The scanned peer is VULNERABLE to Terrapin.Keeping in mind I don't really have any concerns - I don't expose ssh to the public, and there is nobody going to be doing mitm on my local network.. But it is a very interesting attack.
I looked into the strict key exchange - and does look like it is available in openssh 9.6.. But its not yet available in my securecrt client.. I looked to see if they had pushed out a new beta even.. But looks like putty has updated to include strict kex
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.11 | Lab VMs 2.8, 24.11 -
@dennypage said in Terrapin SSH Attack:
On my firewall, results from the published vulnerability scanner seem to indicate that disabling chacha alone (patch 1) is sufficient. Are there other potential mitigating factors?
To exploit the Encrypt-then-MAC variant in practice, we additionally require a CBC cipher to be negotiated. If your implementation does not offer any -cbc cipher alongside an -etm@openssh.com MAC, the vulnerability scanner returns false for CBC-EtM. If CBC-EtM isn't supported at all, disabling chacha20-poly1305@openssh.com on its own will have the same effect.
-
@johnpoz said in Terrapin SSH Attack:
had you disabled etm? when you disabled chacha..
No. I only have -etm MACs enabled. I have other things disabled (RSA), which is why I asked about other mitigating factors.
-
@dennypage This is the security patch I have historically applied for ssh:
--- /etc/inc/globals.inc.org 2023-02-02 08:47:26.000000000 -0800 +++ /etc/inc/globals.inc 2023-02-02 22:53:00.000000000 -0800 @@ -365,7 +365,6 @@ global $ssh_keys; $ssh_keys = [ - ['type' => 'rsa', 'suffix' => 'rsa_'], ['type' => 'ed25519', 'suffix' => 'ed25519_'], ]; --- /etc/sshd.org 2023-02-02 08:47:26.000000000 -0800 +++ /etc/sshd 2023-02-02 22:53:00.000000000 -0800 @@ -70,7 +70,7 @@ /* Include default configuration for pfSense */ /* Taken from https://stribika.github.io/2015/01/04/secure-secure-shell.html */ $sshconf = "# This file is automatically generated at startup\n"; -$sshconf .= "KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256\n"; +$sshconf .= "KexAlgorithms curve25519-sha256@libssh.org,curve25519-sha256\n"; /* Run the server on another port if we have one defined */ $sshconf .= "Port $sshport\n"; /* Only allow protocol 2, because we say so */ @@ -116,7 +116,7 @@ } $sshconf .= "X11Forwarding no\n"; $sshconf .= "Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr\n"; -$sshconf .= "MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com\n"; +$sshconf .= "MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com\n"; $sshconf .= "# override default of no subsystems\n"; $sshconf .= "Subsystem\tsftp\t/usr/libexec/sftp-server\n";And the slight adjustment I made for Terrapin:
--- /etc/inc/globals.inc.org 2023-02-02 08:47:26.000000000 -0800 +++ /etc/inc/globals.inc 2023-02-02 22:53:00.000000000 -0800 @@ -365,7 +365,6 @@ global $ssh_keys; $ssh_keys = [ - ['type' => 'rsa', 'suffix' => 'rsa_'], ['type' => 'ed25519', 'suffix' => 'ed25519_'], ]; --- /etc/sshd.org 2023-02-02 08:47:26.000000000 -0800 +++ /etc/sshd 2023-02-02 22:53:00.000000000 -0800 @@ -70,7 +70,7 @@ /* Include default configuration for pfSense */ /* Taken from https://stribika.github.io/2015/01/04/secure-secure-shell.html */ $sshconf = "# This file is automatically generated at startup\n"; -$sshconf .= "KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256\n"; +$sshconf .= "KexAlgorithms curve25519-sha256@libssh.org,curve25519-sha256\n"; /* Run the server on another port if we have one defined */ $sshconf .= "Port $sshport\n"; /* Only allow protocol 2, because we say so */ @@ -116,7 +116,7 @@ } $sshconf .= "X11Forwarding no\n"; -$sshconf .= "Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr\n"; +$sshconf .= "Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr\n"; -$sshconf .= "MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com\n"; +$sshconf .= "MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com\n"; $sshconf .= "# override default of no subsystems\n"; $sshconf .= "Subsystem\tsftp\t/usr/libexec/sftp-server\n"; -
FWIW, ssh-audit was updated earlier this evening to include scanning for Terrapin.
-
@Skrillor said in Terrapin SSH Attack:
Hi there,
Fabian Bäumer (one of the authors from Terrapin) here. Just replying here to let you know that a workaround requires both, ChaCha20-Poly1305 and -etm MAC algorithms, to be disabled. If you only disable one of them (patch 1 and 2), the other one may still be exploitable if enabled.
Curious, the web site says AES-GCM is not affected, and CTR algorithms are not affected in real-world scenarios. By disabling only ChaCha, the only algorithms left active in the configuration on pfSense software are AES-GCM and CTR-based options. Perhaps the web site needs an update to reflect that? Or the patch could only leave AES-GCM enabled. If there is no real-world scenario where CTR+ETM is exploitable it's questionable to label it vulnerable, but that's open for debate I suppose.
Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!
Need help fast? Netgate Global Support!
Do not Chat/PM for help!
-
FWIW, In addition to pfSense, I've tested a few other Linux and Mac systems using both the Terrapin scanner and ssh-audit. On those systems, even without any other changes, both scanners indicate that disabling ChaCha alone (patch 1) is sufficient. I have not tested with just disabling -etm MACs (patch 2).
Of course, both scanners could be broken...
-
I fully agree with everything what Jim written, but… ;) OpenSSH 9.6 anytime soon in pfSense? (23.09.2?) :)
Thanks! -
@sandie said in Terrapin SSH Attack:
I fully agree with everything what Jim written, but… ;) OpenSSH 9.6 anytime soon in pfSense? (23.09.2?) :)
I don't know that this is worth a point release all on its own especially given the timing. Given the high barrier to do anything meaningful, the workaround is sufficient for now unless new information comes up suggesting otherwise.
Remember: Upvote with the 👍 button for any user/post you find to be helpful, informative, or deserving of recognition!
Need help fast? Netgate Global Support!
Do not Chat/PM for help!
-
@jimp So will 9.6 be coming with the next normal release? I mean 9.5 was out a month before 23.09 dropped. I not sure why when 23.09 or even 23.09.1 came out why openssh wasn't updated to 9.5?
An intelligent man is sometimes forced to be drunk to spend time with his fools
If you get confused: Listen to the Music Play
Please don't Chat/PM me for help, unless mod related
SG-4860 24.11 | Lab VMs 2.8, 24.11 -
@johnpoz Newer <> Better often. I am going to apply Jim’s patch, but we will upgrade each and every system which offers OpenSSH 9.6 (hopefully not having too many of nodes).
I was just crosschecking what is the plan. I think this problem may be urgent only for people who need to use those ciphers, but we are going to stop using them. -
I'm not in a hurry to apply these patches since I'm not exposing SSH to the internet.
SSH is only for my MGMT network.So, I'm just waiting right now..
-
@johnpoz said in Terrapin SSH Attack:
@jimp So will 9.6 be coming with the next normal release? I mean 9.5 was out a month before 23.09 dropped. I not sure why when 23.09 or even 23.09.1 came out why openssh wasn't updated to 9.5?
We follow FreeBSD's lead here. We take whichever version is in base. At the moment that is 9.5p1 on dev snapshots. If they put 9.6 in base and we merge after that point, we'll pick it up.
-
hey there,
first...thank you for your work, explanations, patch and work. :)
Then just a short feedback: although I do not have ssh open to the Internet, I used the nmap script to check..., of course, there it was: chacha and etm just as @johnpoz posted. And then it bugged me so much I installed the patch (first one of the two posted by @jimp) anyways. Rebooted, waited, checked ssh (which is still working) and got that mild feeling of relief (even though no ssh to Internet and only homenetwork with chance for MitM relatively small...but it feels better). So thanx for that one moment of easyness in pre-xmas-stress mode. :) -
J jimp referenced this topic on
-
The patch to disable ChaCha and ETM is now available in System Patches Package v2.2.9 as a recommended patch. Read the linked thread before updating the package.
-
@jimp
The patch works out nicely. Thanks to the prompt response.
-
J johnpoz referenced this topic on
-
I just noticed that this patch seems to "break" shh connectivity with Windows.
After applying the patch (and restarting the ssh deamon), when trying to SSH to the box from Windows, it now just reports
Corrupted MAC on input. ssh_dispatch_run_fatal: Connection to 10.11.11.1 port 22: message authentication code incorrectTested disabling the patch, and everything was back working again. I made sure to test from multiple version of Windows and Windows server to confirm a general problem.
Doing a bit of ssh debugging, I noticed that Windows would try to use "umac-128@openssh.com" as the MAC algorithm, which is also is one of the ones listed as supported on the pfsense box after the patch. It also chose aes128-ctr as the Crypto algorithm. (OpenSSH_for_Windows_8.6p1, LibreSSL 3.4.3; among others)
It can be worked around on the Windows side by just excluding the umac-128@openssh.com algorithm either in the client config file or on the command line, or by forcing Windows to use AES-GCM.
I did some further testing, and while the issue isn't technically caused by the patch, it is still present even without the patch if you force the SSH client to choose the same algorithms it would have picked then, I still thought it worthwhile to report it here, since this patch is technically what will trigger the "bad" MAC algorithm.
This may (or may not) be a fault of Windows (or the OpenSSH client version compiled for Windows),
(Running Netgate 4100, 23.09.1-RELEASE)
-
Simple fix that I've found, to fix my Windows to be able to ssh to my pfSense install (after applying the patch) is the following.
Add the following like to c:\users<user>.ssh/config
MACs hmac-sha2-512
This forced my ssh to use that MAC (message authentication code), of which pfSense is fine with.
