I'm responding to a penetration test finding on one of my application servers. The finding is that the private key embedded in my client script is capable of being used to open an SFTP session to the server.
My understanding has been that the use of the "command="
parameter on the relevant public key precludes the use of SFTP with the corresponding private key. However, the pen tester was able to use WinSCP with the key extracted from the client to access anything the service account owning the key can access.
The application uses the following command (suitably amended) to transfer data from client to server:
(print ${FQDN} ; print ${Environment} ; cat ${OutFileXML}) | \
ssh -Ti ${EmbeddedPrivateKey} \
-o HostKeyAlias="${Alias}" \
-o GlobalKnownHostsFile="${EmbeddedKnownHosts}" \
-o UserKnownHostsFile="${ClientSpecificKnownHosts}" \
-o StrictHostKeyChecking="yes" \
-o CheckHostIP="no" \
-o NumberOfPasswordPrompts=0 \
${User}@${Host} 2>/dev/null
The forced command is set up in the public key with the "command=" parameter. I've inserted the following debug code at the top of the script executed by this parameter:
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 then tried three things:
- I ran the application as is.
- I ran the application with a flag which removes the "2>/dev/null" after the ssh command for debugging purposes.
- I attempted to log in to the same user ID with the same private key from a PC running WinSCP. This was successful, although to my understanding it should not have been.
After these steps, the logfile shows:
Command: 2>/dev/null
No SSH_ORIGINAL COMMAND set
There is no indication that the forced command even ran when I connected from WinSCP. So I'm unable to determine from there whether to accept the connection and attempt to read data from standard input.
I've read in several places that an SFTP connection is supposed to run the forced command before launching the sftp-server process, but this appears to not be the case, as whenever the WinSCP connection is active, the /usr/libexec/openssh/sftp-server
process is running.
Is there a way to ensure a specific user/key cannot be used for interactive SFTP without breaking this method of file transfer?
ForceCommand
for the entire user (not just a particular key) in the sshd_config?