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.
In most cases this will boil down to two VMs: one with Kali Linux and the other one with your favorite scanner. However, it is also quite common that only one VM is provided and that one is used to tunnel traffic through (or pivot through it).

I was recently performing an internal penetration test where the only VM I had was a Kali Linux VM, with SSH to it.
Depending on the target environment, one can manually perform a penetration test, but since I was dealing with a larger number of machines in the scope, I wanted to run a vulnerability scanner. However, the only VM I had was the Kali Linux VM and an SSH connection.

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 
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /root/.ssh/id_rsa.
Your public key has been saved in /root/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:IhndAn301XGp4TkWgS1s/QyEJdmo4fh6vhR/nmmLElw root@server.local
The key's randomart image is:
+---[RSA 2048]----+
|    .. .. ..%=o.o|
|     o...o X.B.o |
|    . o.+ = o O  |
|     o o o E * o |
|    o . S.. . .  |
|     . . +o      |
|        .... .   |
|       ..o  +.o  |
|        ooo..=.  |
+----[SHA256]-----+

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.
The tunnel should be up now, we can check that with the ethtool command:

# ethtool tap0
Settings for tap0:
        Supported ports: [ ]
        Supported link modes:   Not reported
        Supported pause frame use: No
        Supports auto-negotiation: No
        Advertised link modes:  Not reported
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Speed: 10Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: off
        MDI-X: Unknown
        Current message level: 0xffffffa1 (-95)
                               drv ifup tx_err tx_queued intr tx_done rx_status pktdata hw wol 0xffff8000
        Link detected: yes

Nice, our link is up. We can confirm that by pinging the remote tap0 interface:

# ping -c 3 10.100.100.101
PING 10.100.100.101 (10.100.100.101) 56(84) bytes of data.
64 bytes from 10.100.100.101: icmp_seq=1 ttl=64 time=0.028 ms
64 bytes from 10.100.100.101: icmp_seq=2 ttl=64 time=0.033 ms
64 bytes from 10.100.100.101: icmp_seq=3 ttl=64 time=0.031 ms

--- 10.100.100.101 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 1999ms
rtt min/avg/max/mdev = 0.028/0.030/0.033/0.006 ms

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
# 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

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 scan report for 10.10.1.37
Host is up (0.022s latency).
Not shown: 988 closed ports
PORT     STATE SERVICE
22/tcp   open  ssh
53/tcp   open  domain
80/tcp   open  http
88/tcp   open  kerberos-sec
389/tcp  open  ldap
443/tcp  open  https
464/tcp  open  kpasswd5
636/tcp  open  ldapssl
749/tcp  open  kerberos-adm
8080/tcp open  http-proxy
8089/tcp open  unknown
8443/tcp open  https-alt

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.
Before ending this diary, let me mention another interesting tool: sshuttle (https://github.com/sshuttle/sshuttle). In many cases you can use this tool as well, its benefit is that it does not require root privilege on the target server. I had some issues running a scanner with sshuttle so YMMV.
 

-- Bojan
@bojanz
INFIGO IS