We assume that the user is using key-bases ssh auth with ssh and connects using PuTTY. PuTTY now asks for the passphrase to the key. The user enters the passphrase. If the passphrase is wrong, PuTTY will now request the passphrase again after stating that it was wrong. If the passphrase is correct, the connection to the server is established.
A malicious/manipulated server could then display "Wrong passphrase" and ask for the passphrase again. If the user enters it again, it is sent to the malicious server.
As far as I can see, there are only two ways how the user might detect it:1. The real "Wrong passphrase" message is displayed without delay. After entering the correct passphrase, a small delay occurs.
2. The prompt contains the name of the key as stored on the client. Often the same name is used in the authorized_keys file on the server, giving it to the attacker. Maybe it is also possible for the server to remotely read the screen contents or duplicate it using some xterm control sequences, so users should not rely on it.
(See also the attached screenshot, where you can see that there is no visible difference.)
I assume that there are more similar issues like this one using different authentication modes etc.
This can be exploited using a modified .bashrc file. This means that once an attacker has gained access to a user account on the server, he can try this to gain the passphrase to the key.
Impact: Low.As a malicious server is required, the attack probability is not very high. Without the keyfile, the passphrase is worthless to the attacker unless it is used in multiple places. However, key-based auth is supposed to be secure even with untrusted/malicious servers.
Developer notification: The possibility of such spoofing attacks is known: http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/gui-auth.html Workaround: Load the key into the Pageant agent before esablishing the connection Other software affected: Probably many console-based SSH tools have similar issues.
Description: PNG image