CVSS 5.3 CVE-2016-20012

CVSS 5.3 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N

OpenSSH through 8.7 allows remote attackers, who have a suspicion that a certain combination of username and public key is known to an SSH server, to test whether this suspicion is correct. This occurs because a challenge is sent only when that combination could be valid for a login session.

Affected Software:

OpenSSH <= 8.7

integrated in SSH-MITM

Description

The only required authentication ‘method name’ is “publickey” authentication. All implementations must support this method; however, not all users need to have public keys.

This makes it complicated to find out, if a user is allowed to login and wants to use publickey authentication or another method like password. The reason is, because publickey authentication comes before password authentication.

For a man in the middle server, it’s important to know, which authentication method will be used by the client. This information can be queried from the destination server.

All SSH server implementations must provide a method, which allows the client to check if a given username and publickey combination is known by the server.

The reason for implementing this method was because private keys are often stored in an encrypted form at the client host, and the user must supply a passphrase before the signature can be generated. To avoid unnecessary processing and user interaction, the following message is provided for querying whether authentication using the “publickey” method would be acceptable.

byte      SSH_MSG_USERAUTH_REQUEST
string    user name in ISO-10646 UTF-8 encoding [RFC3629]
string    service name in US-ASCII
string    "publickey"
boolean   FALSE
string    public key algorithm name
string    public key blob

The server must respond to this message with either SSH_MSG_USERAUTH_FAILURE or with the following:

byte      SSH_MSG_USERAUTH_PK_OK
string    public key algorithm name from the request
string    public key blob from the request

graph TD A[SSH Client] -->|send publickey| B(OpenSSH) B --> C{username and publickey known?} C -->|yes| D[send SSH_MSG_USERAUTH_PK_OK] C -->|no| E[send SSH_MSG_USERAUTH_FAILURE]

Note

According to RFC-4252 the client is not required to complete the authentication process.

If the client receives a SSH_MSG_USERAUTH_PK_OK message, the username/publickey combination is known by the server. When a SSH_MSG_USERAUTH_FAILURE the client can send a new username/publickey combination to the server.

If no valid combination was found and no publickeys are left, the user is not allowed to login with publickey authentication.

This allowed a man in the middle server to check, if the intercepted user is allowed to login with publickey authentication or not.

Test with SSH-MITM

SSH-MITM’s authetication process implements this method to check if the intercepted user is allowed to login wiht publickey authentication on the remote server.

There is also a standalone check available, which allows during an audit to check a username/publickey combination against a server.

If you are using SSH-MITM <= 4.x.x you must use the audit subcommand.

$ ssh-mitm audit check-publickey --host 127.0.0.1 \
    --username testuser \
    --public-key ~/.ssh/id_rsa.pub
valid key

SSH-MITM 5 and later implemented the check-publickey as its own subcommand.

$ ssh-mitm check-publickey --host 127.0.0.1 \
    --username testuser \
    --public-key ~/.ssh/id_rsa.pub
valid key

CVSS 5.3 CVE-2016-20012

Description

Test with SSH-MITM

References