CVSS 8.1 CVE-2021-36367

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

Note: MITRE’s description is wrong. Please read note bellow.

PuTTY through 0.75 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:

  • PuTTY < 0.71

integrated in SSH-MITM

Discovered by Manfred Kaiser (AUT-milCERT)

SSH “none” Authentication and PuTTY’s Behavior

The SSH authentication protocol (RFC 4252) includes a method called none. Its purpose is to allow clients to query which authentication methods a server supports: the server responds with a list of acceptable methods (publickey, password, keyboard-interactive, etc.) along with an SSH_MSG_USERAUTH_FAILURE message.

However, the protocol also permits a server to respond with SSH_MSG_USERAUTH_SUCCESS to a none request, granting immediate access. This is valid for servers that intentionally allow anonymous or unauthenticated connections.

A Man-in-The-Middle attacker can exploit this: by accepting the none authentication method, the attacker’s SSH server can establish a session with any connecting client without needing to interact with the user at all. No password prompt, no key confirmation — the session is established silently.

In PuTTY prior to 0.71, there was no indication to the user that this had occurred:

  1. User opens PuTTY and connects to what they believe is their server

  2. The MITM server accepts none auth — session established

  3. PuTTY shows the normal terminal window

  4. The MITM can now present any prompt (a fake sudo request, a custom banner, a keyboard-interactive prompt asking for a password) which the user has no reason to distrust

  5. Whatever the user enters goes to the attacker, who can replay it to the real server

Why This Attack is Invisible Before PuTTY 0.71

PuTTY versions before 0.71 display no warning and show no visual difference when a server accepts none authentication. The terminal window opens and behaves exactly as it would after a legitimate authentication. The user has no indication that they never authenticated.

In normal authentication, PuTTY displays the authentication banner and prompts for credentials. When none auth succeeds, these steps are skipped — but PuTTY < 0.71 does not make this skip visible.

The Trust Sigil System (PuTTY 0.71 – 0.75)

PuTTY 0.71 introduced the trust sigil system as a partial mitigation: a visual marker ((!) or a colored indicator in the title bar) is shown when the server accepted the connection without requiring substantive authentication. The purpose is to warn the user that anything displayed in the terminal before the sigil is trusted output, while the sigil marks the boundary where PuTTY’s own indication ends.

However, 0.71–0.75 do not actively prevent the attack:

  • The trust sigil is displayed, but PuTTY still connects

  • A user who does not know what the sigil means (or does not notice it) is still vulnerable

  • Nothing stops a user from typing credentials into a subsequent prompt

Version Summary

PuTTY version

Behavior

< 0.71

none auth accepted silently — no indicator shown. Attack completely invisible.

0.71 – 0.75

Trust sigil displayed. Attack works if user ignores or doesn’t understand the sigil.

≥ 0.76

-o RejectTrivialAuth=yes available. Connection is terminated if server accepts trivial auth.

Note

Comment from Simon Tatham:

CVE-2021-36367 refers to this new option as a fix for a vulnerability, and describes the vulnerability as “PuTTY through 0.75 proceeds with establishing an SSH session even if it has never sent a substantive authentication response”. With respect to the author of that text, we consider that to be misleading. It is perfectly legal for the server to waive authentication, and actually useful in some legitimate use cases; it is perfectly legal for PuTTY to proceed with the connection regardless; and the trust sigil system introduced in 0.71 already defends against every spoofing/phishing attack we know of that a server could attempt by doing this unexpectedly. This new option is a UI improvement, but not in and of itself a vital vulnerability fix.

Version Discrepancy

NVD and MITRE list this vulnerability as affecting “PuTTY through 0.75”, while the affected version here is listed as “PuTTY < 0.71”. This discrepancy is intentional and follows from the version summary above:

  • < 0.71: The attack is completely invisible — no indicator shown. This is the unambiguous vulnerable range.

  • 0.71 – 0.75: The attack works, but a trust sigil is shown. Whether this counts as “affected” depends on whether one considers a visible-but-ignorable warning sufficient mitigation. Simon Tatham considers 0.71+ already mitigated (see note above); NVD counts through 0.75.

  • ≥ 0.76: Active prevention is available via -o RejectTrivialAuth=yes.

PoC Exploit

The trivial authentication phishing attack is described in Trivial Authentication.

Vendor Credit

Note

AUT-milCERT recommended this enhancement and contributed substantially to its implementation.

Source: https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/reject-trivial-auth.html

References