Activity 3.1 Single Port Tunneling

In some cases, for some reason, you cannot communicate directly with a service that is running on a target. This can occur when

• The service is bound to an interface you cannot communicate with (like 127.0.0.1)

• The service is inaccessible due to firewalls (firewalld) or other filtering devices (a vyos or pfsense firewall). It is possible that you have access to another target that can access the intended victim.

• You just don't happen to have access to msfconsole or some of the kali built in tunneling and proxy tools.

Scenario 1, the Forward Tunnel

Our first scenario involves a target-based web server listening only to localhost.We do have SSH access as a limited user to that host but cannot browse directly to the vulnerable web service. We will use an SSH forward tunnel to make this happen.

SSH to Partner Web Server

This is a partner lab as one partner needs to run a Python web server and install a firewall to block the other partner from browsing the server. The partner not running the web server will then create a reverse shell to evade the firewall and access the partner's web server.

Partner 1: Set up web server, install firewall and add user

Start web server:

My partner used an Nginx server instead of a python server

apt install -y nginx
systemctl enable --now nginx

Install and configure firewall:

Firewall configuration that blocks access on port 80 (to the web server) but allows access on port 22 (SSH)

/sudo apt install -y ufw 
ufw allow 22
ufw deny 80 
ufw status

Set up web server in var/www/html

Add user:

/adduser hanne

Partner 2:

SSH as the user that partner 1 set up on their machine (using their ip address). It should work!

ssh hanne@10.0.17.75 
//Your partner will have to give you the password 

Now try to access the web server, and it should time out!

Forward Tunnel

Partner 2:

We are going to port forward the web server using SSH from port 80 to port 9111. This will allow us to access the server. on our local machine and using a new port.

Accessing partner 1's website on partner 2's machine (using both the web browser and curl)

Scenario 2: The Reverse Tunnel

We are now going to SSH to our partner again and create a reverse shell back to our machine. The point of this scenario is to demonstrate how we can make a reverse shell back to our host machine once we have a foothold on our target. We are using SSH here, but we may not always have access to SSH and would rather be exploiting vulnerability to gain access to the target.

Partner 1 IP: 10.0.17.75

Partner 2: IP: 10.0.17.83

• Step 1: Create a netcat listener.

• Step 2: SSH to partner's IP address

• Step 3: invoke a bash reverse shell.

• Step 4: You should have access to your partner's box with your reverse shell!

Creating a throwaway user

We are going to make a throwaway user on our host machine that we will be connecting our reverse shell back to. We are doing this because this user will NOT be a sudoer and will have fewer permissions. This is more realistic in an actual pen testing environment, because you won't always be accessing systems as a sudoer by default.

sudo su 
useradd -m -s /usr/bin/bash throwaway
//make user password 
passwd throwaway

Create a keypair on the target

mkdir throwaway 
cd throwaway 
ssh-keygen -N "" -C throwaway -f throwaway  

Transfer the public to the throwaway user's authorized_keys file.

// su throwaway 
cd ~ 
mkdir .ssh 
cd .ssh
nano authorized_keys 
cat authoirzed_keys
pwd 
chmod 700 . 
chmod 600 authoized_keys

Start sshd on Kali.

Make sure to turn it off once the exercise is done!

Connect to kali from the target with the following syntax:

ssh -o StrictHostKeyChecking=no -T -T 7000:localhost:80 throwaway@10.0.17.83 -i throwaway

Curl to the localhost IP address with your new port, and you will see you can access the target web server!