Introduction
Proxychains is an incredibly useful tool that is incredibly poorly documented. In this tutorial, we will cover using proxychains and SSH to connect to a multihomed device (like a router) that is SSH enabled and using that device to forward traffic from a machine in one network, through the SSH machine, to a network on the other side.
Background
We will use the network below as an example:
SOCKS Proxy - The part you need to know
SOCKS is a proxying internet protocol. One of its most common uses is as a circumvention tool, allowing traffic to bypass internet filtering to access content that is otherwise blocked. In our scenario we will use SOCKS to create a dedicated tunnel between the attacker box and the router. Through that tunnel we can push any traffic and it will appear on the other side of the router, in the router's internal network, as if that traffic were coming from the router. Let's say that the router is blocking port 445, but you want to target the vulnerable port 445 on the internal server at 11.0.0.32. A SOCKS tunnel would allow you to do that.
WHAT YOU CAN'T DO: SOCKS is a layer 5 protocol. That means it doesn't care about anything below that layer in the OSI model! That means that you can't use it to tunnel protocols operating below layer 5. This includes things such as ping, ARP, etc. From an attacker's standpoint, it is also helpful to know that it won't allow you to perform scans using tools such as NMAP if they are scanning based on half open connections etc because that's all functionality happening below layer 5.
WHAT YOU CAN DO: Run something like metasploit's msfconsole, HTTP, SMTP or any other application layer (layer 7) protocol through the tunnel.
HOW WE'RE GOING TO USE SOCKS: In our example we assume that we have credentials to the router depicted above. Using those credentials, we are going to set up a SOCKS proxy server on our attacker box that is connected via a SOCKS tunnel to the router. We will pipe traffic from an application of interest, in this case msfconsole, through the SOCKS tunnel, into the router, and out of the router's internal interface as if it traffic coming from the router itself.
Proxychains - How it fits in
Most people think of proxies as needing to be a separate host that you connect to and it will forward your traffic on in your place. However, it is possible to proxy traffic from one application on your local computer through another application on your local computer. That's what proxychains does.
Proxychains allows us to interface with our SOCKS tunnel. We can configure proxychains to pipe all of the data that an application would normally just push out to the network through normal means, through proxychains, into our SOCKS tunnel, and out of the router on the internal interface.
Creating the SOCKS tunnel and using Proxychains
Step 1 - Set up the SOCKS Server and the SOCKS tunnel using SSH
The first thing we have to do is set up our SOCKS server and the SOCKS tunnel to the router. This will give our traffic a path to take. To do that you would use the following command:
root@whatever: ssh -NfD <local_listening_port> <username>@<router_ip>
What that would look like in our scenario:
root@bt: ssh -NfD 9050 root@10.0.0.1
What the options are:
-N Don't execute a remote command. IE: don't open up a command shell like SSH normally would.
-f Background SSH after you enter credentials
-D Create a dynamic application-level port forwarding tunnel. This is the part that actually creates the SOCKS server. It opens the port you specified after the -D on YOUR local box (attacker in our case). Any traffic that passes through this port on your local box will pass through the SOCKS tunnel to the router.
If done correctly, the router should prompt you for credentials and after you enter them SSH will go immediately to the background. If you run a netstat -antpu on linux or netstat -ano on windows you should see a listening port on your computer for 9050.
Step 2 - Using Proxychains
Now you've set up your SOCKS server. All that's left is using proxychains. On Linux, the proxychains configuration file is stored at /etc/proxychains.conf. It should look like this:
# proxychains.conf VER 3.1
#
# HTTP, SOCKS4, SOCKS5 tunneling proxifier with DNS.
#
# The option below identifies how the ProxyList is treated.
# only one option should be uncommented at time,
# otherwise the last appearing option will be accepted
#
#dynamic_chain
#
# Dynamic - Each connection will be done via chained proxies
# all proxies chained in the order as they appear in the list
# at least one proxy must be online to play in chain
# (dead proxies are skipped)
# otherwise EINTR is returned to the app
#
strict_chain
#
# Strict - Each connection will be done via chained proxies
# all proxies chained in the order as they appear in the list
# all proxies must be online to play in chain
# otherwise EINTR is returned to the app
#
#random_chain
#
# Random - Each connection will be done via random proxy
# (or proxy chain, see chain_len) from the list.
# this option is good to test your IDS :)
# Make sense only if random_chain
#chain_len = 2
# Quiet mode (no output from library)
#quiet_mode
# Proxy DNS requests - no leak for DNS data
proxy_dns
# Some timeouts in milliseconds
tcp_read_time_out 15000
tcp_connect_time_out 8000
# ProxyList format
# type host port [user pass]
# (values separated by 'tab' or 'blank')
#
#
# Examples:
#
# socks5 192.168.67.78 1080 lamer secret
# http 192.168.89.3 8080 justu hidden
# socks4 192.168.1.49 1080
# http 192.168.39.93 8080
#
#
# proxy types: http, socks4, socks5
# ( auth types supported: "basic"-http "user/pass"-socks )
#
[ProxyList]
# add proxy here ...
# meanwile
# defaults set to "tor"
socks4 127.0.0.1 9050
I realize it's long and potentially daunting. For our purposes, we only care about the last line. Unless you changed the port from 9050 you actually don't have to change anything!
If you want to use a different port, you need to change the port from 9050 to whatever you used after the -D. Additionally, proxychains will always check your active directory first
for a configuration file before it will use the default one at /etc/proxychains.conf. Using proxychains from here is simple:
root@whatever: proxychains <name_of_application>
For example you could do:
root@whatever: proxychains msfconsole
Whatever you do in msfconsole will now first be shoveled through port 9050 (or whatever port you chose), through your SOCKS tunnel,
through the router, and into the destination internal network.
Observed Wonky Behavior
While I was using proxychains it would sometimes misbehave in strange ways. For example, I tried opening firefox with:
proxychains firefox
and for some reason it didn't work. If you don't first close all other instances of firefox before using proxychains
IT WON'T WORK. Proxychains also sometimes hiccups for various other reasons (that I couldn't tell you), but that doesn't mean you did it wrong. You may just have to reset
everything and try again.
