Terrapin Attack for prefix truncation in SSH
terrapin-attack.com
terrapin-attack.com
Secure transport protocols all do some kind of handshake to set up a session, agree on keys, etc. Modern secure transport protocols (everything since SSL2) authenticate the handshake, so a MITM can't just edit the messages and, like, stick both sides on the NULL cipher (don't have a NULL cipher, though).
Ever since Kocher and SSL 3.0, the gold standard for handshake authentication has been to keep a transcript of all the handshake messages, and just hash them to fingerprint the entire handshake. You can look at Noise for a streamlined, slick version of the same concept.
SSH does something else: it looks at the handshake as a vehicle for setting up a DH-style key exchange; that's all it's for, everything else happens inside the secure transport that key exchange provides. So instead of doing a transcript hash, SSH picks out the handshake values that will end up being inputs to the key exchange, and hashes those.
The problem is: SSH also does implicit sequence numbers; receivers keep track of how many messages they've received, senders keep track of how many they've sent. Not only that, but SSH has (for reasons passing understanding) a NOP message (`IGNORE`). `IGNORE` carries no data used to do key generation, so it has no impact on the handshake authentication --- but it does impact sequence numbers.
Result: MITM attackers can set sequence numbers to arbitrary values (by injecting `IGNORE`s in the handshake), and then edit out subsequent messages (by just not sending them). If you're using ChaPoly (and often if you're using CBC), the protocol will sync up and keep going. You can use this to, for instance, snipe out extension messages (for things like keystroke timing mitigation) from the beginning of an SSH session.
This is a pretty obvious problem! It's absolutely not something you can just accept from a secure transport protocol. And you could look at SSH and SSL3 and see "SSH is doing something really different and less sophisticated than SSL3". But it took until 2023 for someone to do the legwork to figure out how broken it was.
As far as mitigations and Noise, I've been tunneling all my SSH connections through WireGuard or Nebula anyway primarily just because they're such easy reliable ways to reach hosts behind NAT with in secure fashion, and while there is certainly overhead in putting SSH through something else all the tunnels are fat and fast enough that for just console control it's been fine, haven't had to use mosh (does mosh have the same issue?). Even through Starlink it's never a problem. But one does wonder a bit anyway with all the really old protocols at this point, just feels like there have been a lot of fundamental shifts in thinking around security (simplicity of implementations, not having lots of buttons and switches and flexibility, etc) such that there are less likely to be hidden bugbears now. There is more scrutiny not just day 1 but in the whole process of design.
Not that SSH isn't still important to fix but I wonder if just tunneling everything is a decent default at this point. I use internal VPNs for everything management related but not air gapped at this point, not just external. Maybe that's overkill or foolish doubling up? But it's convenient, performant, and bypasses a lot of complexity in other layers.
It took until 2023 for somebody to publicly disclose the problem.
The first fix for it was described in RFC 5647, which was published in August 2009 (first draft was submitted in June 27, 2008).
Two things stand out to me;
1. That the SSH protocol lacked a robust transcript hash all along, this seems like a staggering decision, and even though I'd read the RFCs, I'd never put this together. Turns out it's to allow for injection of messages designed to defeat traffic analysis? Not the right way to do it.
2. The SSH handshake had been formally verified ... and the proofs are still "true". But the researchers found non-obvious gaps between the environmental assumptions for the proofs and what is actually true in the real world. Formal verification is still the most comprehensive and exhaustive form of testing that we have, but gaps can really bite you. It is like relying Pythagoras' theorem for a triangle, but then it turns out that your triangles are on the surface of a sphere, which isn't a plane. The math itself is right, but the environment was different all along.
So like, you could imagine yourself looking at the SSL 3.0 "Finished" message and the SSH "Exchange Hash" and asking yourself, why do the complicated thing? The SSH thing seems to work!
And: if you asked yourself that, like, in 2013, you could go on believing for ten years that everything was fine, and SSH just found a clever way to do handshake integrity less cumbersomely than SSL 3.0.
There's like an obvious lesson here about PGP and the MDC, right?
Not sure that all the readers will already know about our constant quibbling about the security of the MDC. I have in the past suggested that the fact that the MDC has remained unbroken for 20+ years is evidence that it is secure.
Interestingly enough, I have recently stumbled across a paper[1] that shows that preventing an attacker from computing the hash is important for insuring the security of hash than encrypt schemes like the MDC. OpenPGP does that by preseeding the hash with a random, encrypted value.
So does that mean that the MDC is secure? Unfortunately, when you come up with a set of requirements for security, you have to use your knowledge of existing attacks. You don't get to know about about future attacks. So the fact that a particular construct has never been broken over a long time is in a sense the only objective evidence available.
OpenPGP gets a fair amount of academic scrutiny. What is going to change that would allow someone to find a weakness in OCFB-MDC at this late date?
Also, why do you care so much that you bring it up out of nowhere in unrelated contexts?
I don't understand your second question.
This seems like... not a great stance to take on post about a vulnerability that existed for 20+ years.
I don't understand the defensiveness.
This seems unsurprising for me. Formal verification advocates believe it will prevent all issues, but it seemed obvious to me that the verification is still vulnerable to human fallibility in deciding _what_ to verify.
https://ntrs.nasa.gov/api/citations/20000055731/downloads/20...
Uh, if it was that easy. I recently(!) audited a brand new system for deployment in what most nations consider critical infrastructure. They had just updated to the newest firmware supplied by a well-known and established manufacturer in that industry (not some garbage by a small company). That ran a dropbear ssh server version from 2016 with multiple CVEs, including an unauthenticated RCE. So essentially it's a root shell for anyone that can talk IP to that device.
I predict I will start seeing this terrapin in my Nessus reports soon, and stop seeing it when I enter pension.
Strictly speaking audit is the wrong word for what I did (I'm not a certified auditor). I don't want to say too much in case I break some confidentiality agreement. Though I'm curious how that will be argued away, or if they get the manufacturer to get their shit together and build a new firmware...
I'm interpreting the likelihood of encountering this near term seems very low, and the impact is high enough where an APT group uses it as part of their pivot and persistence strategy, but it's mitigated by the fact that it doesn't compromise a clients private key. There may be some future implementation of this attack that enables automated ssh session hijacking as a result of a key downgrade and an additional cryptographic weakness in that chosen weaker cipher. It implies the network IoCs would be for a bunch of NOP ssh packets and failed ssh session setups.
Interested in disagreement.
The possible downgrade is usually limited to downgrading SHA2 to SHA1 when using RSA keys for user authentication. We are currently not aware of any attacks that benefit from this.
server-sig-algs was only added for compatibility, so new clients wouldn't get kicked off old servers that don't accept rsa-sha2 pubkey auth packets. https://www.rfc-editor.org/rfc/rfc8308#page-7
AFAIK this downgrade is not possible for OpenSSH, as it refuses RSA/SHA1 signatures by default at both the client and server. Moreover, deleting the EXT_INFO message would only remove the _advertisement_ that these messages are accepted and would change the fact of whether they are.
It might be possible to use this attack to trick an old client to making a RSA/SHA1 signature where it might mormally have made an RSA/SHA2 one, but I can't see any security impact from this as the signed data is still bound to the connection instance and it wouldn't change whether the peer would accept it anyway.
https://forum.netgate.com/topic/184941/terrapin-ssh-attack
Nothing's really changed today. The workarounds have become smoother and some of the things we can do with networks of Unix machines are pretty impressive, but when ssh is the foundation of your security architecture, you know things aren't working as they should.
https://slashdot.org/story/04/10/18/1153211/rob-pike-respond...
> 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.
https://www.chiark.greenend.org.uk/~sgtatham/putty/changes.h...
I wanted to share some insights into a security concern that echoes the Terrapin-Attack scenario, highlighting a similar vulnerability that has been observed in other tools.
Recently, I came across a Pull Request on GitHub for the SSH-MITM tool, which sheds light on a critical aspect of SSH protocol security, specifically regarding RFC 4253 during the KEXINIT process. The Pull Request, available at GitHub https://github.com/ssh-mitm/ssh-mitm/pull/163, describes the necessity of discarding certain packages during the KEXINIT phase to prevent issues with intercepted clients.
Moreover, a look into the GitHub Blame for SSH-MITM reveals that these crucial changes in the KEXINIT step were integrated into SSH-MITM about 1-2 years ago. You can see the specific changes at this link: https://github.com/ssh-mitm/ssh-mitm/blame/4fc3ef418847c35d1...
An important note to add is that this information suggests that a similar form of attack, akin to the Terrapin-Attack, could potentially have been exploited for the last two years. This raises significant concerns about the historical vulnerability of systems to such attack techniques and emphasizes the importance of retroactive security analysis in addition to ongoing vigilance.
>Probably not.
(I will preface this by saying I'm likely missing something obvious.)
I am an admin, and it's not clear _how_ I might fix this at the server end.
Edit: thanks for the replies, I'll sit tight for now.
For packages, openssh and openssh-portable 9.6 include the fix, but every vendor will need to backport if they maintain their own pile of patches against a particular version of -portable.
You're just hearing about this early as it's the first hours of public disclosure. There are 3 CVE's assigned. You'll track those with your vendors or upstream and patch as fixes become available, which they already should be for at least some implementations that had earlier disclosure. The main issue is CVE-2023-48795. It does not appear there is any immediate need to implement compensating controls or workarounds at this time, but that assessment really depends on your own environment, security policy, and risk tolerance.
This is not helpful for currently vulnerable setups but hopefully will be a good reminder to think about defense in depth :)
The probability of an attacker targeting you having an exploit for both at the same time will be lower that having an exploit for either.
It's not defense-in-depth; it's a security chain : only as strong as its weakest link.