[HN Gopher] SSH - Spoofing FIDO2 Tokens
       ___________________________________________________________________
        
       SSH - Spoofing FIDO2 Tokens
        
       Author : student10000
       Score  : 48 points
       Date   : 2021-11-17 18:08 UTC (4 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | exabrial wrote:
       | 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.
        
         | RL_Quine wrote:
         | 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.
        
         | agwa wrote:
         | > 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:
         | https://datatracker.ietf.org/doc/html/rfc4252#section-7
         | 
         | This provides the same amount of protection as the U2F channel
         | binding that you describe: 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 happens to have agent
         | forwarding configured, 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.
        
         | tialaramex wrote:
         | > 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.
        
       | staticassertion wrote:
       | Great work. Session hijacking is a huge problem for SSH, I hope
       | this will bring more attention to it.
        
       | 1cvmask wrote:
       | 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.
        
       ___________________________________________________________________
       (page generated 2021-11-17 23:01 UTC)