Why are FIDO2 protected SSH keys affected by phishing attacks?

Question

The OpenSSH developers have written in a description of the "agent restrictions" feature that FIDO2 tokens are vulnerable to phishing attacks: https://www.openssh.com/agent-restrict.html

FIDO keys that require user-presence confirmation offer a little more defence, but are also similarly phishable.

However, on the FIDO Alliance page it is written that FIDO2 tokens protect against phishing attacks: https://fidoalliance.org/fido2/

This security model eliminates the risks of phishing, all forms of password theft and replay attacks.

Questions:

• Why are FIDO2 protected SSH keys affected by phishing attacks?
• Is it already known how the phishing attack mentioned by OpenSSH is supposed to work?
• Why is this not also true for SSH or why has SSH been vulnerable to phishing attacks so far?

Answer 1

Introduction

Webauthn vs ssh authentication protocol

OpenSSH's implementation is not related with webauthn. Those are different protocols. In OpenSSH the FIDO/FIDO2 token is used to allow the usage of the private key. This does not change the ssh's authentication protocol.

Webauthn works different. It's a complete new authentication protocol, which does not have any similarities with the ssh authentication protocol. The browser can verify the website and communicates with the FIDO2 token (trusted party). The website (Domain/URL) and some channel id's are part of the authentication process. Those information can not be faked. This is the reason, why it's not possible to authenticate against a phishing site and reuse the credentials.

Using FIDO2 with webauthn is secure and protects against phishing attacks.

SSH and phishing attacks

SSH should not be affected by phishing attacks, if you verify the fingerprint or compare it against a trusted source. The reason why such phishing attacks work is, that most users does not verify the fingerprint during the first connection.

When the fingerprint is already known, but the host key changes, a warning is presented and the connection is closed. This should prevent from attacks like ARP Spoofing.

In the scenario of "agent restrictions" we are not talking about such phishing attacks. They might be part of the attack but not the attack which was meant by the Damien Miller (OpenSSH dev).

"no-touch-required" option for FIDO tokens

FIDO tokens are supported since OpenSSH 8.2. Compatible FIDO/FIDO2 tokens must support U2F and they must support "ECDSA-P256" and "Ed25519". There are some optional features like "no-touch-required" and "resident keys".

When "no-touch-required" is used, they private key can be used without confirmation and such keys can be abused at any time. The "no-touch-required" is not discussed in the article, because it disables the second factor and a phishing attack is not required.

The phishing attack

The phishing attack is called "trivial authentication" and was first described in Bug 3316 in the OpenSSH issue tracker.

Simon Tatham (PuTTY) and Matt Johnston (Dropbear) has also improved existing mitigation strategies or implemented some mitigation strategies against the described phishing attack.

Scenario

The user wants to connect to a development server with public key authentication and agent forwarding enabled, which is needed, because the user needs to access an internal git repo over ssh.

The server got compromised and the attacker has access to the forwarded agent.

This is the same scenario as by the Matrix server hack in 2019.

Another scenario is remote copy of files. New implementations of openssh (>8.4) supports agent forwarding in scp and sftp, which makes this attack also possible.

Normal behavior

When the user connects to a dev server with public key authentication, the user have to push the button on the fido device.

The attacker got access to the forwarded agent and uses this agent to get access to another server. This does not work, because the user needs to push the button an the fido 2 device.

This is not expected and the user will close the session an inform the administrator of the compromised server.

Bypass of fido 2 devices and ssh-askpass

If the attacker configures the ssh server, so it does not need credentials to login, an attacker can bypass the first confirmation for the fido device or ssh-askpass.

This can be done, by using the authentication method "none".

If the client connects to the compromised server, the server accepts the connection and requests the agent.

After the attacker got the agent, the attacker can try to login to a different server, which will need a confirmation on the fido device.

The user thinks, that this confirmation is for the development server, because he does not know, that he is already connected. After the confirmation, the attacker is logged in to the other server.

Note on the the scenario

The described scenario the most basic scenario and has a lot of drawbacks. "none" authentication is the most obvious authentication method, because it is always present on the client side and allows a login without authentication, which is required for the phishing attack.

Advanced attacks should choose other authentication methods or flaws in the client's authentication process. For example "keyboard-interactive" also allows logging in without passwords.

Disclosure: I found this phishing attack during an audit and developed the improvements/fixes for PuTTY and Dropbear. The documentation about trivial authentication is for my tool "SSH-MITM", which is a man in the middle audit tool for ssh.

Answer 2

These are different contexts.

When you're using a FIDO2 token as part of a WebAuthn request, your browser, a trusted party, sends the actual website you're visiting, in addition to the data you're receiving from the website, to your token. Your token generates a response based on that data. In this context, phishing is not possible because the remote party (the domain) is attested to by a trusted party (the browser), and the response is cryptographically dependent on that data.

In the context of an SSH agent being forwarded to a remote machine, we cannot know if the ultimate system is actually who they say they are. The only trusted party here is our local machine, and if we've connected to A, forwarding our agent, and then attempt from there to connect to B, we cannot necessarily trust A or B to be honest about further connections. There is no trusted party to attest to the remote system's identity.

However, with the new SSH protocol extension, the data that's involved in the request for the signature now includes the server's host key. Because we can generally assume that only the server in question has access to their host key, the signature is cryptographically bound to the destination system, and thus phishing and forgery are not possible if the server only accepts valid signatures.

Thus, the ultimate determinant as to whether a FIDO2 key (or, for that matter, any cryptographic material) is subject to phishing is essentially whether the specific request is bound cryptographically to the remote system in such a way that it cannot be tampered with, forged, or replayed by a proxying system (the party doing the phishing).

Answer 3

You are comparing apples and oranges.

FIDO2 defends against the phishing of credentials. I can set up a fake website and capture credentials, but I would still need to get the TOTP seed to be able to use those credentials on the real site.

But with the OpenSSH article, they are talking about proxying the authentication. Once you forward the agent to an attacker, as it explains, the control goes to the attacker. And it also means that the user's interaction with the FIDO key goes through to the attacker. Once the attacker gets this result, then they can log in to the target. Hence the addition of the indication to the user that the agent has been forwarded.

MFA for websites has this vulnerability, too. If an attacker can insert themselves, they can capture TOTP codes and use them on behalf of the user.

Please remember that "phishing" can mean a lot of different things and the context really matters. You can't read "eliminates the risks of phishing" and assume that it applies in all contexts all the time in perpetuity. Context matters. The FIDO page explains its context. You can't carry that context over to a completely different problem.