Terrapin SSH Attack

jimp

This is pretty fresh so still fairly preliminary information available at the moment: https://terrapin-attack.com/

Barrier to exploit is pretty high. Requires an MitM and certain combinations of options, namely, ChaCha20-Poly1305 and MACs which use Encrypt-then-MAC (-etm). The SSH daemon on pfSense does enable that combination of algorithms but (a) admins shouldn't be exposing their SSH ports to the Internet and (b) if someone can MitM your local network you probably have more pressing concerns than SSH on the firewall.

That said, if you do expose your SSH daemon to untrusted networks and want to work around this vulnerability, you can take one of the following actions:

Disable both in sshd (Recommended) -- terrapin-no-etm-no-chacha.patch
Disable ChaCha20-Poly1305 in sshd (MAY be sufficient) -- terrapin-no-chacha.patch

Choose one of those options and add the patch to the System Patches package.

After applying the patch, reboot or restart the SSH daemon:

# /usr/local/bin/php-cgi -f /etc/sshd

After restarting the SSH daemon, ensure that available/necessary SSH clients can still connect. If they cannot, then revert the patch, restart the SSH daemon, and then try a different patch. Also consider updating the SSH client if it fails to connect, or check its configuration to ensure it has encryption and MAC algorithms enabled which overlap with options enabled on the server.

You can use nmap to verify the list of offered encryption and MAC algorithms on a given server:

$ nmap --script ssh2-enum-algos -sV -p 22 x.x.x.x

As mentioned above, affected configurations will list chacha20-poly1305@openssh.com in the encryption algorithms and will have MAC algorithms in the list which contain -etm in the name.

Various operating systems are patching SSH daemons and clients to work around the issue in other ways, such as by adding a strict key exchange mode, but for that to work both the client and server must support it. For the time being it seems like it would be more effective to disable the problematic combination of options on the server, hence these patches.

However, since it's not yet clear which method is ideal (and that may vary by environment and clients), we are not issuing a specific recommended patch until we have more information.

EDIT: Re-ordered patches to note which is recommended, removed ETM only patch.

EDIT 2: 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.

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.