portfwd bug - Won't bind to local address

[huperdefigo at gmail.com (Mark Baggett)]

THANK YOU!  The portfwd information is extremely helpful.  It is
amazing how much better tools work when you use them properly.

Your right.  In the fictitious scenario I described on my blog I could
just use the bind payloads to access Victim2.  I have an ulterior
motive for focusing on reverse payloads.   I've been unable to pivot
twice (through Victim1 to Victim2 and exploit Victim3)  when using
bind payloads.  My thought is that if I use reverse payloads through a
tcp relay then both meterpreter sessions will appear as "original"
non-tunneled meterpreter sessions.   Then I should be able to ROUTE
through the relayed Victim2 and pivot to a third host.    I think I
should be able to get that to work with the portfwd information you
provided.

Thanks again,
Mark Baggett

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
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: http://getfiregpg.org
>
> iEYEARECAAYFAkmP2J8ACgkQABHabZqEWJ3ALwCeN6xIwK2sGBtD2/GgW6PsvOGV
> W5gAni1zt2jzB+nsCp6TNQFCQm8J8Ir8
> =M3iT
> -----END PGP SIGNATURE-----
>
> On Sun, Feb 8, 2009 at 7:11 PM, Carlos Perez
> <carlos_perez at darkoperator.com> wrote:
> > Natron and I tried for several days to get it to work for RDP but all
> > attempts failed, for light stuff it was working but as soon and we
> > pushed more traffic it failed, I believe there is a ticket open for
> > fixing the portfwd and for re-writing a lot of stuff from meterpreter.
> >
> > Cheers,
> > Carlos
> >
> > On Sun, 2009-02-08 at 19:41 -0500, Mark Baggett wrote:
> > > Is there a bug in portfwd that prevents it from binding to the local
> > > meterpreter address?  I have tried this on both a vanilla Windows 2000
> > > and a Windows XP SP2 host running meterpreter and I get the same
> > > results.   Am I doing something wrong or is this a bug?
> > >
> > > 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 "Can't 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
> > >
> > >
> > > Here is more detail on what I am trying to do.
> > > http://www.indepthdefense.com/2009/02/reverse-pivots-with-metasploit-how-not.html
> > >
> > > Thanks,
> > > Mark Baggett
> > > _______________________________________________
> > > http://spool.metasploit.com/mailman/listinfo/framework
> >
> > _______________________________________________
> > http://spool.metasploit.com/mailman/listinfo/framework