The forced command actively uses the client's input to feed data to the server (it constructs a file name from the information supplied by the client). So changing the forced command as stated will break the application. I would need to create a test bed to simulate the listener rather than use the server as is, where is. That may produce false or misleading results.
A pseudocode description of the forced command follows:
Read one line from stdin and store to $FQDN.
Read one line from stdin and store to $ENVIRONMENT.
Construct a temporary and a permanent file name using the system date, process ID, $FQDN, and $ENVIRONMENT.
Slurp up (dd) all remaining data from stdin and store in the temporary file name constructed in the previous step.
Perform some textual cleanup on the temporary file.
Save the cleaned-up file to the permanent file name.
Emit a success message to stdout.
Obviously there is also error handling, which emits error messages to stdout. But WinSCP is giving no indication that anything has been sent to it during the session setup.
Oddly enough, the same behavior occurs when the embedded key is used to launch an interactive sftp session from the host running the legitimate client:
# sftp -i ${embeddedKey} ${user}@${host}
<Standard warning from /etc/issue.net>
Connected to ${host}.
sftp> ls
README collectors receive-data.ksh tmp
sftp> ^D
So we can probably write off any idiosyncrasies of WinSCP and work only with OpenSSH. Note there is no output from the script whatsoever.
Mike McManus
Principal – Technology Security
GTO Security Governance Team - Unix
P: He/Him/His
AT&T Services, Inc.
20205 North Creek Pkwy, Bothell, WA 98011
michael.mcmanus@xxxxxxx
-----Original Message-----
From: Jochen Bern <Jochen.Bern@xxxxxxxxx>
Sent: Thursday, July 6, 2023 4:20 AM
To: openssh-unix-dev@xxxxxxxxxxx
Cc: MCMANUS, MICHAEL P <mm1072@xxxxxxx>
Subject: Re: RE: Subsystem sftp invoked even though forced command created
On 05.07.23 18:01, MCMANUS, MICHAEL P wrote:
> It appears the forced command either does not run or runs to completion
> and exits immediately, as there is no process named "receive.ksh" in
> the process tree.
FWIW, two cents of mine:
-- The script *exiting* should *not* prompt sshd to execute the
requested subsystem "as a second thought", or else it'd happen all over
the place.
-- The process' cmdline would state the shell executing the script (ksh,
I suppose?) rather than the script file.
In the meantime, I received an (off-list) e-mail pointing out that your
script obviously accepts input from stdin (note the "-T" given to ssh,
so no tty):
>> The actual command is similar to the following (parameters inserted to protect the source):
>> (print ${FQDN} ; print ${Environment} ; cat ${OutFileXML}) | \
>> ssh -Ti ${EmbeddedPrivateKey} ...
and that it's conceivable that WinSCP might send a command line
executing sftp-server, just in case the server provides it with a login
shell instead of calling the SFTP subsystem directly; Hence the theory
that the script has some command injection vulnerability.
Does the exploit still work when you change the authorized_keys from
command="/.../receive.ksh"
to, e.g.,
command="/bin/ksh -c '/.../receive.ksh </dev/null'"
to suppress the client's input?
Kind regards,
--
Jochen Bern
Systemingenieur
Binect GmbH
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
