Cybersecurity researchers from the Ruhr University Bochum, Germany, have discovered a way to crack OpenSSH connections and effectively break SSH channel integrity.
In an academic paper published earlier this week, researchers Fabian Bäumer, Marcus Brinkmann, and Jörg Schwenk, explained that since new encryption algorithms and mitigations were added to SSH, the SSH Binary Packet Protocol is no longer a secure channel.
The vulnerability, which they dubbed Terrapin, lets attackers manipulate messages that are exchanged through the communication channel. As a result, public key algorithms that are used to authenticate users are downgraded, and the protections against keystroke timing attacks are effectively disabled.
Meeting the conditions
“The Terrapin attack exploits weaknesses in the SSH transport layer protocol in combination with newer cryptographic algorithms and encryption modes introduced by OpenSSH over 10 years ago,” the researchers explained.
What’s more, they found an implementation flaw in AsyncSSH that, together with prefix truncation, allows an attacker to redirect the victim’s login into a shell controlled by the attacker. The flaws are now tracked as CVE-2023-48795, CVE-2023-46445, and CVE-2023-46446, BleepingComputer reported.
As is usual with academic research of vulnerabilities, certain conditions need to be met before the vulnerability can be pulled off: the attackers need to be in the adversary-in-the-middle (MiTM) position at the network layer, in order to grab the handshake exchange. Furthermore, the connection must be secured by either ChaCha20-Poly1305 or CBC with Encrypt-then-MAC.
But the researchers also claim that in the real world, these conditions are being met more often than not. Apparently, 77% of SSH servers support an exploitable encryption mode, with 57% even listing one as their preferred choice.
Vendors are now working on fixing the issue, it was later said. Among the possible solutions is a stricter key exchange which renders package injection during the handshake impossible. It will take some time before the problem is fully addressed, the researchers concluded, noting that the strict key exchange mitigation is only effected if it’s implemented on both the client and the server side.
