Message-ID: <AANLkTim6CMVyD1YhDybbfw7fSFSRwmW6c1j6Yz-H3Aqx@mail.gmail.com>
Date: Tue, 1 Jun 2010 09:35:51 +0100
From: Benji <me@...ji.com>
To: Rob Fuller <jd.mubix@...il.com>
Cc: full-disclosure@...ts.grok.org.uk, bugtraq@...urityfocus.com
Subject: Re: PuTTY private key passphrase stealing attack

You should make a show about it.

On Tue, Jun 1, 2010 at 6:07 AM, Rob Fuller <jd.mubix@...il.com> wrote:
> 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/
>

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

Powered by blists - more mailing lists