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
| ||
|
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