SSH – Spoofing FIDO2 Tokens | Hacker News Reader

SSH – Spoofing FIDO2 Tokens

github.com

73 pointsstudent1000014 comments

I'm actually surprised the ssh protocol doesn't have MITM mitigation built in. Part of the original U2f Spec was that the TLS session State could be hashed and included as part of the client signature, effectively making MITM impossible. I don't believe this was widely implemented in practice however, although it seems like ssh would be a much better target to implement this behavior.

Either way, if the guy wants 500 starts to implement a security tool and advance security for the world, a gold star he gets.

That's not completely correct surprisingly. You can put SSH public keys into DNS records with the SSHFP type and use DNSSEC to have a complete trust chain rather than using TOFU. It's disabled by default in OpenSSH however, and I'd be pretty surprised if there was any large group of people making use of it presently.

https://en.wikipedia.org/wiki/SSHFP_record

described in

https://datatracker.ietf.org/doc/html/rfc4255#section-3

I found it amusing that all it changes is a single line in the TOFU output, adding "Matching host key fingerprint found in DNS." among all the other scary warnings.

I use this and came to the realisation that nobody has SSHFP records set up, even popular services like github which definately should have.

> I'm actually surprised the ssh protocol doesn't have MITM mitigation built in. Part of the original U2f Spec was that the TLS session State could be hashed and included as part of the client signature, effectively making MITM impossible.

When you use SSH public key authentication, a hash of the key exchange (called the "session identifier") is included in the client signature, much like the U2F channel binding you describe: https://datatracker.ietf.org/doc/html/rfc4252#section-7

This provides the same amount of protection as the U2F channel binding: namely, the MitM is unable to forward the signature to the server and successfully authenticate to the server as the client.

However, neither SSH nor U2F channel binding prevents the MitM from impersonating the server and hoping the client transmits something confidential. The SSH-MITM tool supports redirecting clients to a honeypot for this purpose.

Additionally, if the SSH client has agent forwarding enabled, the MitM can just ask the client to sign a new signature in order to authenticate to the server. The SSH-MITM tool also supports this.

Bottom line, no amount of channel binding in the authentication protocol is a substitute for correctly validating the server's identity, especially if you have SSH agent forwarding enabled.

Oh, the server fingerprint I have ignored literally tens of thousands of times in my life?

I don't turn it off, because I like the warning, but dhcp has made me completely blind to server keys.

You can search `known_hosts` for a fingerprint using `ssh-keygen -l -f ~/.ssh/known_hosts` and `grep`. If you disable `HashKnownHosts` in your ssh config, the command will also tell you the name of the host(s) for that fingerprint, rather than its hash.

I use this all the time, because my AWS/Azure/GCP ips change constantly, but their pubkey fingerprints do not.

[1] https://www.schneier.com/blog/archives/2005/05/the_potential...

If you connect by constant server name, dhcp shouldn't invalidate TOFU.

> Part of the original U2f Spec was that the TLS session State could be hashed and included as part of the client signature, effectively making MITM impossible.

This turns out to have the usual deployment hiccup, Middleboxes. In this case, at least, they've got some sort of consent, the user agent is agreeing to trust this middlebox which is not, in fact, the host it wanted to talk to. But it necessarily blows up export of session identifiers which was needed to make this U2F feature work.

The session between Alice and her BigCorp middlebox, and the session between the BigCorp middlebox and Bob's server are two different sessions (if you try to make it "one session" you don't have working middleboxes unless clients and servers only know TLS 1.2 or earlier), so, this shows up as MITM.

Which makes sense, the goal is to ensure MITM is impossible, these consensual Middleboxes are MITM, so it makes them impossible. But as a practical technology you can't deploy it because ordinary Joe User works at some company using such middleboxes and now their U2F sign-in doesn't work.

> I'm actually surprised the ssh protocol doesn't have MITM mitigation built in.

I don't understand, doesn't it? If the key for a host changes, it throws a scary warning. If you haven't connected to a host before, you're asked to trust the key. How does this utility manage to MITM exactly?

This utility can only perform MitMs if the client doesn't correctly verify the server's identity - e.g. if the user doesn't verify the fingerprint during the first connection, or they override the scary MitM warning. If the client correctly verifies the server's identity, then MitM is not possible.

exabrial is referring to a mitigation that works even if the client doesn't correctly verify the server's identity. SSH actually does have this mitigation, but it doesn't fully prevent nastiness, as I explain here: https://news.ycombinator.com/item?id=29259981

Ah okay, thank you. So this is a lot less scary than I initially thought.

Great work. Session hijacking is a huge problem for SSH, I hope this will bring more attention to it.

MITM malware can hijack most 2FA methods. There are well over 20 2FA common methods and the vast majority are susceptible to a MITM attack. But the most common attack is replay attacks and all 2FA methods thwart that. Some 2FA methods are trivial to hijack like SMS and others require more effort. Some are pointless to hijack if they are from a separate channel, session based and paired to a trusted pinned device like remote login 2FA.

Tangential: I found the documentation for this at https://docs.ssh-mitm.at/ to be good since it went into the underlying concepts and working in some detail. As someone who uses ssh with key based authentication but hasn’t learned this at a deeper level — neither ssh nor the configuration (security, usability, etc.) — what are some good tutorials and sources to follow (I think text with diagrams and/or videos would be helpful)?

Reply on news.ycombinator.com