Primer on the new 2023 SSH Terrapin attack

[robi]

http://pijul.org/posts/2023-12-18-thrussh-cve/

Tl-dr.

Along with other authors of SSH implementations, I was warned a few weeks ago by Fabian Bäumer, Marcus Brinkmann and Jörg Schwenk, three security researchers at Ruhr University Bochum, that the SSH protocol had a flaw by which an attacker could, in some cases and with some specific algorithms, manipulate the identifier of packets in an SSH channel and break channel integrity. This is called the Terrapin Attack.

The SSH protocol for dummies

The current flaw is an interesting one, as it touches some of the core concepts of the SSH protocol and allows to explain its main ideas quite naturally.

The most important thing to understand is that a nice thing we generally want to build over a network is the illusion that there is a direct “pipe” between two computers, even though the network is a complex interconnected mesh. The first way to build a pipe is TCP, the transmission control protocol. TCP splits a stream of bytes into packets and numbers them. The computer on the receiving end confirms the received packet to the sender, allowing the sender to retransmit any missing packet.

Like everything else, the correctness depends on our model of the network and its participants: is anyone interested in listening to the messages? in modifying them? do they have quantum computers? or maybe 5$ wrenches?

With that in mind, SSH is actually not much more than a stronger pipe than TCP: it works on top of TCP and extends it with protections against some threats like eavesdroppers and people trying to manipulate the message.

The way the SSH protocol itself works is actually surprisingly simple: after an initial plain-text handshake made of a single line, the stream is split into packets (which do not necessarily match TCP packets). Packets are just a series of bytes, plus a packet type, number and a length, just like in TCP, except there are more possible packet types. Some of these types are related to cryptography, while others indicate specific things related to the most common use of the protocol: remote-controlling computers. For example, “start a shell command” is one type.

See top link for more..

[Kubernetes]

For server side there are fixes available already. Important is to understand that also the ssh client needs to be fixed!

I used the Terrapin Scanner to check my environment: https://github.com/RUB-NDS/Terrapin-Scanner

[scooke]

@Kubernetes I read some of this... just to be clear, this is supposed to be run ON the server in question, correct? Not on my latop, replacing localhost with the VPS IP?

[Kubernetes]

@scooke Yes, you run it on the server. With localhost you can check the vulnerability of your ssh server. With the --listen (?) parameter you can setup a one time connect session to check your ssh client for vulnerability. The latter you could also run locally on your laptop.

From Usage Guide:
Scan the SSH server available at localhost port 2222
./Terrapin-Scanner --connect localhost:2222

If no port is specified, the tool will default to port 22 instead
./Terrapin-Scanner --connect localhost

To scan an SSH client, specify the listen command instead
After running the command, you will need to connect with your SSH client to port 2222
./Terrapin-Scanner --listen 0.0.0.0:2222

When binding to localhost, you can omit the interface address
The following command will listen for incoming connections on 127.0.0.1:2222
./Terrapin-Scanner --listen 2222

[robi]

It may be easier to check versions of clients and servers for a list of known patched versions. ie what version of putty/kitty passes?

OS updates likely already have the fix for the server and client there.

[Kubernetes]

You may trust lists, but you may trust more a test you did yourself - assumed the tool to test is working right

I don't know which versions of Putty/Kitty passes, on my Mac the ssh client of Macos Sonoma 14.2.1 is still vulnerable. I installed openssh ssh client via brew - the test showed that this version is not vulnerable

[robi]

@Kubernetes Point is, not everyone has the ability test everything. Some should. We can't be too lazy and assume either.

Good feedback on desktop OSs, since they don't have the same level of updates as Linux distros for security updates.

MacOS should not require an OS upgrade to do this, yet that is their model.