Seven FOSS Tricks and Treats (Part One)

Last updated at Thu, 28 Dec 2023 18:49:56 GMT

Adventures in FOSS Exploitation, Part One: Vulnerability Discovery

_This is the first of a pair of blog posts covering the disclosure of seven new Metasploit modules exploiting seven popular free, open source software (FOSS) projects.

Back over DEFCON, Metasploit contributor Brandon Perry decided to peek in on SourceForge, that grand-daddy of open source software distribution sites, to see what vulnerabilities and exposures he could shake loose from an assortment of popular open source enterprise applications. For his effort, he discovered a variety of vulnerabilities and exposures, and has released Metasploit modules for the following applications. All have some kind of webapp component, which was the focus of his efforts.

Affected Software Summary

The most popular application on this list is Moodle, with over four and a half million downloads over its lifetime of SourceForge hosting, and the least is NAS4Free, with merely several hundred thousand downloads. While this is only an approximate figuring of popularity, and none approach the installation base boasted by Wordpress or Apache, they nevertheless are not uncommon to find on a penetration testing engagement. Across all seven projects, we're looking at a total lifetime download count of about 16 million. If only one to two percent of those are installed and still active today, that's still over a quarter million targets out there.

Despite this level of apparent popularity, though, the actual business of disclosing vulnerabilities to the software developers directly was... circuitous. Across these seven projects, I found there were at least seven different approaches to handling incoming vulnerability reports.

It's been well over a decade since the publication of Rain Forest Puppy's seminal work, the RFPolicy 2.0, and virtually everyone in the information security community can agree that some kind of vulnerability disclosure policy is useful for any serious project of note. Yet, when we contacted these vendors, it was as if the RFPolicy had never existed.  I won't trouble you with shaming details of disclosure -- I won't mention which project representative asked for a password-protected zip file of the disclosure, while another filed the issue on a public bug tracker which promptly e-mailed it back in cleartext -- but the the level of preparedness I ran into was pretty troubling. I suspect, rather strongly, that mature security issue handling that you find at organizations like the Apache Foundation or Microsoft is the exception, and not the rule.

A Vulnerability Handling Checklist

So, rather than simply dump these vulnerabilities and exposures and run, we thought we'd provide an extremely short checklist that software maintainers could use to ensure that they are holding up their end of the social contract for popular software. This is broad strokes stuff, intended for the (apparently huge) audience of software developers and maintainers who don't already have a security vulnerability handling procedure in place.

1. Have a designated security mailing alias. If your software is popular, you almost certainly already have a dedicated domain is an ideal format. Try not to be creative with this naming convention; the goal is to be easily guessable, even if the reporter can't (or won't) find your most excellent web page describing your disclosure process.

2. Have a signed PGP key. Ideally, you will already be participating in a web of trust, and can collect multiple signatures, but at the very least, the PGP/GPG key associated with security@yoursoftware.org is signed by one or more of your core developers.

3. Publish your PGP key somewhere obvious. At Rapid7, we link to our PGP key on MIT's keyserver. CERT/CC is even better at this, hosting the key directly on their own server over HTTPS. At a minimum, it should be findable with very little work.

4. Insist on encrypted communication. Yes, the NSA has already broken everyone's encryption (let's say), but that doesn't mean every ISP, intermediate router, e-mail exchange, and bug tracker should have straight cleartext access to your security disclosure messages. I have no idea if anyone's watching your comms for reported security issues, but more importantly, neither do you. Plus, using encrypted e-mail serves as a pretty decent shhibboleth for representing yourself as Serious About Security.

5. Acknowledge receipt. If you are getting a disclosure for free you should be polite and acknowledge receipt. The vulnerability discoverer is playing by the rules, so you should make the effort as well. Worst case, you don't respond, and the discoverer just dumps his findings on Full Disclosure.

6. Have a contact at CERT/CC. I like dealing with CERT/CC a lot, since they tend to know people, and know people who know people. If something serious is discovered, we communicate with CERT/CC shortly after informing the vendor, so if they already know who you are, coordinated disclosure is all the easier.

7. Issue a patch. This may seem obvious, but not every vulnerability is a bug in code. Some -- like the ones found here by Brandon -- are "merely" exposures, which are (often unintended) features; in this case, a patch could simply be a documentation update, warning about the described behavior.

8. Issue a disclosure. Nearly always, security researchers will publish their own findings. Sometimes, CERT/CC will publish a Vulnerability Note. Public security resources such as OSVDB and Exploit-DB will often have entries for your bug. All of this is great here in infosec land, but your users may not keep abreast of these sources. For many of them, all they know about your software is what you tell them. So, take advantage of this event to help out your users, and their users, and the rest of the Internet. Have a link to some clearly worded text that describes the problem, the solution, and any workarounds.

That is really the long and the short of it. It's a little preachy, but believe me, there are many, many more things to say on disclosure (both giving and receiving). The above should get you going today if you don't already have some kind of process in place, and if you have many hundreds of thousands of downloads, you really ought to have that process ironed out and ready to go.

That's nice, what about all the "wontfix" bugs?

Please see part two of the FOSS Tricks and Treats by Brandon Perry, for technical details of these exposures and vulnerabilities. The modules described are checked into Metasploit now, and will be available as part of the regular Metasploit update. Note that all are post-authentication, which means that you already need a username and password to exercise host operating system functionality via the HTTP/HTTPS vector. Also, for some of these applications, the argument was made that these exposures were normal, designed functionality. In other words, many of these modules will still function in the latest patched versions of the software.

There is definitely room for debate as to whether or not these were particularly wise design decisions. On the one hand, many of these applications assume the user is also already in control of the host operating system. On the other, the users of these applications may not realize that by allowing regular old port 80 traffic, they are, effectively, opening a full shell to anyone able to guess a username and password. Penetration testers love these kinds of applications, since they often can provide surprising and unexpected footholds into a network.

Thanks to CERT/CC for helping with disclosure chores, and to the above vendors who responded in a timely way to our vulnerability disclosure ministrations. Regardless of their unique disclosure handling processes, every one of them reacted politely and professionally, so thanks for that.

Update: ISPConfig has reported that they are patched and has provided a link. Links also provided for the vTiger and Openbravo fixes.