I have done some research on the behavior of the second factor authentication (fido2) and ssh-askpass. Those methods can be used to confirm, when a private key is used by the agent. By using the authentication method "none", which allows a client to login without credentials an attacker can bypass one of two required confirmations during a mitm attack. Why is the ssh client and not the agent, fido 2 key or ssh-askpass affected? ---------------------------------------------------------------------------- When "none" authentication is used, the client does not need the agent to sign the data. This is the reason, why the user does not need to confirm the login with the fido 2 key or ssh-askpass. Scenario -------- I want to connect to a development server with public key authentication and agent forwarding enabled, which is needed, if I want to access an internal git repo or another server from this machine. 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. I want to connect to a remote machine with scp or sftp to copy one file to another server. New implementations of openssh (>8.4) supports agent forwarding in scp and sftp, which makes this attack also possible. Normal behavior ----------------- When I connect to the dev server with public key authentication, I have to push the button on my fido 2 device. The attacker got access to my forwarded agent and uses this agent to get access to another server. This does not work, because I need to push the button an my fido 2 device. This is not expected and I will close the session an inform my administrator of a compromised server. Bypass of fido 2 devices and ssh-askpass ---------------------------------------- If you configure your ssh server, so it does not need credentials to login (none authentication), an attacker can bypass the first confirmation for the fido 2 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 2 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. Suggestion mitigation --------------------- The main problem is the none authentication. If the server does not allow none authentication, this bypass is not possible. Removing the "none" authentication from the openssh server does not mitigate this bypass, because an attacker can use another server or patch it to the old behavior. The client can warn, if "none" authentication was successful are close the connection, in a more restrict mode. Perhaps an optional parameter "e.g. --disable-none" can be added. Default value is the old behavior, where "none" authentication is allowed. When the user wants to disable "none" authentication, he can use the new parameter. Note: We are talking about high security use cases where agent forwarding is needed. If you don't use a fido 2 key, a mitm attack becomes far easier and does not require such a bypass. Of course, one can argue, that agent forwarding is a bad practice, but there are still some use cases. For example pulling a repo on a dev machine from a git server.
First, the root cause is forwarding an agent to an attacker-controlled destination - the user is effectively delegating use of their keys to that attacker. Second this is not an authentication bypass, since nothing is being bypassed. The user is becoming confused as to the context of a FIDO touch request. That makes this more like phishing than anything else. This attack may be mitigated by setting LogLevel=verbose so ssh(1) will print a message at the conclusion of authentication: > [djm@origin ~]$ ssh -oLogLevel=verbose host > Authenticated to host.example.com ([10.0.0.1]:22). > $ Fundamentally, forwarding an agent is a risky operation and should be avoided where possible. This is why we implemented ProxyJump :)
OpenSSH 8.9 added "agent restrictions", which should prevent such attacks. Thanks for implementing the new feature :-D I think this issue ticket can be closed.
* Information about "agent restriction": https://www.openssh.com/agent-restrict.html * Full disclosure: https://docs.ssh-mitm.at/trivialauth.html Note: I will update the full disclosure to reflect the new feature of OpenSSH 8.9.
CVE-2021-36368 was reserved for this vulnerability.
closing bug resolved during openssh-9.0 release cycle