[Bug 3316] New: possible bypass of fido 2 devices and ssh-askpass

[bugzilla-daemon at mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=3316

            Bug ID: 3316
           Summary: possible bypass of fido 2 devices and ssh-askpass
           Product: Portable OpenSSH
           Version: 8.6p1
          Hardware: All
                OS: All
            Status: NEW
          Severity: major
          Priority: P5
         Component: ssh
          Assignee: unassigned-bugs at mindrot.org
          Reporter: m.kaiser at bmlv.gv.at

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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.