PuTTY vulnerability vuln-auth-prompt-spoofing

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Pre-release · Snapshot | Docs | Privacy | Changes | Wishlist

Up to and including version 0.70, the PuTTY tools had no way to indicate whether a piece of terminal output was a genuine user-authentication prompt (such as a prompt for a password, or for an SSH private key passphrase), or whether it was a faked version sent by the server after PuTTY's authentication phase had already completed.

For example, suppose that a malicious server let you log in without any authentication at all, and then started the session by sending text that looked exactly like PuTTY prompting you for your private key passphrase. If you didn't know for sure that you didn't expect that prompt, the server might trick you into entering your passphrase, which should not have been sent to any remote server.

If the server had also acquired a copy of your encrypted key file (which, for example, you might have considered safe to copy around because it was securely encrypted), then this would give it access to your private key.

This is a user-interface weakness rather than the usual kind of software vulnerability, so it requires a user-interface fix. It's also difficult to fix because the Unix terminal model gives the server so much control over what is displayed. For example, it wouldn't be enough for PuTTY to display a separator line between the real authentication prompts and the start of the main session, because the server could immediately send escape sequences that moved the cursor back up by a line and erased the separator! If you looked away from the screen and didn't catch the (probable) rapid flicker, you might easily miss that completely, and then the separator line would have been useless.

As of 0.71, we're using the following combination of strategies to distinguish legitimate from fake authentication prompts.

In GUI PuTTY: any line of the terminal containing data that was legitimately emitted by the local PuTTY during SSH connection setup is marked with what our code describes as a ‘trust sigil’. A trust sigil must be something the server can't cause PuTTY to display by sending escape sequences. We've chosen a small copy of the PuTTY program's icon, because it's multicoloured and distinctive. (You can think of it as the name of the speaker in a chat: it's indicating that PuTTY is saying whatever is written next to it.)

In Plink: at the point where authentication ends and the main session begins, we print a new interactive message: ‘Access granted. Press Return to begin session’. Then we wait for the user to acknowledge it by pressing Return, which means that even if the server overwrites the message immediately afterwards, the user will have seen it already and will know to be suspicious.

This additional interactive prompt is rather annoying (especially if you had set up one-touch authentication via a passphraseless SSH key or Pageant), so we provide as many methods as possible to avoid it:

• If you run Plink with the -batch option, it is assumed that you already know that you're not expecting any interactive authentication prompts, so you'll already be suspicious of anything that resembles one. So the new prompt is not given.
• If you run Plink with its standard input redirected to anywhere other than the terminal, then server-side authentication-prompt spoofing would not gain the server anything in any case, since you wouldn't be able to enter a response even if you were fooled by the prompt. So the new prompt is not given.
• If you trust your server not to do this in any case, you can run Plink with the -no-antispoof option, which unconditionally eliminates the new prompt.

During authentication (in all tools, GUI and console): prompts and text sent by the server as part of the authentication phase (e.g. SSH banners, or keyboard-interactive server-generated login prompts) are prefixed with a vertical-bar symbol (‘|’) on each line, and their line lengths are limited so that on a default 80-column terminal the server can't mimic an unprefixed prompt by word wrapping. This should allow you to distinguish a legitimate request for your passphrase from a fake one sent by the server, even if the server sends it during authentication.

(This does mean that banners that previously took up the full width of a terminal, e.g., 79 or 80 characters, will now wrap and look ugly. This is unavoidable.)

This vulnerability was found as part of a bug bounty programme run under the auspices of the EU-FOSSA project.

2021-07-17: 0.76 will include an additional defence against this same class of spoofing attacks, in the form of a new configuration option to make PuTTY abandon the SSH connection if the server terminates authentication without asking for any actual proof of identity (no password, no signature, etc). This way, if a server attempts this kind of spoofing, you don't have to spot the lack of trust sigil on the server's spoof prompt, because PuTTY will have terminated the connection already before the server even presents the spoof prompt. (However, you have to enable this option, because it is also legitimate and actually seen in practice for servers to perform trivial userauth for sensible reasons.)

CVE-2021-36367 also refers to this general class of attack. The public text in Mitre's database lists it as a vulnerability up to and including PuTTY 0.75, because they're thinking of 0.76's new config option as the only defence against it. With respect to them, we do not agree: we regard this class of vulnerability as having been addressed from 0.71 onwards.