Proxies, Pivots, and Tunnels

Forward

When talking about a proxy or a pivot or a tunnel, we could be talking about very different things. However, to me, these terms could mean the same thing too. A proxy could be considered a pivot, especially in ‘forward proxy’ mode, when it may be a corporate client’s only way to the internet from the internal network. Essentially making all your requests ‘pivot’ (or proxy ) through a specific device to access that external resource. A proxy can also provide a ‘tunnel’ to a remote resource by encapsulating traffic in some form of transmission protocol, that may even enforce encryption like HTTPS.

Why do we (okay, me early on in my career) only think of IPSEC or VPNs when tunnels come to mind? Is it because they operate at the TCP or Network Layer of the OSI ‘model’ and TLS/SSH operates at a level above the network layer? If you think of Tor as a way to ‘tunnel’ your traffic through a secure virtual medium, well that uses TLS as the encryption transport, not IPSEC. Also, many VPN solutions today support TLS as a primary or fallback transport mechanism and depending on the negotiated TLS cipher suite used for the connection, it is able to provide the same protections as an IPSEC tunnel, if not better. Furthermore, WireGuard uses a UDP socket, as opposed to TCP for the tunnel. We can get an idea of where these protocols line up on the OSI model from the mapping table found below. Caveat, this is just a model and is not meant to be ground truth. Rather, I use it as a way to communicate troubleshooting steps to determine where on the ‘stack’ a problem resides or to understand a solution to know what kind of controls can be put in place to harden a service from the physical layer up.

Image obtained from here.

I only bring this up to explain the title and how I interpret these terms (maybe even incite a good discussion/debate over it). However, this has little to do with this article overall. Okay, so what is this all about?

Well, this article is not going to go and debate how these terms (proxy, pivot, and tunnel) are alike or differ, instead I want to show you some tips and tricks when making your way around a network for ethical penetration testing purposes, general IT use, troubleshooting services in a segmented network, or just curious about how SSH tunneling works. The goal here is to provide a HowTo, as well as a way to build your own local environment for the purpose of understanding and practicing these networking concepts. First, let’s get some terms knocked out so that we are on the same page.

Definitions

Proxy – Service that is able to act as an intermediary between a client’s requests to and responses from a server. In this article we will be using SOCKS via SSH and Burp as our proxy applications.

Forward Proxy – Service that is used to be placed in front of client requests sent to (forward) a server. These services are generally used to filter outbound web traffic or even anonymize users and when you hear proxy, this is what most people are talking about.

Port Forwarding – This is the behavior when you take a port from one system and ‘tunnel’ or forward that port to another system, essentially making that service appear to be binded to that local or remote socket. This is explained with pictures and in further detail below, since this is even hard for me to grasp at times.

SOCKS – Stands for Socket Secure, and is a type of proxy that operates lower than the application layer (of the OSI or TCP/IP model) and does not modify any of those headers while tunneling packets. SOCKS4 and SOCKS5 (a more secure version, with auth) are the two versions you will most likely see.

Burp – Web application assessment tool of choice that can intercept and proxy your traffic in order to observe, modify, or repeat attacks against that service.

Now that those terms are laid out, I want to provide a local setup where you can try these out yourselves to get comfortable with so that when you need to do them in the real world, it feels a little more natural and something you can understand.

Test Network

Caveats

Depending on the operating system (Windows, Mac, or Linux) and how the application supports a proxy could require additional steps or measures to make this work, other than the steps stated in this article. Everything done in this article was conducted on an Ubuntu 19.10 host OS with Oracle VirtualBox for all the pivoting and routing examples. The Pivot Machine is a base Kali image and the Segmented Server is a SamuraiWTF machine. Luckily, if you are using Windows and VirtualBox, then this setup should work for you as well, however your mileage may vary. Finally, this post assumes that you know how to configure each of the VMs for use, outside of the networking bits mentioned below.

Environment Setup

The goal for this test environment is to be able to walk through a couple of scenarios that you may come across in your IT travels. The high level gist is that you have access to a machine on a seperate subnet than your own and then that machine is the pivot to the secure or controlled subnet. Below is an oversimplification of what we are going to mock up in our testing environment.

Going forward the local subnet is the main network on the VM Host machine, or the IP address assigned from the network your machine is attached to

VirtualBox Networking

Virtualbox has many networking modes that it supports. First, we need to configure the NAT Network to match the pivot ranges used in this post or to one of your choosing. With VirtualBox open, go to File -> Preferences -> Network. Once there, you may see a NAT Network listed. If one is listed there, choose the configure option on the right, which looks like this, and take note of the network settings or change it. Otherwise, if it is not there, choose to create a new network by pressing this button . With that dialog box open, it should look something like the image below once configured.

To properly mimic this limited access architecture we are going to configure two network interfaces on the Kali pivot machine and just one network interface for our Secure server. The Kali instance will have 1 Host-only Adapter and 1 Internal Network adapter, which is setup in the guest VM’s Network settings area. Here is a screenshot of each setting for the pivot machine, shown respectively below.

Now configure one interface on the Secure server and attach it to the Internal Network. Make sure the Name matches what was set on the Kali guest’s internal network settings shown above.

Once VirtualBox VM Guest network adapters are set, power up your guest VMs and log-in. First, let’s configure the Kali machine’s network interfaces in order to pivot to that secure network. The following command is configuring eth0 to use an IP address in the subnet configured in VirtualBox for the subnet we configured, in this case the 192.168.56.0/24 network or pivot network. In this case, we are setting the interface to the 192.168.56.100 IP address.

#ip addr replace 192.168.56.100/24 dev eth0

This next command sets up the internal network interface that will be attached to the Secure Subnet Network adaptor and used to access the SamuraiWTF server.

#ip addr replace 10.10.10.100/24 dev eth1

Once Kali is configured, login to the Secure server, and run this command to set its IP address.

#ip addr replace 10.10.10.200/24 dev eth0

Once both VMs are set up, check the following connectivity using ping; from the VM Host to the Kali machine, then the Kali machine to the SamuraiWTF Machine. From your VM Host, run the folloing to test connectivity from VM Host to your Kali machine:

$ping -c 4 192.168.56.100

Now test from the Kali machine to the SamuraiWTF VM Guest:

$ping -c 4 10.10.10.200

Now to configure SSH on your Pivot host to use a regular user account to SSH with, as opposed to root since the default sshd_config does not allow root to use password authentication and setting up SSH keys would be the best way forward to accomplish that (as opposed to setting the SSH service to allow root login with only password). Adding your SSH keys to a user account on Linux is out of the scope for this HowTo, but more information can be found in this Digital Ocean article. If not going the SSH keys route, then add a standard user by running the following commands:

#useradd -d /home/ -G sudo -s /bin/bash user
#passwd user

Once you have added that user account, check the status of the SSH service and if not running, use the following command to start it.

#/etc/init.d/ssh status
#/etc/init.d/ssh start

Now SSH to your pivot machine to make sure that is all setup.

$ssh user@192.168.56.100

Troubleshooting

If all is working, then awesome! If not, then the first thing to do is to validate that the network subnets and configured IP addresses match what you expect it to on the host and the guest VMs. On the VM Host, this would just appear as another interface called vboxnet0 if using VirtualBox. You can run ip addr (Linux) or ipconfig /all (Windows) on your VM Host (not the Guest) to see if you have vboxnet attached to your host and to see if the network subnet is correct. The following command should show something similar when you run it on your VM Host.

$ip addr show dev vboxnet0

Another validation is to make sure the IP addresses are set on the proper interfaces on your Kali and SamuraiWTF VMs using the same command above. After validating the expected IP addresses are set on the VM Guests, then validate that on those interfaces, you have a valid route set. On the Kali pivot VM you can validate that the route is set for both networks, 192.168.56.0/24 and 10.10.10.0/24, and configured on the appropriate interface as shown below.

If SSH fails, add -vvvv to your SSH command to get verbose message output to determine if there is something wrong with the negotiated encryption or refusing your authentication method. You can also check the status of the SSH daemon on the pivot machine with this command.

#/etc/init.d/ssh status

Another helpful command to run on the Kali machine is tcpdump. This next command is filtering for any kind of SSH connection attempts (port 22) to the Pivot machine.

#tcpdump -nnvv -i eth0 port 22

Use Case 1 – Access Remote Subnet

More and more corporations are segmenting the systems that operate on their internal network, for many good reasons. This tightened security posture, almost without fail, makes it harder for sysadmins (or even pentesters) to do their job. One way to obtain access to that remote network is to utilize an SSH tunnel to ‘forward’ our requests through that established connection to that segmented service using a SOCKS proxy tunnel. SOCKS proxy is actually built into SSH and is better than Squid, when it comes to supporting other protocols, like SMTP and FTP, since it operates at a lower layer on the network stack than HTTP. Also, since SOCKS doesn’t understand anything about HTTP or any of its nuances, it makes it a perfect proxy for maliciously crafted traffic that may not adhere to the RFC, and is therefore denied by Squid since it does not comply with standard HTTP traffic.

First, run the following command to establish the SOCKS connection to your Pivot machine.

$ssh -D 36363 user@192.168.56.100

After successful completion of the command above, either using Burp or a web browser’s proxy configuration, set it to use your localhost address, 127.0.0.1, and port 36363. Once those are set, you should be able to browse to the SamuraiWTF web services, by browsing to one of the endpoints, like DVWA. In this case that URL would look like this and from your proxied browser connection should render on the VM Host:

http://10.10.10.200:31000

Use Case 2 – Bypass Local Network Controls

In this use case, you are able to get to the Pivot machine via SSH, however that Pivot machine has very limited internet access. This is helpful if you need to update a machine in a remote subnet with no internet access. This use case requires another tool called proxychains and is installed by default in Kali. However there is one configuration change to make in the /etc/proxychains.conf file. Add the following line and comment out (add a ‘#’ at the beginning of the line) with socks4 in it. This is generally the last line in the config file:

#socks4 	127.0.0.1 9050
socks5          127.0.0.1 36363

Once that is set on the Pivot machine, you can establish this remote forwarded port via the following command:

$ssh -R 36363 user@192.168.56.100

By passing the -R flag and just a single port identifier, you are making a SOCKS proxy out of that forwarded connection that binds to the remote host’s port, 36363. On the pivot host, run the following command.

$sudo proxychains apt update

With the help of proxychains, your Pivot host should be using the SSH tunnel to obtain system updates instead of the default outgoing route, or lack thereof. You can use just about any command that is TCP based currently through proxychains.

Use Case 3 – Listen Locally to a Remote Port

Sometimes you may find yourself wanting to run a tool or command against a service in a remote subnet, and the Pivot host does not have the tool or installing it may be more effort than it’s worth. In this use case, we will take a remote port from the Kali server and bind it to a local port on our host. This essentially uses the SSH connection to the Pivot server as the middleman to send packets to a remote port on a host. This command will forward requests from localhost:31001 to 10.10.10.200:3100, using your Pivot VM to get there.

$ssh -L 31001:10.10.10.200:31000 user@192.168.56.100

Once established, you can bring up your browser and go to the following URL:

http://localhost:31001/setup.php

Conclusion

There are a lot of ways around a network using just SSH. This hopefully helped you to understand how powerful just opening one port on a server can be and the potential risks(or fun) in doing so. I am not saying don’t use SSH, since you can configure the SSH service daemon to deny any forwarded connections to harden your pivot machine by setting the directive AllowTcpForwarding to no in your sshd_config, but to be aware of the dangers of a default configuration. Regardless, I hope you learned something and this proves helpful for that time when you have trouble getting around a network, and all you have is SSH access to the subnet where that machine resides.

If you are looking for more information that covers a variety of technology topics, we have a Professionally Evil Fundamentals (PEF) channel you can subscribe to. We also answer general basic questions in our Knowledge Center. Finally, if you’re looking for a penetration test, professional training for your organization, or just have general security questions please Contact Us.

Proxies, Pivots, and Tunnels - Oh My!