CVSS 8.1 CVE-2021-36369

CVSS 8.1 CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H

The Dropbear client through 2020.81 proceeds with establishing an SSH session even if it has never sent a substantive authentication response. This makes it easier for an attacker-controlled SSH server to present a later spoofed authentication prompt (that the attacker can use to capture credential data, and use that data for purposes that are undesired by the client user).

Affected Software:

  • Dropbear <= 2020.81

integrated in SSH-MITM

Discovered by Manfred Kaiser (AUT-milCERT)

Dropbear and Trivial Authentication

Dropbear is a lightweight SSH implementation designed for embedded systems — routers, IoT devices, and systems where OpenSSH’s resource footprint is too large. It is the default SSH client and server on many embedded Linux distributions (OpenWRT, Buildroot, etc.).

The vulnerability is that the Dropbear client prior to 2022.82 accepted trivial authentication responses from a server without warning. When a server authenticates the connecting client via:

  • none — immediate session grant without any credentials

  • keyboard-interactive with zero prompts — session granted without interaction

the client proceeds and establishes a full SSH session as if authentication succeeded normally. The user is not notified that no substantive authentication took place.

Why This Is Exploitable

The SSH protocol specifies that after the client sends an SSH_MSG_USERAUTH_REQUEST message, the server may respond with SSH_MSG_USERAUTH_SUCCESS — even if the method used was none or keyboard-interactive with zero prompts. This is technically valid per RFC 4252 (e.g., for servers that allow anonymous access).

The problem is that a Man-in-The-Middle attacker can use this to:

  1. Accept the client’s connection immediately via none auth (no credentials collected yet)

  2. Establish a session without triggering any password or key confirmation prompt

  3. Once inside the session, present a fake prompt — e.g., a sudo-style password request, a custom banner asking for re-authentication, or use SSH agent forwarding to access other systems with the user’s credentials

In deployments using agent forwarding (ssh -A), the attacker can additionally use the forwarded agent to authenticate to the real target server — see CVE-2021-36368 for the FIDO2 variant of this attack.

Specific Risk in Embedded/IoT Context

Because Dropbear is dominant on embedded systems, this vulnerability is particularly relevant in scenarios where:

  • Users connect to routers or IoT gateways via SSH

  • The devices are behind NAT and the user connects through a jump host

  • SSH agent forwarding is used across device boundaries

An attacker who can intercept traffic at a network chokepoint (ISP, shared Wi-Fi, VPN endpoint) can silently authenticate the user’s SSH session without triggering any credential prompt.

The Fix in Dropbear 2022.82

Dropbear 2022.82 added the -o DisableTrivialAuth client option. When set, the client rejects connections where the server accepted any trivial authentication method (none or empty keyboard-interactive) and terminates the connection with an error.

For the general attack description and PoC, see Trivial Authentication.

Release Announcement

Dropbear 2022.82

Note

Added client option “-o DisableTrivialAuth”. This can be used to prevent the server immediately accepting successful authentication (before any auth request) which could cause UI confusion and security issues with agent forwarding - it isn’t clear which host is prompting to use a key. Thanks to Manfred Kaiser from Austrian MilCERT

References