Tag: SSH Tunnelling

Posted on

Networking Pivoting via SSH – Scanning with Nessus Professional behind a Firewall or NAT.

In this post I’m going to be covering the process to scan a network behind a Firewall or NAT using Networking Pivoting via SSH without being limited to proxychains, specific ports and protocols. Essentially this will use SSH tunneling, virtual tap adapters, some routing and masquarding in IPtables. The beauty of this method is the prerequisites are very low, for the most part no additional packages or standalone tools are required, we can use what is shipped with most Linux builds.

There are many use cases for this, scanning an internal network without being on prem, cloud environments, various pentesting scenarios, which can often be the stumbling point once a shell has been landed. Traditionally this type of task would have been done with the use of proxy chains, through some form of shell access via a netcat listener, Metasploit or SSH dynamic port forward, which I have previous walked through here. However this is an extremely slow method and rely’s on being able to tunnel through a single port with proxy chains, I have never had any luck scanning with more complex tools like Nessus in this way. Full SYN scans (-sT) with nmap great, Nessus not so much.

Lets take the following scenario and set the pivot up:

Networking Pivoting via SSH

We can use tunctl or ip tuntap, the difference being that ip tuntap is part of the iptools suite and therefore general supported on most Linux operating systems. Tunctl can usually be downloaded from your repo of choice ie with Ubuntu its part of the apt repository. In this example we will be working with Kali as the scanning system and a Ubuntu server as the pivot point, which has SSH accessible. (It is worth mentioning at this point it doesn’t matter which end the SSH connection is initiated from).

First we need to create a virtual tunnel and therefore need to create two virtual interfaces at both ends of the tunnel. For this we are going to use a tap interface. For reference a tap interface operates at layer 2 and a tun interface operates at layer 3.

Using tunctl: First we will need to install tunctl with apt install uml-utilities

# apt install uml-utilities

Create the virtual tap interface with the following command:

# tunctl -t tap0

Using ip tuntap: First verify your ip tools version installed supports tuntap, type ‘ip’ you will see if the command is available:

# ip

Create the virtual tap interface with the following command:

# ip tuntap add dev tap0 mod tap

Once this is setup assign it an ip address and raise the interface, assign a different address for each end of the tunnel:

So on the scanner:

# ip a a 10.100.100.100/24 dev tap0 && ip link set tap0 up

On the pivot server:

# ip a a 10.100.100.101/24 dev tap0 && ip link set tap0 up

On each end of the tunnel we will also need to make sure our SSH config will allow us to tunnel. Lets modify our /etc/ssh/sshd_config file by adding ‘ PermitTunnel=yes ‘ to the end and restart the service. More about this option can be found in SSH man page here.

Now for the magic, lets bring the tunnel up by establishing an SSH session, this will need to be done with a privileged account:

ssh -o Tunnel=ethernet -w 0:0 root@11.1.1.11

Lets cover off these options:

  • -o = allows us to specify options
  • Tunnel=ethernet = is our option for the tunnel
  • -w 0:0 = specifies the next available interface for the tunnel, and corresponds to each side of the tunnel.

Next lets take a moment to verify our tunnel is up with a couple of quick checks:

First verify the link is up with ethtool:

# ethtool tap0

You will notice the link is up, try this without the connection you will find the link is down.

Second verify you can ping the other end of the tunnel:

# ping 10.100.100.101

Again disconnect your SSH connection and watch icmp response drop.

Next in order to get our traffic to our destination servers/subnet we are going to need some routes adding to Kali to tell the system where to send the traffic, ie the other end of the tunnel, so, something similar to this where 192.168.1.0/24 being the network you are targeting:

# ip route add 192.168.1.0/24 via 10.100.100.101

# ip route add 192.168.2.0/24 via 10.100.100.101

Finally we need to setup some iptables rules and turn our pivot point into a router by enabling IPv4 forwarding:

# echo 1 > /proc/sys/net/ipv4/ip_forward

# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

# iptables -t nat -A POSTROUTING -o tap0 -j MASQUERADE

# iptables -A INPUT -i eth0 -m state –state RELATED,ESTABLISHED -j ACCEPT

# iptables -A INPUT -i tap0 -m state –state RELATED,ESTABLISHED -j ACCEPT

# iptables -A FORWARD -j ACCEPT

At this point the pivot should be up and running, test this by doing some basic checks with a known host on your target network.

Happy pivoting testers!

Posted on

Tunnel snmp-check and other UDP traffic over SSH

Today I will be walking you through how to tunnel snmp-check and other UDP traffic over SSH.

In this example we are tunnelling UDP over SSH to circumvent firewall rules on the outside. Our firewall rules are only allowing access into the other side of the firewall to TCP port 22 on a Ubuntu server. We don’t have access to any other TCP or UDP ports. The only method of communication into the environment is via SSH to our Ubuntu server. We will use this server as jump/pivot point for other traffic. Imagine we have earlier identified through cdpsnarf using SSH dynamic port forwarding and proxychains another router, we want to enumerate this further. Our next goal in this case is to try and enumerate SNMP UDP port 161 on target router with a public community string. This example could also be applied to all sorts of UDP traffic such as DNS for example were we want to tunnel our local DNS requests to a server behind a firewall. Zone transfer maybe?tunnel snmp-check and other UDP over SSH

Attack machine: Kali Linux 192.168.200.2
Pivot Server: Ubuntu 192.168.100.10
Target: GNS3 Cisco Router 192.168.100.100

We are going to do this by sending our local UDP traffic through netcat (handling UDP) into a fifo process back into netcat (handling TCP), through the ssh tunnel then in reverse the other end. Yes I know bit of a brain teaser! You can read more about fifo files here, they are similar to pipe in linux. In essence we are sort of writing the output to a file (without actually writing anything) then sending it on its merry way through netcat via TCP then down the tunnel. Its best we see this in the flesh with an example.

We begin on the Attack machine by running up the ssh connection, here we are forwarding TCP port 6666 on localhost to TCP 6666 on the remote pivot server:

root@kali:~# ssh -L 6666:localhost:6666 user@192.168.100.10

Then on the Pivot Server we create a fifo file for netcat to talk too:

root@ubuntu:/home/user# mkfifo /tmp/fifo
root@ubuntu:/home/user# nc -l -p 6666 < /tmp/fifo | nc -u 192.168.100.100 161 > /tmp/fifo

On the Attack machine we do similar:

root@kali:~# mkfifo /tmp/fifo
root@kali:~# nc -l -u -p 161 < /tmp/fifo | nc localhost 6666 > /tmp/fifo

In second terminal on the attack machine:

Run up ‘netstat -au’ to verify snmp is listening on the local machine.

UDP netstat connections

We can then simple run snmp-check to localhost.

snmp-check 127.0.0.1

snmp-check over SSH

 

Looking further down the information we discover the following:
snmp-check over SSH another netowrk

 

Another network interface, is this possibly the internal network and route to DA..? Maybe in the next post…

Bingo UDP and snmp-check over an SSH tunnel, awesome!