Dynamic Port Forwarding is the third major method of port redirection with SSH. Where as previously both local and remote port forwarding allowed interaction with a single port, dynamic allows a full range of TCP communication across a range of ports. The tool proxychains is also used to force any program you wish to use through the dynamic proxy.
Firstly we have to ensure that proxychains is set up to appropriately tunnel the program through our port forward. Open /etc/proxychains.conf and look at the bottom line. You require a socks4 proxy on 127.0.0.1 followed by an unused port. Most likely you’ll have the default value of 9050 in there which is what tor uses. From this point “changing the port in proxychains” means going in and editing this port value. Personally I remove the # from quiet_mode to suppress the output but this is more of a user preference.
An attacker is trying to make their way into a corporate network. They have compromised a web server with the IP of 192.168.1.18. We assume for simplicity that the web server happened to have credentials for each workstation and the password for the end goal computer’s RDP (hey it’s hypothetical we’re allowed to dream).
Firstly we wish to connect to Workstation 1 and see what it see’s for the purpose of our exploitation.
ssh -f -N -D 9050 email@example.com <password>
-f : This flag asks SSH to background immediately upon connection. Useful for port forwarding so you don’t need to leave a terminal open and also not ruin your forward by accidentally sending any commands.
-N : This flag instructs SSH to not send any remote commands, once more useful for port forwarding.
-D : The user determined dynamic port. This value needs to correlate to whatever is in the proxychains.conf file. We’ve used 9050 for the first value to stop us having to change proxychains.conf.
You should be familiar with the rest of the commands. Upon connection you should see it the command line background immediately. At this point we can see whatever Workstation 1 does on the 220.127.116.11/24 network. If a web server was host on 18.104.22.168 (not pictured) then the command “proxychains firefox” could be used to open firefox and the IP address 22.214.171.124 entered to view the webpage, even though it’s typically non-routable from our 192.168.1.18 position.
Now we wish to go further into the network. Workstation 2 is our target and the SSH server it’s running is on port 2222. We enter the command:
proxychains ssh -f -N -D 10050 firstname.lastname@example.org -p 2222 <password>
Once again upon connection it will instantly background. We now have two tunnels in place. The first leading into the 126.96.36.199/24 network through workstation 1, and now a second into the 10.6.6.1/24 network via workstation 2. At this point we must edit the proxychains.conf to reflect our new arbitrarily chosen dynamic port forward number (well, at least one not in use). Edit /etc/proxychains.conf and place the value of 10050 down the bottom instead of 9050. Save the new configuration file.
So now we’ve got the second tunnel in place we use it the same as the first. We want to RDP into 10.6.6.88 so we can do so with the following command.
proxychains rdesktop 10.6.6.88 -u Administrator -p password -g 90%
Hey presto we have RDP access into our end goal, two layers deeper than when we started. Obviously we have access to all of the other computers along the way in each of those networks. This is how a pen tester can turn a foot hold in a web server into a full compromise of multiple networks.
Additional Uses (I.e. Nmap)
Strictly speaking almost all we’ve done above could have been done with a combination of local port forwards. Forward Workstation 1 to the attacking machine, then connect to it in order to forward Workstation 2, etc etc. Dynamic port forwarding adds a layer of simplicity in the event we need to switch between multiple ports. We don’t want to have to tear down our tunnel every time we want to get access to a different computer. It also allows us to do things like nmap through a dynamic port forward with commands such as the following:
proxychains nmap -sTV -n -PN 10.6.6.88
This would port scan the 10.6.6.88 machine to tell us if anything else other than RDP was open. Unfortunately for us nmap via proxychains is much slower than normal, but sometimes you just have to learn to cope with some of these things. Given that nmap would be testing multiple ports this is something which can only be done with the dynamic port forward (as opposed to local or remote).