Just for information
Regards
2 Likes
Here is my input on this.
Fixed in openssh-9.6p1 which was merged into the git repo on 30th December 2023 and will end up in Core Update 183.
Info from OpenSSH
While cryptographically novel, the security impact of this attack
is fortunately very limited as it only allows deletion of
consecutive messages, and deleting most messages at this stage of
the protocol prevents user user authentication from proceeding and
results in a stuck connection.The most serious identified impact is that it lets a MITM to
delete the SSH2_MSG_EXT_INFO message sent before authentication
starts, allowing the attacker to disable a subset of the keystroke
timing obfuscation features introduced in OpenSSH 9.5. There is no
other discernable impact to session secrecy or session integrity.
openssh-9.6 resolves this by
OpenSSH 9.6 addresses this protocol weakness through a new “strict
KEX” protocol extension that will be automatically enabled when
both the client and server support it. This extension makes
two changes to the SSH transport protocol to improve the integrity
of the initial key exchange.
Note that to get the protection all clients also need to have their ssh client packages updated in addition to the IPFire system. This means not just openssh but also things such as putty, winscp, filezilla, dropbear etc, etc.
The risk is only present if accessing IPFire’s ssh from the internet. If the ssh access on IPFire is only done from the internal green lan or via VPN from a roadwarrior there should not be any risk, unless bad actors can have access to the trusted lan network.
So it is a vulnerability and it will be fixed in Core Update 183 but unlikely to be experienced unless ssh access is done from the internet where a bad actor can attempt to interpose themselves via a MITM attack.
7 Likes
IPfire 182 is VULNERABLE…
Test of my IPfire, SSH running at port 222:
$ ./Terrapin_Scanner_Linux_amd64 -connect 192.168.123.1:222
================================================================================
==================================== Report ====================================
================================================================================
Remote Banner: SSH-2.0-OpenSSH_9.5
ChaCha20-Poly1305 support: true
CBC-EtM support: false
Strict key exchange support: false
The scanned peer is VULNERABLE to Terrapin.
Note: This tool is provided as is, with no warranty whatsoever. It determines
the vulnerability of a peer by checking the supported algorithms and
support for strict key exchange. It may falsely claim a peer to be
vulnerable if the vendor supports countermeasures other than strict key
exchange.
For more details visit our website available at https://terrapin-attack.com
The test was against 181. I updated to 182, rebooted and it is still VULNERABLE. SSH was updated to SSH-2.0-OpenSSH_9.5
The issue is that line with “Strict key exchange support” is false.
I tested against Debian host, it runs SSH-2.0-OpenSSH_9.2p1 and is not vulnerable…
There is more, SSH client at IPfire…
Start Scanner in listen mode and try to connect with ssh from ipfire gateway, I see client is VULNERABLE…
user@ubuntu $ ./Terrapin_Scanner_Linux_amd64 -listen 192.168.123.101:12345
At IPfire, run ssh client:
root@ipfire $ ssh -p 12345 192.168.123.101
And check console with Terrapin_Scanner
If you read my input i said that the fix would end up in CU183.
CU182 was already close to release when the fixed openssh package was released. Too late to be included.
2 Likes
This is incorrect. The same question was raised as an issue on the terrapin-scanner github site.
Strict key exchange support has nothing to do with the terrapin vulnerability.
If it was then I am sure Openssh would have said just change that parameter and everything is fixed.
Both the Vulnerability reporter and Openssh say that the only fix is to implement the changes that are in Openssh-9.6.
I suspect that the debian system you are testing is a bookworm system and debian has issued a security patch fix (1:9.2p1-2+deb12u2) that has the terrapin fix included in it so that is why that system shows up as not vulnerable.
4 Likes
I updated to IPfire version 184 and scanner from https://terrapin-attack.com/ reports that system is not vulnerable. I tested client and server, all is OK. It just took so long. There was an article at the beginning of Jan 2024, that more than 10 millions servers are still not patched. Attack details were published during Nov 2023. It is Mar 2023 and IPfire with patch was released. That was a slow process. I assume that there were no exploits to use terrapin vulnerability so there was no pressure to fix it ASAP.
The fix was already in CU183 which was released on Feb 13th.
4 Likes
OK, I did a mistake, I have not checked situation before update. And I missed that this vulnerability was already patched a month ago. I am sorry, I confirm that version 183 was already patched.
Anyway, the article from Jan 2024 has a link to online chart, status of this vulnerability and it seems like more than 8 mil servers are vulnerable today, no real progress from January…
Well all IPFire users also need to make sure that all ssh clients used on their LAN are also updated.
The problem exists if either the client or the server is using a vulnerable version.
1 Like
I am not confident that SSH service should be exposed to an attacker. even when patched.
How would you test a client though?
user@ubuntu $ ./Terrapin_Scanner_Linux_amd64 -listen 192.168.123.101:12345
At IPfire, run ssh client:
root@ipfire $ ssh -p 12345 192.168.123.101
And check console with Terrapin_Scanner
That test is for ssh client, you can run it from any PC you have, it is not limited to IPfire.
1 Like
root@ipfire $ ssh -p 12345 192.168.123.101
I ran this on a PC against a server,
Should I put the client IP and port 222 instead?
IP address 192.168.123.101 points to computer that runs Terrapin_Scanner with -listen option. TCP port (12345 in my example) is the port that was used in the scanner, so you can change it:
user@ubuntu $ ./Terrapin_Scanner_Linux_amd64 -listen 0.0.0.0:12345
I used host address 0.0.0.0 in this example, it is better, scanner will listen on any network interface, no need to specify IP address to bind…
This is what you will see when you connect with ssh client that was not fixed:
$ ./Terrapin_Scanner_Linux -listen 0.0.0.0:12345
Listening for incoming client connection on 0.0.0.0:12345
================================================================================
==================================== Report ====================================
================================================================================
Remote Banner: SSH-2.0-OpenSSH_9.5
ChaCha20-Poly1305 support: true
CBC-EtM support: false
Strict key exchange support: false
The scanned peer is VULNERABLE to Terrapin.
Note: This tool is provided as is, with no warranty whatsoever. It determines
the vulnerability of a peer by checking the supported algorithms and
support for strict key exchange. It may falsely claim a peer to be
vulnerable if the vendor supports countermeasures other than strict key
exchange.
For more details visit our website available at https://terrapin-attack.com
Testing ssh server is easier, you just try to connect to it with Terrpain_Scanner -connect host:port, if server port is 22, you do not need to specify it…
1 Like