Last updated at Mon, 24 Jul 2017 17:27:39 GMT

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.