1

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:

  1. I ran the application as is.
  2. I ran the application with a flag which removes the "2>/dev/null" after the ssh command for debugging purposes.
  3. 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?

2
  • I'm not sure this has anything to do with SFTP. Does the command even get forced for a standard SSH connection? Have you tried forcing the command with ForceCommand for the entire user (not just a particular key) in the sshd_config?
    – Ja1024
    Commented Jun 6, 2023 at 23:39
  • @Ja1024: The user has multiple keys with different forced commands, so using ForceCommand in sshd_config won't work. The forced command is invoked for a standard SSH connection as demonstrated. Commented Jun 8, 2023 at 14:18

1 Answer 1

0

If I understand your concerns correctly:

  1. Make sure the user cannot use the private key to gain SSH access, which offers even more possibilities. The trick is usually to set the shell for the user to /bin/false. This is enough to create a SSH tunnel though and should be sufficient for SFTP afaik.
  2. Limit what the user can do with that private key and reduce file exposure server-side. You're saying that the transfer is from client to server. Then you probably want a one-way communication channel, so that the client can upload new files, but cannot read remote files from the server. Then here is one relevant topic you may find useful How can I set up one-way scp?. One approach is to use ProFTPd, but OpenSSH should suffice as well. Disclaimer: I have not tried any of those suggestions but I intend to do so in the future.
1
  • Our corporate standard is OpenSSH, so ProFTPd is not an option here. The issue is that in many other questions across StackExchange, it is asserted that OpenSSH sshd executes forced commands when the SFTP subsystem is invoked, but the experiment above demonstrates this is clearly not the case. Commented Jun 8, 2023 at 14:24

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .