openssh bugs - Jun 2021 - [Bug 3316] possible bypass of fido 2 devices and ssh-askpass

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.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
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 at 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 :)

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

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

m.kaiser at bmlv.gv.at changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #2 from m.kaiser at bmlv.gv.at ---
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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

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

m.kaiser at bmlv.gv.at changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |https://docs.ssh-mitm.at/tr
                   |                            |ivialauth.html

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

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

--- Comment #3 from m.kaiser at bmlv.gv.at ---
* 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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

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

Manfred Kaiser <manfred.kaiser at bmlv.gv.at> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|8.6p1                       |8.8p1

-- 
You are receiving this mail because:
You are watching the assignee of the bug.
You are watching someone on the CC list of the bug.

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

--- Comment #4 from Manfred Kaiser (bmlv.gv.at) <manfred.kaiser at
bmlv.gv.at> ---
CVE-2021-36368 was reserved for this vulnerability.

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #5 from Damien Miller <djm at mindrot.org> ---
closing bug resolved during openssh-9.0 release cycle

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.