Novel Terrapin attack uses prefix truncation to downgrade the security of SSH channels:
Sometime around the start of 1995, an unknown person planted a password sniffer on the network backbone of Finland's Helsinki University of Technology (now known as Aalto University). Once in place, this piece of dedicated hardware surreptitiously inhaled thousands of user names and passwords before it was finally discovered. Some of the credentials belonged to employees of a company run by Tatu Ylönen, who was also a database researcher at the university.
The event proved to be seminal, not just for Ylönen's company but for the entire world. Until that point, people like Ylönen connected to networks using tools which implemented protocols such as Telnet, rlogin, rcp, and rsh. All of these transmitted passwords (and all other data) as plaintext, providing an endless stream of valuable information to sniffers. Ylönen, who at the time knew little about implementing strong cryptography in code, set out to develop the Secure Shell Protocol (SSH) in early 1995, about three months after the discovery of the password sniffer.
[...] Ylönen submitted SSH to the Internet Engineering Taskforce in 1996, and it quickly became an almost ubiquitous tool for remotely connecting computers. Today, it's hard to overstate the importance of the protocol, which underpins the security of apps used inside millions of organizations, including cloud environments crucial to Google, Amazon, Facebook, and other large companies.
[...] Now, nearly 30 years later, researchers have devised an attack with the potential to undermine, if not cripple, cryptographic SSH protections that the networking world takes for granted.
Named Terrapin, the new hack works only when an attacker has an active adversary-in-the middle position on the connection between the admins and the network they remotely connect to. Also known as a man-in-the-middle or MitM attack, this occurs when an attacker secretly positioned between two parties intercepts communications and assumes the identity of both the recipient and the sender. This provides the ability to both intercept and to alter communications. While this position can be difficult for an attacker to achieve, it's one of the scenarios from which SSH was thought to have immunity.
For Terrapin to be viable, the connection it interferes with also must be secured by either "ChaCha20-Poly1305" or "CBC with Encrypt-then-MAC," both of which are cipher modes added to the SSH protocol (in 2013 and 2012, respectively). A scan performed by the researchers found that 77 percent of SSH servers exposed to the Internet support at least one of the vulnerable encryption modes, while 57 percent of them list a vulnerable encryption mode as the preferred choice.
At its core, Terrapin works by altering or corrupting information transmitted in the SSH data stream during the handshake—the earliest stage of a connection, when the two parties negotiate the encryption parameters they will use to establish a secure connection. The attack targets the BPP, short for Binary Packet Protocol, which is designed to ensure that adversaries with an active position can't add or drop messages exchanged during the handshake. Terrapin relies on prefix truncation, a class of attack that removes specific messages at the very beginning of a data stream.
[...] The researchers note that they aren't the first people to describe a prefix truncation attack on a network protocol by manipulating sequence numbers. In 2015, researcher Cédric Fournet envisioned a similar attack on a draft of the upcoming version 1.3 of TLS. Fournet's technique increased sequence numbers by fragmenting messages rather than injecting them as Terrapin does. (Terrapin injects an IGNORE message to asymmetrically increase the sequence number on one side of the communication.) Fournet's attack was deemed theoretical because the manipulation in this case was likely to cause TLS handshakes to fail. The possibility of a successful exploit nonetheless prompted engineers to follow Fournet's advice to revert back to 1.2's practice of resetting record-layer sequence numbers to 0 whenever new keys were installed.
In response to recommendations provided by the researchers ahead of the publication of Monday's paper, the developers of SSH software, including the nearly ubiquitous OpenSSH, have updated their implementations to support an optional strict key exchange. It provides for sequence number resets and also prevents an attacker's capability to inject packets during the initial unencrypted handshake. For the fix to take effect, both client and server must support this backward-compatible change.
[...] People who want to know if the SSH client or server they use is vulnerable to Terrapin can use a custom scanner developed by the researchers. It connects to a server or monitors the incoming client connection to determine whether one of the vulnerable encryption modes is available and if the countermeasure requiring a strict key exchange is supported. The scanner doesn't perform a full-fledged handshake or carry out the attack.
[...] While the risk Terrapin poses varies, it invalidates proofs published in 2016 that concluded such attacks weren't possible. The real lesson is that practical evaluations, like the one provided in Monday's research, are crucial for revealing previously overlooked flaws in such proofs.
"In any case, proofs need to be updated over time to reflect changes and extensions to the protocol," the researchers wrote. "Although we suggest backward-compatible countermeasures to stop our attacks, we note that the security of the SSH protocol would benefit from a redesign from scratch, guided by all findings and insights from both practical and theoretical security analysis, in a similar manner as was done for TLS 1.3."
Also see: SSH shaken, not stirred by Terrapin vulnerability.
The researcher's web site and the paper describing the attack [PDF].
(Score: 5, Interesting) by Anonymous Coward on Sunday December 24, @02:29AM (5 children)
Saying "SSH ... Just Got a Lot Weaker" seems completely out to lunch at this point.
The openssh 9.6 release notes [mindrot.org] have a much less sensationalist take:
(Score: 4, Insightful) by RamiK on Sunday December 24, @03:33AM (1 child)
If I'm reading it right, the severity has to do with the need to modify the protocol and the implementations (possibly not in a backwards compatible way) to address the issue.
compiling...
(Score: 2) by driverless on Monday December 25, @06:53AM
There's no need to modify the protocol, it only affects a bunch of homebrew crypto mechanisms the OpenSSH guys invented. If you never supported them, you're not vulnerable. Even if you did, the most you can do is mess around with a few SSH extension messages, which again many implementations don't support. And even if you do, it's not clear whether any of them are actually security-relevant. In essentially all cases except AsyncSSH, which has some implementation bugs around this, there's not really any need to do anything.
(Score: 4, Insightful) by krokodilerian on Sunday December 24, @05:54AM (2 children)
I completely agree.
A lot of people tend to overhype this kind of stuff, or propose idiotic security measures. To all the standard answer should be "what is your threat model? who is attacking you, how, why?".
If you're in a case where you're protecting from MITM, you're already a target of someone sophisticated. Doing MITM means having a lot of resources and access, and knowledge how not to be trivially detected. If you're targeted by such people, you either have few more layers of security, or you're screwed (well, you might be screwed anyway). SSH would be the least of your worries, you would be more worried about the myriad vulnerabilities in Android/iOS devices connected to the same network, in the different large pieces of software you run, etc., which present a lot softer target that can provide local access to something, that can then be escalated to root.
(or, they can just find you and kick the shit out of you. obligatory xkcd https://xkcd.com/538/ [xkcd.com] )
And if you're not in the above category, this completely doesn't matter, as nobody cares to spend that many resources to attack you and this attack is never going to happen to you.
(Score: 2, Disagree) by Anonymous Coward on Sunday December 24, @07:02AM (1 child)
(Score: 3, Insightful) by krokodilerian on Sunday December 24, @07:49AM
MITM is active change of packets, passive eavesdropping is a lot easier and common (and harder to detect). Random people can do that on wifi, for example.