Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

Re: PuTTY private key passphrase stealing attack
From: Rob Fuller <jd.mubix () gmail com>
Date: Tue, 1 Jun 2010 01:07:39 -0400

Couldn't this also be thwarted by having a MOTD? It generally displays
before the bashrc if I'm not mistaken.

--
Rob Fuller | Mubix
Room362.com | Hak5.org



On Mon, May 31, 2010 at 8:47 PM, Jan Schejbal
<jan.mailinglisten () googlemail com> wrote:
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.

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


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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]