[HN Gopher] Terrapin Attack for prefix truncation in SSH
___________________________________________________________________
Terrapin Attack for prefix truncation in SSH
Author : colmmacc
Score : 74 points
Date : 2023-12-18 16:47 UTC (6 hours ago)
(HTM) web link (terrapin-attack.com)
(TXT) w3m dump (terrapin-attack.com)
| lambdafu wrote:
| It's prefix truncation, though.
| colmmacc wrote:
| Fixed!
| lambdafu wrote:
| Thanks! <3 Also for the kind words.
| colmmacc wrote:
| This paper is the best protocol security research I've seen in a
| while. Thankfully the consequences aren't too big - everyone
| should update ssh (which will be a pain!) - but it likely doesn't
| need to happen at breakneck pace. This issue isn't quite as
| serious as prior issues that impacted TLS/SSL.
|
| 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.
| tptacek wrote:
| Isn't this great? I can put myself "in the room" when they
| decided not to do a full transcript MAC. The SSL3 transcript
| hash is annoying! It was the first protocol I personally
| encountered that did that. And what are you trying to protect?
| A key exchange, right? Why not just create a mechanism that
| catches the inputs to the key exchange, authenticates them, and
| ignores everything else? Everything else is just a vehicle for
| communicating those inputs.
|
| 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?
| lambdafu wrote:
| ChaPoly was added in 2013, but the weird KEX is even older,
| dating back all the way to 1998 in SSHv2. And surprisingly,
| the attack only works with the "better" symmetric ciphers
| that do INT-CTXT instead of INT-PTXT.
| upofadown wrote:
| >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.
|
| [1] https://cseweb.ucsd.edu/~mihir/papers/enc-red.pdf
| tptacek wrote:
| The MDC thing has nothing to do with you. It's a perennial
| complaint among cryptographers about how PGP's design has
| escaped modernity. It's weird that you think HN is somehow
| the center of that phenomenon.
| tptacek wrote:
| This is wonderful.
|
| 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.
| xoa wrote:
| Super, super interesting. What a cool bit of research, and as
| you said in your other comment also a interesting bit of living
| history as well.
|
| 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.
| petecooper wrote:
| >I am an admin, should I drop everything and fix this?
|
| >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.
| justinclift wrote:
| Seems like it'll be a case of "wait for updated ssh packages",
| potentially with some mitigation advice appearing in the next
| day or so.
| gorkish wrote:
| > I am an admin, and it's not clear _how_ I might fix this at
| the server end.
|
| 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.
| Skrillor wrote:
| We updated the FAQ question to cover this. For most users,
| fixing can be done by installing patched versions of their SSH
| implementations as they come available. If you feel
| uncomfortable waiting for an update, you may disable the
| affected cipher modes temporarily and use other modes like AES-
| GCM instead. But keep in mind that a faulty configuration can
| cause you to loose access to the server.
| colmmacc wrote:
| Fwiw, I found a bunch of clients and libraries that didn't
| support AES-GCM at all, or only very recently. libssh2 is one
| example. That's made me nervous to make AES-GCM the only
| supported cipher as a mitigation.
| Aloisius wrote:
| What about aes-ctr?
| lambdafu wrote:
| Depends a bit on the MAC. CTR-EtM is technically
| vulnerable (i.e. cryptographically broken), but due to
| key stream desynchronization the attack will quickly lead
| to application errors, defeating the attacker. See Sect.
| 4.3.3.
| rastignack wrote:
| Is disallowing IGNORE messages during handshake a good enough fix
| for this ?
| lambdafu wrote:
| No, because there may be other messages that are ignored, i.e.
| don't trigger a response message. Any such message can be used
| for injection. The details are implementation specific, though.
| The new strict-kex disallows all unexpected messages during the
| initial handshake, which helps a lot. (Even better would be to
| authenticate the complete handshake transcript). Another
| mitigation is resetting the sequence number. Both together give
| some redundancy.
| motohagiography wrote:
| Short version of the net threat/risk of this appears to be a
| sophsticated attacker on the network may snipe ssh session
| negotiations with injected packets and cause the session to not-
| apply mitigations against keystroke timing analysis - which in
| turn may expose an ssh authN password via implementing that
| timing attack, or sudo credentials on the other side of the
| connection.
|
| 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.
| Skrillor wrote:
| Actually, you cannot perform keystroke timing attacks on the
| password sent during SSH user authentication. This is because
| SSH transmits the password in its entirety, not the individual
| keystrokes as it does during a shell session.
|
| 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.
| notherhack wrote:
| Netgate is providing a pfsense patch that disables ETM MACs but
| leaves chacha20 enabled. The vuln announcement is arguably vague
| because of the way is uses "and" and "or" but from the vuln
| scanner source chacha20 is clearly not okay even without ETM.
| https://forum.netgate.com/topic/184941/terrapin-ssh-attack
|
| Shame they won't let me post a reply to let them know.
___________________________________________________________________
(page generated 2023-12-18 23:00 UTC)