Terrapin SSH Attack

johnpoz

@jimp The way I am reading this - if was open to this would be seeing -etm listed with the nmap script?

and will have MAC algorithms in the list which contain -etm in the name.

I have not applied the patch yet for the no-etm, but I don't recall messing with the sshd conf, maybe I did but not seeing that combo on my 23.09.1

$ nmap --script ssh2-enum-algos -sV -p 22 192.168.9.253
Starting Nmap 7.94 ( https://nmap.org ) at 2023-12-18 14:36 Central Standard Time
Nmap scan report for sg4860.home.arpa (192.168.9.253)
Host is up (0.0010s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.4 (protocol 2.0)
| ssh2-enum-algos:
|   kex_algorithms: (2)
|       curve25519-sha256@libssh.org
|       diffie-hellman-group-exchange-sha256
|   server_host_key_algorithms: (3)
|       rsa-sha2-512
|       rsa-sha2-256
|       ssh-ed25519
|   encryption_algorithms: (6)
|       chacha20-poly1305@openssh.com
|       aes256-gcm@openssh.com
|       aes128-gcm@openssh.com
|       aes256-ctr
|       aes192-ctr
|       aes128-ctr
|   mac_algorithms: (6)
|       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
|   compression_algorithms: (2)
|       none
|_      zlib@openssh.com
MAC Address: 00:08:A2:0C:E6:24 (ADI Engineering)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 0.91 seconds

edit:
DOH!!! it is there - nevermind, going to patch it now... I can't read it seems, was looking for it at the end... ugghhh

|       hmac-sha2-512-etm@openssh.com
|       hmac-sha2-256-etm@openssh.com
|       umac-128-etm@openssh.com

edit2: after etm patch applied

$ nmap --script ssh2-enum-algos -sV -p 22 192.168.9.253
Starting Nmap 7.94 ( https://nmap.org ) at 2023-12-18 14:47 Central Standard Time
Nmap scan report for sg4860.home.arpa (192.168.9.253)
Host is up (0.0010s latency).

PORT   STATE SERVICE VERSION
22/tcp open  ssh     OpenSSH 9.4 (protocol 2.0)
| ssh2-enum-algos:
|   kex_algorithms: (2)
|       curve25519-sha256@libssh.org
|       diffie-hellman-group-exchange-sha256
|   server_host_key_algorithms: (3)
|       rsa-sha2-512
|       rsa-sha2-256
|       ssh-ed25519
|   encryption_algorithms: (6)
|       chacha20-poly1305@openssh.com
|       aes256-gcm@openssh.com
|       aes128-gcm@openssh.com
|       aes256-ctr
|       aes192-ctr
|       aes128-ctr
|   mac_algorithms: (3)
|       hmac-sha2-512
|       hmac-sha2-256
|       umac-128@openssh.com
|   compression_algorithms: (2)
|       none
|_      zlib@openssh.com
MAC Address: 00:08:A2:0C:E6:24 (ADI Engineering)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 0.32 seconds

edit3: And can can still ssh into pfsense.. Great info and write up thanks!

Skrillor

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.

dennypage

@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?

johnpoz

@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

Skrillor

@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.

dennypage

@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

@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";

dennypage

FWIW, ssh-audit was updated earlier this evening to include scanning for Terrapin.

jimp

@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.

dennypage

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...

sandie

I fully agree with everything what Jim written, but… ;) OpenSSH 9.6 anytime soon in pfSense? (23.09.2?) :)
Thanks!

jimp

@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.

johnpoz

@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?

sandie

@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.

mcury

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..

jimp

@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.

the other

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. :)

jimp

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.

michmoor

@jimp
The patch works out nicely. Thanks to the prompt response.

monsen

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 incorrect

Tested 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)