stdapi not loading

[ihackstuff at gmail.com (j0hnny)]

On 5/15/07, jlbrown1980 <jlbrown1980 at comcast.net> wrote:
> I had this SAME exact problem and finally figured out why.  I was trying
> to use metasploit just on my local network, right, and test my desktop
> through attacking it with my laptop... anyways no matter what i tried on
> the desktop i could not get it to connect to the SRVPORT and the SRVHOST
> (for example http://192.168.1.1:8080/test), download the initial code
> and then redirect itself to the LHOST and LPORT (EX.
> http://192.168.1.1:4444).  It would just load about 8 or 9 components at
> the SRV location and then quit as soon as its done, without touching the
> LPORT.  Being bored in class today I SSH'd into my laptop from their
> school winxp comp on their on network, setup the exploit and ran it.

I will set up a sniffer on both LPORT and SRVPORT, but I don't think that's it.

> It ran PERFECT without a hitch!  My assumption is that you are having
> the same issue I was. In my case the problem is with the system being
> attacked.  It is most likely not vulnerable for whatever reason.  If it
> WAS vulnerable STDAPI extension would load automatically.

The target is definitely vulnerable. I'm using the same target,
exploitable from my "working" install, but STDAPI isn't loading on
this install. One other note: I have slightly different ruby versions
on the two machines (both installed via ports FWIW) 1.8.4 on working
machine, and 1.8.6 on non working machine. Let me reiterate that I had
this problem on my working machine, but somehow resolved it. I tried
copying ext_server*.dlls to data/meterpreter directory in an attempt
to "use" them, but I got the listed error, and besides... (run on
sentence here) on my working machine I don't have to "use" when I
exploit the same machine... meterpreter loads the fs and process dlls
automatically (presumably because it's in STDAPI now, right?)...

> So from that being said... the only difference which I had enough time
> to write down between my home PC and School PC is the Internet Explorer
> Version.  Is it possible that the ANI_LOADIMAGE_CHUNKSIZE vulnerability
> has been patched and fixed in IE7?  I'm pretty sure my home computer is
> SP2 not sure about the school comp, however next time I have class I
> will definitely take a look.

Target is SP2, IE6. Not sure about the status of the exploit on IE7.
Thanks for the email.. still desperately working through this. I'm
really down to the wire here, which is not to say metasploit is not a
WONDERFUL thing =)

> On Tue, 2007-05-15 at 14:11 -0400, j0hnny wrote:
> > I've seen a similar thread posted, but can't find a solution for this.
> >
> > I have a fully working very happy install of MSF 3 (on OSX) and I'm
> > doing a fresh install on another OS X machine, and for some odd reason
> > I can't get meterpreter's STDAPI loaded. I did SOMETHING to get it
> > working on my original install, but can't remember what it was.
> >
> > When I interact with meterpreter/reverse_tcp, I only get the core
> > commands loaded, none of the stdapi commands (process, fs, net,etc).
> >
> > Copying the modules from output/extensions/ and dropping them into
> > data/metasploit doesn't seem to work either.
> >
> > For example, copying over ext_server_process.dll and doing use process
> > yields this:
> >
> > Loading extension process...[-]
> > failure: The core_loadlib request failed with result: 1168.
> > ./lib/rex/post/meterpreter/client_core.rb:156:in `use'
> > ./lib/rex/post/meterpreter/ui/console/command_dispatcher/core.rb:249:in
> > `cmd_use'
> > ./lib/rex/post/meterpreter/ui/console/command_dispatcher/core.rb:237:in `each'
> > ./lib/rex/post/meterpreter/ui/console/command_dispatcher/core.rb:237:in
> > `cmd_use'
> > ./lib/rex/ui/text/dispatcher_shell.rb:230:in `send'
> > ./lib/rex/ui/text/dispatcher_shell.rb:230:in `run_command'
> > ./lib/rex/post/meterpreter/ui/console.rb:94:in `run_command'
> > ./lib/rex/ui/text/dispatcher_shell.rb:196:in `run_single'
> > ./lib/rex/ui/text/dispatcher_shell.rb:191:in `each'
> > ./lib/rex/ui/text/dispatcher_shell.rb:191:in `run_single'
> > ./lib/rex/post/meterpreter/ui/console.rb:60:in `interact'
> > ./lib/rex/ui/text/shell.rb:121:in `call'
> > ./lib/rex/ui/text/shell.rb:121:in `run'
> > ./lib/rex/post/meterpreter/ui/console.rb:58:in `interact'
> > ./lib/msf/base/sessions/meterpreter.rb:170:in `_interact'
> > ./lib/rex/ui/interactive.rb:48:in `interact'
> > ./lib/msf/ui/console/command_dispatcher/core.rb:671:in `cmd_sessions'
> > ./lib/rex/ui/text/dispatcher_shell.rb:230:in `send'
> > ./lib/rex/ui/text/dispatcher_shell.rb:230:in `run_command'
> > ./lib/rex/ui/text/dispatcher_shell.rb:196:in `run_single'
> > ./lib/rex/ui/text/dispatcher_shell.rb:191:in `each'
> > ./lib/rex/ui/text/dispatcher_shell.rb:191:in `run_single'
> > ./lib/rex/ui/text/shell.rb:125:in `run'
> > ./msfconsole:77
> >
> > Any advice? My sad meterpreter help looks like this:
> >
> > meterpreter > help
> >
> > Core Commands
> > =============
> >
> >     Command       Description
> >     -------       -----------
> >     ?             Help menu
> >     channel       Displays information about active channels
> >     close         Closes a channel
> >     exit          Terminate the meterpreter session
> >     help          Help menu
> >     interact      Interacts with a channel
> >     irb           Drop into irb scripting mode
> >     migrate       Migrate the server to another process
> >     quit          Terminate the meterpreter session
> >     read          Reads data from a channel
> >     run           Executes a meterpreter script
> >     use           Load a one or more meterpreter extensions
> >     write         Writes data to a channel
> >
> > Very frustrating, as I fixed this once.. =/
> >
> > thanks!
> > Johnny