Folks,
I'm curious if the documented behavior of portable OpenSSH (specifically Linux) may be at odds with the actual behavior I have seen in my experiments. Here is the background:
I manage an application which collects data from a client script (Korn shell) which runs on Unix and Linux servers across the entire enterprise. The client communicates with a Linux server (currently running RHEL 7.9, reporting OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017) using a technique we call SSH Pass-Through and described in an article in ;login: (Secure Automated File Transfer, vol. 30, no. 4, August 2005, by Mark McCullough who was also the original author of the client). The technique is predicated on using a forced command, which we specify per key with the "command=" directive in the authorized_keys file. (The user ID we use performs several functions, so we cannot use ForceCommand in configuration.)
In theory, any SSH connection made to the account with the corresponding private key should be forced to run the command provided, which accepts a fully-qualified domain name, environment, and stream of XML data on standard input and stores the data in a file with a name reflecting the FQDN and environment along with a date stamp. In all documentation I have to hand, the forced command is applied to all sessions including interactive, non-interactive, and *subsystem calls*.
An authorized penetration tester brought to my attention that the private key embedded in the application can be extracted and used to launch a WinSCP session against the user ID which the client uses to send the data to the server. This session has the same access to all files on the server which the original user ID does, including the ability to traverse directories. This should not happen if the documentation is correct.
To test the theory, I've slightly altered the forced command to output log data to indicate whether the forced command is even executed, and if so, what command line it was passed from the client (or WinSCP). The added code is as follows:
LOGFILE=/tmp/name-of-file.log
if [[ $SSH_ORIGINAL_COMMAND ]]; then
print "Command: $SSH_ORIGINAL_COMMAND" >> $LOGFILE
else
print "No SSH_ORIGINAL COMMAND set" >> $LOGFILE
fi
I ran the client as is and received the following entry in the log:
Command: 2>/dev/null
I then set a flag in the client which removes the redirection to /dev/null and received:
No SSH_ORIGINAL COMMAND set
Finally, I connected via WinSCP as instructed by the pen tester and received no further data in the log. This indicates to me that the sftp subsystem does not even execute the forced command.
The subsystem configuration in sshd_config is
# override default of no subsystems
Subsystem sftp /usr/libexec/openssh/sftp-server
I would almost expect this sort of behavior with the internal-sftp subsystem, but not with an external executable. Can anyone shed some light on this situation?
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@att.com
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
I'm curious if the documented behavior of portable OpenSSH (specifically Linux) may be at odds with the actual behavior I have seen in my experiments. Here is the background:
I manage an application which collects data from a client script (Korn shell) which runs on Unix and Linux servers across the entire enterprise. The client communicates with a Linux server (currently running RHEL 7.9, reporting OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017) using a technique we call SSH Pass-Through and described in an article in ;login: (Secure Automated File Transfer, vol. 30, no. 4, August 2005, by Mark McCullough who was also the original author of the client). The technique is predicated on using a forced command, which we specify per key with the "command=" directive in the authorized_keys file. (The user ID we use performs several functions, so we cannot use ForceCommand in configuration.)
In theory, any SSH connection made to the account with the corresponding private key should be forced to run the command provided, which accepts a fully-qualified domain name, environment, and stream of XML data on standard input and stores the data in a file with a name reflecting the FQDN and environment along with a date stamp. In all documentation I have to hand, the forced command is applied to all sessions including interactive, non-interactive, and *subsystem calls*.
An authorized penetration tester brought to my attention that the private key embedded in the application can be extracted and used to launch a WinSCP session against the user ID which the client uses to send the data to the server. This session has the same access to all files on the server which the original user ID does, including the ability to traverse directories. This should not happen if the documentation is correct.
To test the theory, I've slightly altered the forced command to output log data to indicate whether the forced command is even executed, and if so, what command line it was passed from the client (or WinSCP). The added code is as follows:
LOGFILE=/tmp/name-of-file.log
if [[ $SSH_ORIGINAL_COMMAND ]]; then
print "Command: $SSH_ORIGINAL_COMMAND" >> $LOGFILE
else
print "No SSH_ORIGINAL COMMAND set" >> $LOGFILE
fi
I ran the client as is and received the following entry in the log:
Command: 2>/dev/null
I then set a flag in the client which removes the redirection to /dev/null and received:
No SSH_ORIGINAL COMMAND set
Finally, I connected via WinSCP as instructed by the pen tester and received no further data in the log. This indicates to me that the sftp subsystem does not even execute the forced command.
The subsystem configuration in sshd_config is
# override default of no subsystems
Subsystem sftp /usr/libexec/openssh/sftp-server
I would almost expect this sort of behavior with the internal-sftp subsystem, but not with an external executable. Can anyone shed some light on this situation?
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@att.com
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
