Terrapin Attack for prefix truncation in SSH

Re:Terrapin Attack for prefix truncation in SSH by motohagiography on Monday December 18, 2023 @03:52PM (#38688079)

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.

[ Parent | on HN ]

Re:Terrapin Attack for prefix truncation in SSH by Skrillor on Monday December 18, 2023 @05:16PM (#38689158)

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.

[ Parent | on HN ]

Re:Terrapin Attack for prefix truncation in SSH by mkj on Monday December 18, 2023 @10:15PM (#38691361)

I don't think dropping the server-sig-algs packet gives any additional downgrade capability? If a server is going to accept a rsa sha1 signature it will accept it regardless of whether the client receives the server-sig-algs or not. Performing a rsa sha1 signature doesn't cause any exposure for a client (that I know of?).

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

[ Parent | on HN ]

Re:Terrapin Attack for prefix truncation in SSH by djmdjm on Monday December 18, 2023 @11:41PM (#38691908)

> The possible downgrade is usually limited to downgrading SHA2 to SHA1 when using RSA keys for user authentication

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.

[ Parent | on HN ]