By Mark Baggett
Proxychains is a Linux dynamically loadable library that will intercept any TCP and UDP traffic from a specific process and tunnel it over HTTP, SOCKS4 or SOCKS5 proxy. For this discussion I will be focusing on SOCKS4 proxies setup with the SSH -D parameter. Proxychains is already installed in Backtrack4 and configured to tunnel over a SOCKS4 listener on port 9050 on the local host. By default, proxychains uses the configuration file /etc/proxychains.conf. But Proxychains will look for a proxychains.conf file in the current working directory and use it if one exists. To illustrate how an attacker or penetration tester can use this powerful tool let us look at the following scenario. The attacker is attempting to gain access to the TARGET host at 10.10.1.2 on the following network. (Note the super 1337 Visio skills)
The attacker brute forced valid credentials to the public SSH service on 192.168.100.13. Then they cracked passwords obtained from that machine and used them to find valid credentials on a second DMZ host at 192.168.100.15. That host, has two network cards and the second network interface straddles the corporate firewall and connect to the internal network where our target 10.10.1.2 sits. Note that for this attack to work the second host is not required to straddle the firewall, it just needs to have firewall rules in place that allow it to access the internal target.
The attacker starts his attack by connecting to the external SSH listener at 192.168.100.13 as follows:
"-D 127.0.0.1:9050" causes a dynamic port forwarder to start on port 9050 of the attackers local host. Since the default proxychains.conf file already has an entry to proxy on port 9050 (tor's default) all the attacker has to do is launch a program and proceed it with "proxychains" and all its traffic will be shoveled to the host 192.168.100.13. If the attacker ran:
>proxychains wget localhost
They would get back the website listening on port 80 on host 192.168.100.13. But I want to bounce off that server and gain access to 192.168.100.15. So I could do this:
>proxychains ssh email@example.com
That would make an SSH connection into 192.168.100.15. On that host it would appear that the connection came from 192.168.100.13. In this case after I make the connection to 192.168.100.15 I really want to pivot a second time to get to the internal host. So I run the following:
What is really awesome here is that this establishes a NEW dynamic port forwarder on the attackers localhost at port 8090. The attacker now has the multiple dynamic port forwarders listening on his host. The first port forwarder on 9050 takes him into 192.168.100.13 and the second on 8090 takes him to 192.168.100.15. The attacker can use proxychains again with a different configuration file to tunnel all the TCP and UDP packets from a program to execute on the second pivot point at 192.168.100.15. To do this I did the following:
>cat /etc/proxychains.conf | sed "s/127.0.0.1 9050/127.0.0.1 8090/g" > ./proxychains.conf
or you can use your favorite editor to change the port at the bottom of the configuration file. Then from the directory containing my new configuration file I ran this:
Which started the NESSUS server daemon and allowed me to do a full vulnerability scan on the internal host. Nessusd worked great over proxychains! Nmap, Metasploit and others also worked well. To launch Metasploit using proxychains you'd simply run the following:
Here is a quick video showing how quickly you pivot through hosts and capture the target.
I hear you, "Dude... That is scary. How do I prevent this from happening?"
Well, first be sure to minimize the ports you open between hosts and don't have host that straddle your firewall. Second, you can turn off port forwarding in your sshd configuration files. Edit /etc/ssh/sshd_config and set "AllowTCPForwarding to NO". While your in there make all these changes. Remember that if an attacker has a shell they can install their own forwarders or use netcat so this is just one step in trying to preventing the host from being a relay. It does make the attacker job much harder when you turn off the DEFAULT mode of being a relay.
Shout out to Jim Shewmaker and ace1 over at SANS Netwars. Ace1's excellent paper inspired me to take another look at proxychains.
Note: proxychains support CHAINS of proxies (imagine that). There is probably a more elegant way to do this using just one configuration file and a strict chain. Do you know how? Leave me a comment!
Mark Baggett is teaching SANS 504 in Raleigh NC June 21st! Click here for more information.