full-disclosure - PuTTY private key passphrase stealing attack

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Message-ID: <4C04588B.4080705@googlemail.com>
Date: Tue, 01 Jun 2010 02:47:07 +0200
From: Jan Schejbal <jan.mailinglisten@...glemail.com>
To: bugtraq@...urityfocus.com, full-disclosure@...ts.grok.org.uk
Subject: PuTTY private key passphrase stealing attack

PuTTY, a SSH client for Windows, requests the passphrase to the ssh key 
in the console window used for the connection. This could allow a 
malicious server to gain access to a user's passphrase by spoofing that 
prompt.

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.

Download attachment "screenshot-explained.png" of type "image/png" (13651 bytes)

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/