Although I’m quite aware this subject has probably been blogged to death, this entry serves two purposes. For one my memory is shot and I need to write this somewhere to help me not forget. The second is the simple fact that this site is, after all, for the beginner.
Imagine yourself the following scenario: You’re at work (or one of your clients) and you need to RDP out to your place. Then you remember port 3389, amongst others, are blocked from going outside the corporate network. What does a bored admin do…? What will he do? He organizes ahead of time so as to be able to connect home using a SSH Tunnel.
The SSH Tunnel will permit the user to forward local ports on the computer through the tunnel, having them connect to the remote station using that specified port. In theory, this connection will sneak through the firewall rule preventing the remote desktop connection.
In the following scenario let us imagine that all machines involved are Windows machines. Our admin needs to prepare a few things before hand as well. Such as which outbound ports are not blocked (probably 80 – 443), and have a SSH Server running on his home computer (let’s assume ports are correctly redirected in his router). This server must be listening on one of the ports not blocked by the corporate firewall.
With a server at home listening on a proper port, all the admin needs to do is connect to it and create a tunnel. There are many free SSH server application running on Windows available on the Internet as well as clients. Make sure the applications permit tunnels and TCP forwarding.
Setting up the Client: In this example, our admin is using PuTTY as his client of choice. He enters his home server’s IP.
Then configures the port forwarding, don’t forget to click the “Add” button.
Once connected it should look something like the image below. What will happen is any connection done to localhost on port 443 will be sent through the tunnel and end up on the remote host’s 3389 port. Of course this can be done for other protocols and not just for remote desktop. FTP, SMB, NetCat connections and Metasploit modules can also be tunneled in this matter. It also has the added bonus of encrypting your traffic.
The tunnel is ready for use and all that needs to be done is connect to port 443 on your localhost using “Remote Desktop Connection”.
Connecting to one’s self using “mstsc.exe”.
And there we have it; Windows Remote Desktop Connection is playing with itself.
Of course I’d like to show more proof of success with a Wireshark capture. Seeing I’m doing all of this on my local LAN, and it is a pain to sniff “127.0.0.1” on a windows machine. You’ll have to either take my word on it, or test it yourself. You can do it from your work place, modify your own firewall rules to block outbound RDP connections or simply enable a rule on your local machine preventing outbound 3389.
Now I must add this scenario may not be suitable for all work place environments. Some actually secures their permitted outbound ports with some sort of content filtering. In this case it would be detected and blocked due to the fact that another protocol other than HTTP is using that port. Uniting SSH Tunneling with a Proxy Tunnel would bypass this bump. This would encapsulate our SSH session in the proper protocol, hence making it pass the filter.
Another plausible situation where tunneling can be used, is when you acquire a remote shell on a compromised system. Using readily available software you can end up with the same result… just done a bit differently. That is out of the scope of this blog entry but could be an idea for another one.