I am sure that many penetration testers among our readers try to minimize their travel. While many years ago we had to be physically present for internal penetration tests, today it is very common that client organizations setup virtual machines for penetration testers, which are then used to perform internal penetration tests. I was recently performing an internal penetration test where the only VM I had was a Kali Linux VM, with SSH to it. Tunneling network traffic through the VM seems like an obvious choice, however this not all that trivial since the scanner generally needs raw access to sockets. So this diary describes one solution I came up with – let us know if you have another solution for this problem. The diagram below shows our target devices. We will want to establish an SSH connection from the vulnerability scanner server to the Kali Linux VM, and use that connection to scan the target network. SSH has extremely powerful tunneling capabilities (actually, so powerful that it is a bit scary). We will use SSH’s Tunnel option to tunnel traffic between two TUN TAP interfaces. These are virtual devices that behave as real interfaces so our scanner will not know the difference. First we need to create such devices on both sides with the following command: # tunctl -t tap0 Now we can assign an IP address to this interface. On the scanner server: # ifconfig tap0 10.100.100.100 netmask 255.255.255.0 And on the Kali Linux VM: # ifconfig tap0 10.100.100.101 netmask 255.255.255.0 We will link those devices with an SSH tunnel. Now, in order to do that we need to be root on both sides so I created an SSH key that I copied on the Kali Linux VM: # ssh-keygen This allows us to login without specifying a password. Additionally, the target SSH server must allow tunneling – this can be done by adding the following line into /etc/ssh/sshd_config on the Kali Linux VM: PermitTunnel=yes And we are now ready – we can simply login from the scanner server to the Kali Linux VM with the following ssh command: # ssh -o Tunnel=ethernet -f -w 0:0 root@kali.linux true This will establish a tunnel and execute the “true” command (which does nothing), and send the process into background. # ethtool tap0 Nice, our link is up. We can confirm that by pinging the remote tap0 interface: # ping -c 3 10.100.100.101 --- 10.100.100.101 ping statistics --- We’re not done yet though. We need to now configure our scanner server to send data for the target network (10.10.0.0/8 above) through that tunnel. While there are more and less complex ways to do that, I opted to simply enable forwarding on the Kali Linux server with NAT (masquerading) and setup a route to the target network. On the Kali Linux VM: # echo 1 > /proc/sys/net/ipv4/ip_forward On the scanner server: # ip route add 10.10.0.0/8 via 10.100.100.101 And we’re done – let’s test it by scanning a server in the target network: # nmap -sT -Pn 10.10.1.37 Starting Nmap 7.01 ( https://nmap.org ) at 2018-11-05 21:48 CET Nmap done: 1 IP address (1 host up) scanned in 2.26 seconds There we go – our tunnel is up and happily moving data between our networks. No more battling with proxychains! We can now simply start a scan as we would normally do and SSH will do the job for us. |
Bojan 396 Posts ISC Handler Nov 7th 2018 |
Thread locked Subscribe |
Nov 7th 2018 2 years ago |
Could it also be a solution to set up a VPN server (e.g. openvpn) on the Kali Linux and to make a VPN connection from your scanner to the Kali Linux?
What would be the advantage of an SSH tunnel versus a VPN tunnel? |
Lode 5 Posts |
Quote |
Nov 7th 2018 2 years ago |
Indeed, setting up OpenVPN is another solution - in my case, the only traffic that was allowed to the target Kali Linux VM was SSH, so I decided to go that route.
Thanks for the comment! |
Bojan 396 Posts ISC Handler |
Quote |
Nov 7th 2018 2 years ago |
On a semi-related note, tunneling is a great method to run command and control from the outside to the inside or to exfiltrate data. I've seen as much as 3 M/bps capacity when DNS tunneling was used. With DNS tunneling the data is encoded into either DNS TXT records where each DNS packet has a corresponding encoded data packet. When the query hits an Internet DNS server that's also running the tunneling software it gets decoded and turned back into the original data packet. A second method uses long random subdomains encoded as data. Both methods usually are able to "hide in the noise" of normal network traffic levels.
If your IPS or firewall has protections against DNS and SSH tunneling be sure to enable it. If you have Check Point firewalls and IPS, their tunneling protections were never successfully bypassed by pen testers in over a decade of my experience and it detected them every time with zero false positives. |
Anonymous |
Quote |
Nov 7th 2018 2 years ago |
Sign Up for Free or Log In to start participating in the conversation!