Traversing NAT firewalls couldn't be easier with a well crafted SSH proxy. This week Darren and Shannon break down reverse shells and persistence using a WiFi Pineapple and some autossh-fu. Plus, SSHFS GUIs for Linux, ClientAliveMaxCounts, Putty keys without Pageant and more!

Download HD Download MP4

In this episode Darren and Shannon break down reverse shells via proxy. The network scenario is that of two devices on disparate networks who's firewalls won't allow inbound connections. Typically this is a NAT router that you haven't access to. Assuming both devices can create outbound connections, which is commonly the case, we'll configure an SSH server to act as a relay for our reverse shell.

In this scenario three hosts are involved. First is our WiFi Pineapple, which is the device we'll be getting the reverse shell from -- meaning we'll be able to login to a terminal on this machine. In our example it is connected to the Internet by way of a 3G/4G modem which our carrier firewalls. Using AutoSSH -- a tool to maintain a persistent SSH connection -- we establish a connection back to our second host, relay.hak5.org. In turn our third host, my laptop (hostname: dk10) connects to relay.hak5.org as well.

## browse to 172.16.42.1/ssh.php (WiFi Pineapple) and Generate Key
##SSH Into WiFi Pineapple
## Establish connection to relay adding key fingerprint to known_hosts on pineapple
root@pineapple# ssh user@relay.wifipineapple.com
## Refresh ssh.php showing known_hosts. Copy RSA key string from "rsa" to "root@pineapple"
## From new session on relay, paste RSA key into authorized_keys file
user@relay$ echo "" >> ~/.ssh/authorized_keys
## Logout of the relay
user@relay$ exit
## Demonstrate how without the -i option ssh on the pineapple will still prompt for password
root@pineapple# ssh user@relay.wifipineapple.com #this will prompt for passwd
## Demo how to properly SSH into a host with a dropbear RSA key
root@pineapple# ssh user@relay.wifipineapple.com -i /etc/dropbear/id_rsa
user@relay$ 
## Configure SSHD to allow TCP Forwarding **Necessary for Server Admin Only**
## Become root
user@relay$ sudo -i
## Add settings to sshd config file
root@papaya# echo "AllowTcpForwarding yes" >> /etc/ssh/sshd_config
root@papaya# echo "GatewayPorts yes" >> /etc/ssh/sshd_config
## Restart SSH Daemon
root@papaya# /etc/init.d/ssh restart
## Logout of root
root@papaya# exit
## Logout of relay completely
user@relay$ exit
## Update SSH Connection Command from 172.16.42.1/ssh.php to reflect username and host
## Enable SSH on boot and SSH keepalive, then click Connect
## From localhost (your laptop) SSH into the newly configured WiFi Pineapple via the relay
## Demonstrate technique one: SSH from SSH (not as sexy)
darren@dk10$ ssh user@relay.wifipineapple.com
user@relay$ ssh root@localhost -p 4255
## Logout of both pineapple and relay
root@pineapple# exit
user@relay$ exit
## Demonstrate technique two: Single SSH session
darren@dk10$ ssh root@relay.wifipineapple.com -p 4255

SSH and SOCKS5 Proxy Follow-up

MetalX1000 writes regarding SSHFS from the command line in Linux

OK, I love that you showed how to do it this way. But, for the Shannon's of the world who need a GUI, you can always just open Nautilus and in the location bar type ""sftp://user@server"" and then make a short cut to that in the left side bar of Nautilus.

Thanks for the tip MetalX1000. We demonstrated on the show one more technique. From Gnome2's "Places" menu click Connect to Server and select SSH.

Spectrakid writes regarding setting up an SSH Server on Linux and "apt-get install ssh"

I thought you needed the ""openssh-server"" package to set up a ssh server in Debian based systems........ssh is a metapackage that simply depends on openssh-server & openssh-client

There are about as many ways to skin a cat in Linux as there are dependency issues ;-)

wirerat1 writes regarding keeping connections alive

ClientAliveCountMax 0 does not do what he thinks it does.

True, it doesn't do what it claims to do.

From the MAN Page:

ClientAliveCountMax sets the number of client alive messages (see below) which may be sent without sshd receiving any messages back from the client. If this threshold is reached while client alive messages are being sent, sshd will disconnect the client, terminating the session. It is important to note that the use of client alive messages is very different from TCPKeepAlive (below). The client alive messages are sent through the encrypted channel and therefore will not be spoofable. The TCP keepalive option enabled by TCPKeepAlive is spoofable. The client alive mechanism is valuable when the client or server depend on knowing when a connection has become inactive.
The default value is 3. If ClientAliveInterval (see below) is set to 15, and ClientAliveCountMax is left at the default, unresponsive ssh clients will be disconnected after approximately 45 seconds.

Meaning a ClientAliveCountMax 0 should continue sending Keep Alive messages over the SSH connection for every ClientAliveInterval forever, but in practice, it doesn't. I've started using 99999 as my value of choice, however I'm sure there's a better way.

Steven writes regarding Pageant and Putty

In Putty you don't need the pageant program to use the private key. Select your profile and hit load so that you can edit the profile. On the right go to SSH -> Auth. There you will find ""Private file for authentication"", hit browse and select your private key. Go back to Session. Select your profile and hit save. Next time you open a connection putty will automatically use the key. Note: The key will not be stored in memory so you'll need to enter the passphrase each time you connect to the server.