9: Metasploit Auxiliary Modules

Bydefinition, a Metasploit module that is not an exploit is an auxiliary module,
which leaves a lot to the imagination.
In addition to providing valuable reconnaissance tools such as port
scanners and service fingerprinters, auxiliary modules such as ssh_logincan
take a known list of usernames and passwords and then attempt to log in
via brute force across an entire target network. Also included in the auxiliary
modules are various protocol fuzzers such as ftp_pre_post, http_get_uri_long,
smtp_fuzzer, ssh_version_corrupt, and more. You can launch these fuzzers at a
target service in hopes of finding your own vulnerabilities to exploit.

Should you want to create your own
module or edit an existing one to suit a specific purpose, you will find them
in their corresponding directories. For instance, if you need to develop a
fuzzer module to hunt your own bugs, you will find some pre-existing mod-ules in the /fuzzersdirectory.

Anatomy of an Auxiliary Module
Let’s look at the makeup of an auxiliary module in a fun little example not
currently in the Metasploit repository (because it does not pertain to pene-tration testing). This example will demonstrate how easy it is to offload a
great deal of programming to the Framework, allowing us to focus on the
specifics of a module.

Chris Gates wrote an auxiliary modulefor the Framework that gave his
Twitter followers the impression that hehad somehow invented a device that
allowed him to travel at the speed of light. It makes a great example of the
code reuse available in Metasploit. (You can access the source of the script at
http://carnal0wnage.googlecode.com/.)

root@bt:/opt/framework3/msf3# cd modules/auxiliary/admin/
root@bt:/opt/framework3/msf3/modules/auxiliary/admin# wget http://carnal0wnage.googlecode
.com/svn/trunk/msf3/modules/auxiliary/admin/random/foursquare.rb

We’ve placed the module inour auxiliary directory Xso that it will be
available for use by Metasploit. But before we use this module, let’s look at
the actual script and break down the components so we can see exactly
what the module contains.

The module begins with the first two lines importing the auxiliary class X.
Next it makes the HTTP client functions available for use Ywithin the script.

Within the initialization constructor Xwe define much of the informa-tion Ythat is reported back when issuing the infocommand in msfconsole.
We can see where the various options are defined Zand whether they are
required. So far, all are pretty direct and their purposes are clear. Still, we
have yet to see any actual logic being performed. That comes next.

Now we reach the actual logic ofthe script—what happens when runis
called within the module. Initially the provided options are set to local vari-able names Xalong with defining various other objects. An object is then
created by calling the send_request_cgimethod Yimported into the script
from lib/msf/core/exploit/http.rband defined as “Connects to the server, cre-ates a request, sends the request, reads the response.” This method takes var-ious parameters that make up the callto the actual server, as shown here.

After this object is created, the results are printed X. If anything goes
wrong, logic exists for catching any errors Yand reporting them to the user.
All of this logic is simple and is just a matter of plugging various parameters
into existing functions of the Framework. This is a great example of the
power of the Framework, because it allows us to concentrate only on the
information needed to address our goal. There is no reason to reproduce
any of the standard functions such as error handling, connection manage-ment, and so on.
Let’s see this module in action. If you don’t remember the full path to
the module within the Metasploit directory structure, search for it like so.

In order to run this module successfully, we need a valid set of Four-square credentials to do the check-in. We first define the VenueID that we
find online with a bit of Googling X, and then we set our Foursquare creden-tials Yand run the module. We get a successful result with the Foursquare
service confirming our check-in and giving us five points Z.
In this case, we have submitted a request to “check in” at Union Station
in Washington, DC, on the Foursquare service (see Figure 9-1).

Going Forward
As you have seen, auxiliary modules can have a wide range of uses. The infra-structure provided by the MetasploitFramework can produce a wide array
of tools in a very short time. Using Metasploit’s auxiliary modules, you can
scan an IP address range to determine which hosts are alive and which ser-vices are running on each host. You can then leverage this information to
determine vulnerable services, such as in the WebDAV example, or even log
in via brute force on a remote server.
Although you can easily create customauxiliary modules, don’t discount
the existing auxiliary modules in the Framework. These modules may be the
exact one-off tool you need.
The auxiliary modules provide a wide range of potential additional ave-nues. For a web application, the auxiliary modules offer more than 40 addi-tional checks or attacks that you can perform. In some instances, you may
want to brute force a web server to see which servers are listing directories.
Or you may want to scan the web server to see if it can act as an open proxy
and relay traffic out to the Internet. Regardless of your needs, the auxiliary
modules can provide additional enumeration information, attack vectors, or
vulnerabilities.