A weakness in the SSH protocol was discovered by a group of researchers (Fabian Bäumer, Marcus Brinkmann, and Jörg Schwenk) that can allow manipulation of some ssh packets. The vulnerability has been dubbed ‘Terrapin’, and details can be found in their post HERE
Affected versions of AbsoluteTelnet/SSH: 11.42 and earlier
Fixed in version: 12.11 and later.
Affected versions of OpenSSH: Earlier than 9.6
CVE: CVE-2023-48795
Mitigation of the vulnerability requires implementation of a new SSH feature “Strict Key Exchange”, also known as “Strict KEX”. Full resolution requires that the server and client BOTH implement strict key exchange! OpenSSH, for example has implemented Strict KEX in version 9.6, though I have noticed some distributions have backported this feature to earlier versions. Specifically, Amazon Linux 2023. For visibility, AbsoluteTelnet/SSH has added the message “Strict KEX : Enabled” to the login blurb when both client and server have declared support. When this is displayed, the Terrapin attack is fully mitigated and no further changes to the SSH session are necessary. In the absence of server support, AbsoluteTelnet/SSH will display: “Strict KEX: Not detected on server” and will lead you to this page.
For older servers that may not yet support Strict KEX, the Terrapin vulnerability can still be fully mitigated by careful selection of encryption and MAC algorithms. Only certain algorithms and combinations of algorithms are vulnerable when Strict KEX is not available. For example, ETM MACs (available since Absolute 11.41) in conjunction with CBC mode encryptions are theoretically possible to exploit, though non-trivial in practice. Algorithms are negotiated at the start of the connection, so availability and preference of algorithms on either end can potentially result in a vulnerable combination being selected. AbsoluteTelnet/SSH 12.11 and above will warn you when this happens and give you recommendations on what to do, including:
- Disable vulnerable algorithms and try again (automatic)
- Disconnect, I’ll fix this myself (manual)
- Continue (not recommended)
With or without server support, AbsoluteTelnet/SSH 12.11 and above will NOT enter into an exploitable connection without the user knowing their options.
Vulnerable and Exploitable:
ChaCha20 – Poly1305 (which AbsoluteTelnet/SSH does not implement, and so is not vulnerable)
Vulnerable, and probabilistically exploitable:
Use of CBC mode encryptions with ETM MAC algorithms
Vulnerable, but not exploitable:
Use of CTR mode encryptions with ETM MAC algorithms… Attempts at manipulation will cause immediate failure of the stream.