Last updated at Thu, 17 Aug 2017 23:56:52 GMT
No, I Will Not Make A Ghost Pun
This week was marked -- some might say mauled -- by the news of another cutely-named vulnerability, GHOST. I'm sure it's a huge deal and justified all of the ballyhoo surrounding it, so I won't get into all that. If you're looking for some technical background, please see Michal Zalewski's excellent analysis.
Since we're in the exploit business, you can be sure I've spent a lot of time fielding questions about severity, ubiquity, and Metasploit coverage this week. We determined pretty early that Metasploit wasn't affected, like most software analyzed so far. So, that's one bullet dodged.
We also confirmed that Metasploit had no need to add an exploit for the publicly-disclosed exim denial of service (DoS), since we've had one shipping with for a little over four and a half years. The venerable SMTP fuzzer module will trip the condition, with just a little bit of tweaking, like so:
msf> use auxiliary/fuzzer/smtp/smtp_fuzzer msf> set STARTLEN 1239 msf> set CMD HELO msf> set FuzzChar 0 msf> set RHOST address.to.vulnerable.and.remotely.listening.exim.server msf> run
With that, you're off to hunt down and knock over all the unpatched, specially-configured, and somewhat old exim servers in your environment. They probably weren't doing anything important anyway. (Okay, only try this on a test network when you're trying to determine if your IDS/IPS is working, or if you have a mature Chaos Monkey style production environment).
As this is a library-level vulnerability, GHOST is not limited to merely old and weird versions of EXIM. I'm sure that we'll have a handful of software and embedded systems that will turn out to be vulnerable to this. In fact, as of this morning, community contributor Christian FireFart Mehlmauer put up a pull request for a Wordpress GHOST scanner, which is nice to have. That'll be landed to Framework this morning, I expect, after the usual code review.
That leaves the remote code execution angle. Of course, that's the only angle anyone really cares about, and it's the hardest nut to crack here. I believe Qualys's conclusion that this bug can lead to RCE... under certain, somewhat specialized circumstances. We kicked it around for a day or two here at Rapid7 and in the Metasploit Freenode channel. Turns out, popping shells with this bug is easier said than done. Maybe if we spent an extra 88 days on it, we'll be able to replicate the conditions required to get code execution. That said, the interest in the open source security community seems pretty low.
I welcome any comers, of course. On the bright side, Qualys says they'll be releasing the Metasploit module "in the near future." I'm looking forward to seeing how they did it, given all the constraints, so I'm looking forward to their submission.
We have two new modules since the last Weekly Wrapup was published. I've been waiting for a RubyGems.org credential file stealer for literally years, and this week, Jonathan Claudius delivered. It's a post module that snarfs up your saved API key, used to publish gems, which is stored, in the clear, in a known location.
Unfortunately, the first version of this module used YAML.load to parse out the credential itself, which can be a Bad Thing. How ironic would that be? You pop a machine of a known Ruby developer (like, say, a Metasploit contributor), go for the RubyGems credential, and end up getting popped right back as soon as you parse your ill-gotten gains! The module was only live for about 13 hours with this security exposure, never shipped in Metasloit Pro or Community Editions or the Kali builds, and was caught the morning after by James egypt Lee. To me, this is a success story for open source code review -- our community and contributor base is highly engaged and puts a critical security eye on pretty much anything we write. It also points out that common programming practices, like using YAML.load to load YAML files (duh?) can lend themselves to exposing security bugs, just by using the normal, standard APIs.
It's kind of a shame we didn't ship the exposure, since it'd be a fun, if dastardly, trick to pull at the Capture-The-Flag event at InfoSec Southwest this April here in Austin. (:
Auxiliary and post modules
- Huawei Datacard Information Disclosure Vulnerability by Jimson K James and Tom James exploits CVE-2013-6031
- Multi Gather RubyGems API Key by Brandon Myers and Jonathan Claudius