Network Pivoting Methods for Beginners
Pivoting is a concept that is difficult for many newcomers to penetration testing to utilize, let alone grasp. It's only lightly touched upon in many of the beginner level courses you can find online. Outside of that, it's up to the student to go out and look for the solutions.
I'm going to show you three ways to pivot to an internal network once you've gotten a foothold on your first target machine.
The first method will be using Metasploit and a built-in script/post module. The next will be using a socks4 proxy in Metasploit to scan a network you found in the first method and the last will be my preferred method: manually pivoting using ssh tunneling and proxychains.
Before I move on, I want to touch on why the third method I mentioned is my preference. Simply speaking, beginners should always be looking to level-up their skills. If you've taken an entry-level cybersecurity course you might be thinking about other certifications down the line and the OSCP should be on your short list.
Offensive Security only allows one use of Metasploit on the exam so it would be wise to practice doing everything manually from day one. Metasploit is a wonderful tool, but you'll be shortchanging your progress if you don't practice manual techniques.
A TLDR OF THE PIVOTING COMMANDS ARE AVAILABLE AT THE END OF THE ARTICLE
COLLECT YOUR EQUIPMENT
First, we need to set up our pivoting lab. The ingredients are as follows:
Virtualbox
Kali Linux VM
Proxychains (should come installed with Kali or apt-get install proxychains)
Ubuntu Server 14.04.4 32 bit VM (https://www.osboxes.org/ubuntu-server/)
VSFTPD 2.3.4 for our Ubuntu Server (https://github.com/nikdubois/vsftpd-2.3.4-infected)
Metasploitable 2 for our inner network machine (https://www.vulnhub.com/entry/metasploitable-2,29/)
SETUP
To start things off, we'll need to create new virtual machines for our server and the vulnerable machine that will be on the internal network.
Go to File > Machine > New to make a new VM. Select Ubuntu 32 bit and import the virtual
machine disk images.
The next step is to begin configuring the network. You'll want to go to the Tools menu near the top of the Virtualbox menu interface above the VM listings. Tools > Network > Create is how we'll be creating a new host-only adapter. This will be the internal network for Metasploitable 2. When creating it, select <configure adapter automatically> and tab over to DHCP server. Enable the DHCP server via the checkbox.
Go into the network settings of the Ubuntu Server and select whatever network your main lab network is for the first network adapter. Enable the second adapter and select the host-only network we just created. This enables the outer network to communicate with the inner one.
Select the same host-only network for Metasploitable's first (and only) network adapter. This cuts the VM off from the main network and makes it only discoverable from the Ubuntu machine.
Log into the Ubuntu machine (osboxes:osboxes.org) and sudo su to the root user. Change the password to something short and lame. Now we're going to install VSFTPD 2.3.4 on it to make it vulnerable to our Kali box.
TROUBLESHOOTING THE HOST-ONLY NETWORK INTERFACE
Sometimes, Virtualbox won't detect the new machines on the virtual network interfaces in Windows. It might throw a weird error and stop the VM from booting. One solution could be:
Control Panel > Network and Internet > Network Connections and right-click on the Virtualbox Adapter connected to the host-only network. Select disable and then right-click again and enable it.
SERVER SETUP
The Server is bare-bones so we'll have to install git. SSH isn't installed either. Run these commands:
apt-get update
apt-get install ssh (we need this for pivoting later)
edit /etc/ssh/sshd_config (PermitRootLogin yes)
apt-get install git (or pull it off of your local machine via wget and python SimpleHttpServer).
apt-get install build-essential
The Makefile needs an edit in the VSFTPD directory you cloned in. Add -lcrypt to the LINK= section with your favorite text editor.
Continuing on...
make
The vsftpd binary should be in the folder. If not, something went wrong and run make again.
useradd nobody (probably already there, if not, run this command).
mkdir /usr/share/empty
usermod -d /usr/share/empty nobody
cp vsftpd /usr/local/sbin/vsftpd
cp vsftpd.8 /usr/local/man/man8
cp vsftpd.conf.5 /usr/local/man/man5
cp vsftpd.conf /etc
/usr/local/sbin/vsftpd &
Check out the PID and make sure it's listening on port 21. Or you can install nmap on the server and do a simple scan against the local host.
Now we enable the anonymous user:
mkdir /var/ftp/
useradd -d /var/ftp ftp
chown root:root /var/ftp
chmod og-w /var/ftp
Finally, allow local users by editing /etc/vsftpd.conf and uncommenting the option local_enable=YES and adding ftp_username=nobody.
You'll also want to sort out the network. Doing so is a simple process. Edit the /etc/network/interfaces file like so:
TROUBLESHOOTING VSFTPD 2.3.4
Try and rerun the make file. You might get some errors, but it still might work. Also, the nobody user seems to be included but has no home folder. You can alleviate this by running the usermod -d /<newhome>/<username> <username> command if you skipped it.
Optionally, you can add a quick script to /etc/init.d/ to start vsftpd every bootup. Otherwise you'll have to log in and start the service yourself. Don't forget the script headers!
Now, reboot the server and you should be in business. Let's find that inner network!
METHOD 1
Let's get to hackin'! The first method is easy-pease. Pull up msfconsole and run the command use exploit/unix/ftp/vsftpd/_234_backdoor. After you set the RHOSTS, you'll want to run the exploit in the background with the -j option.
We'll need to first upgrade our shell to a meterpreter:
use post/multi/manage/shell_to_meterpreter
Set the LHOST and the SESSION options and after you run the post module you should have a meterpreter shell on the first target.
From here we can enumerate all kinds of target information. With an ifconfig command we can see that the eth1 interface has the inner network address. We can use this information for our most automated approach, the deprecated autoroute script:
run autoroute -s 192.168.192.0/24
Another option is to use the bg option on the Meterpreter shell and use post/multi/manage/autoroute. Afterward it's possible to run a auxiliary/scanner/portscan/tcp or whatever you'd like.
IMPORTANT TAKEAWAY
As long as the meterpreter session is open you'll be able to route to the hidden network via the autoroute command. If you lose the meterpreter session you'll need to re-exploit the machine and rerun autoroute to re-enable the ability to pivot.
METHOD 2
Method 2 conveniently begins where we left off. Instead of searching with the Metasploit portscan module (which can be extremely slow), we can use it as a socks4 proxy and use nmap via proxychains to route the nmap scan through the Meterpreter session.
use auxiliary/server/socks4a
I like to use a different port number than 1080 in avoidance of conflict. In this case we'll use 1337. C'mon, it's a classic.
Meanwhile in another terminal window, we want to make sure to edit the /etc/proxychains.conf file to reflect the settings of the socks4a proxy server from Metasploit.
Proxychains has some limitations. It encapsulates TCP and UDP (layer 4 on the OSI model of networking), whereas nmap features that utilize ping use ICMP (layer 3 of the OSI network model). The gist is that proxychains doesn't support the ICMP protocol.
When scanning through a proxy server, you'll need some particular switches on nmap. Let's say that we already discovered that the new host was on 192.168.192.6. If we wanted to scan all its ports, I'd use:
proxychains nmap -n -sT -sV -Pn 192.168.192.6 -vv
TROUBLESHOOTING METHOD 2
Make sure proxychains is fully updated. Also, it may be necessary to edit the proxychains.conf file entries
tcp_read_time_out to 1200
and
tcp_connect_time_out to 800
But you may need to alter those values further. Your milage may vary.
METHOD 3
Here it is! My favorite. This is a manual method of pivoting using SSH tunneling and using that tunnel via proxychains to scan a different network. All you need for this method are SSH credentials. It doesn't even have to be the root user! But for our lab's purposes, we'll just use root.
I'll use the commands:
ssh root@10.0.2.62 -D 1337 -N -f
and
proxychains nmap -n -sT -sV -Pn -p- 192.168.192.6
The first command connects with the compromised machine as root@10.0.2.62, -D binds to the port 1337 of the attacking machine to port forward through root's ssh session on 10.0.2.62 and -f means I want the session to go into the background so I can use nmap through that tunnel via proxychains.
Now that we've checked out the services on the ports, we can set about exploiting them. Oh look, there's VSFTPD again! Let's exploit it manually!
All that's necessary to exploit the backdoor in VSFTPD 2.3.4. manually is to add a smiley face to the name.
After that, VSFTPD 2.3.4 starts listening on port 6200. Now that we've made it through, all we need to do is connect with nc via proxychains over to port 6200 and we're root on the inner vulnerable machine.
TROUBLESHOOTING METHOD 3
Again, it might be necessary to alter the values for tcp_read_time and tcp_connect_time in the proxychains.conf file.
Also, you might get a ton of timeout/connection refused errors on the nmap scan through this method, but I've found that it is possible to wait out that error. It's not a sure thing, but it might not be the end of the road. It just takes a little messing around and is dependent on the network you're pivoting on.
There you have it! Three methods for pivoting inside of internal networks you can use. May they serve you well!
PIVOT COMMANDS COVERED
use exploit/unix/ftp/vsftpd/_234_backdoor
use post/multi/manage/shell_to_meterpreter
run autoroute -s <target_IP_range>
use post/multi/manage/autoroute
use auxiliary/server/socks4a
ssh <username>@<foothold> -D <LPORT> -N -f
proxychains nmap -n -sT -sV -Pn -p- <targetIP>
REFERENCES
Lab Construction
An Explanation on the VSFTPD 2.3.4 Exploit
See You, Space Cowboy...
