MSIE exploit for CVE-2013-3893

This week, you might have seen some press on our new exploit for CVE-2013-3893, some of which engages in that favorite infosec dichotomy of full disclosure vs "responsible" disclosure. First, if you want some technical details on the exploit development process used by our own Wei @_sinn3r Chen, the bop on over to his blog post on CVE-2013-3893. If you're interested in a retort to the doomsayers about our philosophy of free and open exploit dev, feel free to read on.


There's some concern that since Metasploit released an exploit for this unpatched vulnerability, we're "compounding" the situation, making things worse. I have to say, I kind of don't buy the reasoning behind that for a couple reasons. To start, criminal users of exploits already had the goods; while we picked up our sample about a week before publishing the exploit, there's some intelligence that suggests that this vulnerability has been part of criminal campaigns since at least early August, 2013, and quite probably earlier.


An exploit going mainstream in the form of a Metasploit module can have the upside benefit of raising general awareness of the bug in question. This, in turn, can put pressure on vendors to issue patches. We saw pretty much exactly that back in January: On January 11, we published an exploit for an unpatched vuln in Java, and there was similar hand-wringing about "responsible" exploit disclosure. Two days later, 7u11 was released. This kind of turnaround is exceedingly rare for Oracle. Was the availability of a Metasploit module the cause of the lickity-split patch release? You'll have to ask them, but it looks like a pretty solid cause-and-effect relationship to me. I don't know if this is going to play out exactly the same way for this MSIE bug. Microsoft does have a Fix-It available, and EMET 4.0 appears effective as well, so that does buy some time for concerned end users, but at least now it's not just bad guys who can test your end-user protection mechanisms.


Speaking of which, if your security posture depends on a lack of public exploits for 0-days, I have to say, you're kind of doing it wrong. "Defense in depth" is a security mantra for a reason. If your organization gets popped because of a client-side 0-day, I hope your incident response report contains some suggestions on how not to get owned the same way next time. You do have an IR plan, right? In the era of a hostile Internet, I don't think it's reasonable to rely on perfect software, nor is it reasonable to rely on limited availability of exploits where only criminals and shady government operations have access to attack tools.


So, I think Metasploit is pretty reasonable when we go about publishing exploits. We have a partial-secrecy disclosure policy that we stick to for what we believe to be truly unique zero-days, but when something serious is circulating on the Internet, we've found it's best for everyone to invite everyone to participate in the risk-assessment process.


New CMD stager for embedded devices

Okay, rant over. Let's talk about something more pleasant, like Joe Vennix's and Juan Vazquez's work on a new CMD stager for limited Linux platforms. You can read up on the vulnerability that started it and the research that followed at Juan's recent blog post. It's long, but totally worth it, and culminates in a reliable exploit for CVE-2013-3568 for Linksys routers. This work is available now in the latest Metasploit update, revolving around using plain old "echo" to construct a payload on the victim device.


Since this was published, we have a new, possibly even better version, that uses the shell-builtin "printf" function (common to all POSIX-compliant shells) in the form of Pull Request #2412 from community contributor Markus mwulftange Wulftange. We'll be probing the limits of this technique's portability soon, so look for it in an upcoming update.


Hitting up unattend.xml for passwords

Finally, I'd like to hilight a module we've landed from community contributor Ben @Meatballs__ Campbell. Turns out, when Windows is installed using a scripted installation -- which is common for many corporate environments -- the unattended "answer file" is often left behind on the installed system. This can contain lots of juicy sensitive data, not the least of which are default local administrator passwords. Ben's module makes short work of these, and honestly, and checking to see if a compromised target has this trove of info should be part of any penetration testing engagement.


Note that clearing sensitive data is part of normal post-installation, but there are several ways this sanitation can fail, as discussed on Christopher Blake's blog, here. So, to defend against this info-leak, system administrators are advised to be on the lookout for these installation artifacts, lest they fall into the hands of your industrious local penetration tester.


New Modules (and much more!)

Including the four discussed above, we've got eight new modules this week, including a new exploit for Nodejs (with an accompanying "ARCH_NODEJS" payload, which is exciting), and exploits for Astium, ZeroShell, and freeFTPd. There's a ton of other exciting new fixes and content in this release I didn't get a chance to highlight as well, most notably, the fact that this update bumps Metasploit to version 4.7.1, so that means new bins for Nmap, Postgres, and updated Rails and other Ruby gems. So, your total update size is going to be bigger than usual.


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.