Latest news

No Shell? No Problem!

Enumerating internal networks via ssh-tunnels, Alexis V, November 2021

On a recent engagement, we were tasked to assess the security of an Secure File Transfer Protocol (SFTP) server. We were provided with a regular account to facilitate the file uploads, and so proceeded to work our way through the common checks. We tried to:

• Log in directly via SSH with the account – this failed as the user most likely had the shell set to /usr/bin/false or similar. 
• Attempt command execution by appending a command right after SSH login: e.g. ssh user@host /bin/bash. This also failed as the sftp user was set up correctly. 
• Log in via SFTP, which we did, and checked to see if we were in a chroot jail – as this turned out to be the case we could not access any other directories, files, etc.
• Attempt SSH tunnelling with the valid account. This worked, as we were able to bind to an internal service via a command like:  ssh -CnfN -L 31337:127.0.0.1:22 user@host

Great, so far so good as we can now access the internal network and start searching for any services that we can exploit to gain a foothold. The problem is that this presents us with 65,535 ports to go through, and that’s just on the SSH host. It doesn’t include all the possible internal hosts. Going through all of these would be an extremely time consuming process if we did so manually.

Despite searching, I was unable to find any tools/scripts that would help me solve this problem, so we decided to write our own.

The concept was fairly simple and could be broken down into the following steps:

• Create an SSH tunnel to an internal IP and port
• Use netcat to prod the tunnel on the localhost 
• Look for a ‘connect failed’ string from SSH, indicating a closed port
• Or catch a timeout exception, indicating a valid port
• Kill the tunnel and move on to the next internal IP and port

After a few hours, we had a working proof of concept that (albeit slow, with a small false positive rate) got the job done. Here’s a sample output of the tool running:

With this information, we can then bind to the known services, access them locally, and start exploiting them to help laterally move through the network.

We’ve uploaded the code to our GitHub. Note that the script was created during an assessment so is in no way optimised, it also sometimes reports false positives (although this can be reduced by setting a correct timeout variable in the script). We always appreciate pull requests!