Adventures in FOSS Exploitation, Part Two: Exploitation

This is part two of a pair of articles about disclosing vulnerabilities in a set of FOSS projects, see part one for some background on these vulnerabilities in particular, and some general advice for FOSS developers and maintainers.

 

A while back, I started a project to go over some of the top Sourceforge web applications and try to write some Metasploit modules for them. In the end, I was able to write seven new Metasploit modules (six exploits and one aux). Some of the modules take advantage of intended functionality, such as the Moodle module. Others take advantage of true security flaws, such as the Openbravo XXE module. I will go into detail for each module in this blog post.

 

I would like to especially thank todb for handling the vuln reporting for these modules, as I am lazy and just want to hack stuff. Props!

 

Moodle Authenticated Remote Command Execution (CVE-2013-3630)

Moodle is an open-source Learning Management System or Course Management System. It is used around the world by educational institutions, private enterprises, and governments alike and is a very good example of a solid open-source project. This year, as of this writing, Moodle has been downloaded from Sourceforge over 800,000 times. However, Moodle is easily installed from apt and yum as well.

 

This module exploits more of a design flaw than a bug as the feature that is abused is meant to be there. This means that this isn't actually going to be fixed, but I will discuss mitigation later.

 

The module also has the ability to exploit a vulnerability. Moodle was recently found to have an XSS bug that allows a student (unprivileged user) to steal an admin's session key (the "sesskey"). You can log in with less-privileged credentials, but supply a sesskey for an admin. This allows the unprivileged user to have the authorization of the admin, which in turn allows the user to pop a shell. You can read more about this XSS vulnerabilities on Exploit-DB.

 

image.jpg

 

So, down to the knitty-gritty, how do you pop the shell? Within Moodle, an Administrator has the ability to specify a system path to the aspell binary on the filesystem that the TinyMCE editor will use for spell-checking. You can probably already see where this is going.

 

image.jpg

 

Basically, an attacker can specify an arbitrary command, ensure the editor will use the system aspell, and make a request to ask for a spell check. By default, it is not set to the correct value and you will need to ensure it is using the system aspell.

 

image.jpg

 

 

When the request for a spell check is made, the command is run in the context of the web application. If you specify the username and password of any user, and a sesskey of an admin, the exploit will work in the exact same way.

 

You can use the config value "$CFG-> preventexecpath = true" to mitigate this risk.

 

image.jpg

 

Disclosure Timeline (Moodle)

 

Sat Aug 03, 2013: Initial discovery by internal researcher

Sat Aug 03, 2013: Draft Metasploit module written

Mon Aug 26, 2013: Initial contact to vendor

Mon Aug 27, 2013: Bug filed at Moodle bug tracker as MDL-41449

Wed Oct 30, 2013: Public Disclosure

 

Vtiger CRM Authenticated Remote Code Execution

 

This web application has been downloaded over 200,000 times this year from Sourceforge.

 

image.jpg

 

I found that an authenticated user (default creds admin:admin) could upload PHP source files with an extension of .php3 (.php was blocked) after manipulating a URL that the user is taken to during image uploading.

 

image.jpg

 

By altering the URL (is read-only, need to copy to new tab), you could navigate to an upload folder with less file restrictions than the image upload folder, and by uploading a PHP script to this folder, you could access the script remotely to have it run the arbitrary PHP code.

 

image.jpg

 

There are two vulnerabilities here that lead to successful exploitation. The first is that a user could navigate to an upload directory with less restrictions on allowed filetypes (non-images). The second is that this used an incomplete blacklist (restrict .php but not .php3).

 

You can access the newly uploaded file directly on the web server and execute any PHP code you want.

 

image.jpg

 

Once I realised the workflow for exploitation, a Metasploit module was cake . The module is effective against versions 5.3.0 and 5.4.0 of VTiger CRM.

 

image.jpg

 

Disclosure Timeline (vTiger CRM)

 

2013-07-01: Vulnerability discovered by Brandon Perry, Rapid7

2013-07-01: Metasploit module written

2013-07-02: Disclosure first draft written

2013-07-03: Vendor contacted with disclosure and Metasploit module

2013-07-23: CERT/CC contacted with disclosure and Metasploit module

2013-09-05: Planned Public disclosure (delayed)

2013-10-30: Public disclosure

 

Zabbix Authenticated Remote Command Execution (CVE-2013-3628)

 

Zabbix is an enterprise-class open-source software for monitoring networks, similar to Nagios. It has been downloaded on Sourceforge almost 300,000 times this year so far.

 

This module abuses functionality within the application which allows an administrator to run scripts on hosts. By creating a host with an IP of 127.0.0.1 (it can already exist, will make two), then you can create a 'script' with an arbitrary command to be run on the Zabbix server, and call script_exec.php with the ID of the new host and the ID of the new script. This module uses the same vector of command execution as the module pyoor just got pushed into the framework, but uses real authentication as opposed to a SQL injection. This means mine will still work after the patch, with correct credentials. As it turns out, I found the vector around the same time as another researcher (Lincoln of corelan), independently. Funny how things like that work sometimes.

 

image.jpg

 

Disclosure Timeline (Zabbix)

 

Sat Aug 24, 2013: Initial discovery by internal researcher

Sat Aug 24, 2013: Draft Metasploit module written

Mon Aug 26, 2013: Initial contact to vendor

Wed Aug 28, 2013: Response from vendor, details provided

Wed Sep 11, 2013: Disclosure to CERT/CC

Wed Oct 30, 2013: Public Disclosure

 

Openbravo ERP Authenticated XXE (CVE-2013-3617)

 

Openbravo ERP is an open source project available on Sourceforge, downloaded over 134,000 times this year. It was vulnerable to an XXE (XML eXternal Entity) attack the the XML API. This allows an authenticated user to post specially-crafted XML to the XML API and read arbitrary files from the file system as the user the application is running as (generally not root).

 

image.jpg

 

If you aren't familiar with what an XXE attack is, I will explain it briefly. A great resource to read up more fully on this type of vulnerability is on the OWASP website.

 

Basically, the default SAX parser used by many Java applications by default validates and expands entities defined within an external DTD. An attacker can create an external DTD within the XML request to a web service that will define new entities and where to look for them if referenced. When this request is parsed, the entities will be expanded on the server side to the values they are set to be expanded to. You can set these to expand to local files on the file system, thus replacing the entity with the contents of the file. This is the basic premise of the attack.

 

Openbravo ERP is a Java application that provides an XML API to authenticated users. This is available at the URI /ws/dal/<ENDPOINT>. Each endpoint represents a specific entity within the Openbravo data access layer. The module by default uses the ADUser endpoint because you will eventually find a user you can edit (yourself) and persist with the new value. Each class represented by the endpoints seem to all share at least one property, a comment. This field seems to be postable with free form text across all the endpoints I tried (Product is another). The module uses this field to store the value of the file, then requests the updated entity from the endpoint with a GET and parses the comment field. I do try to remain stealthy, so I remove the file from the comments field when done. You have ability to set the endpoint you want to use in the options for the module (ENDPOINT, be default ADUser).

 

image.jpg

 

Disclosure Timeline (Openbravo ERP)

 

Mon Jul 22, 2013: Initial discovery by internal researcher

Mon Jul 29, 2013: Draft advisory written

Tue Aug 06, 2013: Initial contact to vendor

Tue Aug 06, 2013: Automatic response for issue 22813

Tue Aug 13, 2013: PGP key provided, disclosure sent to vendor

Wed Aug 26, 2013: Disclosure to CERT/CC

Thu Aug 27, 2013: VU#533894 assigned by CERT/CC

Wed Sep 04, 2013: Planned public disclosure (Delayed)

Wed Oct 30, 2013: Public Disclosure

Wed Oct 30, 2013: CERT/CC VU published

 

 

ISPConfig Authenticated Remote Code Execution (CVE-2013-3629)

 

 

ISPConfig is an open source hosting control panel written in PHP that allows for easy management of resellers and clients of internet cloud space and the like.

 

An administrator (default creds admin:admin) on ISPConfig has the ability to import and export language definition files. These files contain snippets of PHP code that get evaluated and executed in order to persist the correct language values. An attacker can abuse this by uploading a specially crafted file with arbitrary PHP code.

 

The Metasploit module I have written to take advantage of this is called ispconfig_php_exec and allows the attacker to define the language that will inevitably be over-written (so don't choose the main language, otherwise it will be apparent something is wrong). While the vendor has stated they have added mitigations to later versions than 3.0.5.2 (which I was testing on at first), the module still works against the latest release.

 

image.jpg

 

Disclosure Timeline (ISPConfig)

 

Mon Jul 29, 2013: Initial discovery by internal researcher

Mon Aug 29, 2013: Draft Metasploit module written

Mon Aug 26, 2013: Initial contact to vendor

Tue Aug 27, 2013: Vendor response with PGP key

Tue Aug 27, 2013: Vendor provided with full details

Wed Sep 04, 2013: Vendor provided a fix

Wed Sep 12, 2013: Disclosure to CERT/CC

Wed Oct 30, 2013: Public Disclosure

 

OpenMediaVault Authenticated Remote Command Execution (CVE-2013-3632)

OpenMediaVault is an open-source Debian distribution for network attached storage devices. Available on Sourceforge, it has been download over 500,000 times this year as of this writing.

 

OpenMediaVault allows you to create cron jobs as users (including root). This module abuses this to create a cron job to run whatever arbitrary command the authenticated attacker (default creds admin:openmediavault) wants to run.

 

image.jpg

 

Disclosure Timeline (OpenMediaVault)

 

Thu Aug 01, 2013: Initial discovery by internal researcher

Thu Aug 01, 2013: Draft Metasploit module written

Mon Aug 26, 2013: Initial contact to vendor

Tue Aug 27, 2013: Vendor response with PGP key

Tue Aug 27, 2013: Vendor provided with full details

Wed Sep 11, 2013: Vendor response

Wed Sep 12, 2013: Disclosure to CERT/CC

Wed Oct 30, 2013: Public Disclosure

 

NAS4Free Authenticated Remote Code Execution (CVE-2013-3631)

NAS4Free is an open-source BSD distribution for network attached storage devices. Available on Sourceforge, it has been downloaded nearly 350,000 times this year as of this writing. NAS4Free is a direct continuation of development of FreeNAS, just under a different name (due to legal circumstances).

 

A feature offered by NAS4Free to authenticated users (default creds admin:nas4free) is to run arbitrary PHP code (what could go wrong?). It also offers to run bash commands, but the bash environment is very limited and no connect-backs were viable via this vector.

 

image.jpg

 

This module simply takes advantage of this feature to pop a shell with PHP. I noticed that PHP meterpreter did not work properly, and settled on using the more simple php/reverse_php payload for most of my testing.

image.jpg

 

Disclosure Timeline (NAS4Free)

 

Fri Aug 02, 2013: Initial discovery by internal researcher

Fri Aug 05, 2013: Draft Metasploit module written

Mon Aug 26, 2013: Initial contact to vendor

Wed Aug 28, 2013: Disclosure to vendor

Wed Sep 12, 2013: Disclosure to CERT/CC

Wed Oct 30, 2013: Public Disclosure

Wed Oct 30, 2013: CERT/CC VU published