full-disclosure - Re: 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 for Android: free password hash cracker in your pocket

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

Date: Tue, 1 Jun 2010 01:07:39 -0400
From: Rob Fuller <jd.mubix@...il.com>
To: Jan Schejbal <jan.mailinglisten@...glemail.com>
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: Re: PuTTY private key passphrase stealing attack

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@...glemail.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/