Magento RCE And Application Security Templates

Part of the responsibilities of the Qualys Web Application Firewall (WAF) security team is to analyze newly disclosed vulnerabilities. We must ensure their correct detection, and when necessary, publish security updates that will be pushed onto customers' sensors so they can be protected. For most vulnerabilities, these changes are only cosmetic. The inspection engine already knows all the classic web attack strategies (SQLi, XSS, …), and typically our patches are about displaying specific messages to warn the customer that a known vulnerability has been targeted.

But occasionally, as in the case of the Magento remote code execution (RCE) vulnerability described by Checkpoint, the vulnerabilities are far more interesting. As I describe in this article, these vulnerabilities are in application-specific protocols on top of the HTTP protocol. That means they are not blockable by standard web application firewalls, and it is necessary to write and deploy custom signatures to block them. Qualys is writing a set of these custom signatures, called "Application Security Templates," to provide accurate inspection for application-specific behaviors and protocols. They extend and enrich the classic HTTP inspection to provide "state of the art" security for the most well-known applications.

In Search of the Lost Payloads

To assert the effectiveness of our security engine against the RCE attack, we must understand how the exploit payloads are sent. Our starting point will be the blog post published by Checkpoint.

The unauthenticated remote execution is triggered using three different vulnerabilities named CVE-2015-1397, CVE-2015-1398, CVE-2015-1399. Checkpoint researchers have documented at length the investigation process they have conducted to discover these weaknesses, as well as some dead ends they have reached. But after having carefully read their blog post, we have to face the facts: some critical technical details are missing and some tricks have been hidden from the public. The reason for that is obvious. Magento is a critical application widely used for e-commerce, and nobody wants to give script kiddies an easy way to write an exploit. Browsing the web to find exploit signatures used by black hats lead to the same result: all exploit payloads have been hidden to prevent an easy exploit reconstruction.

We are left with no other choice than to download the vulnerable application code and follow the Checkpoint researcher’s steps. Let’s analyze the three CVEs from the WAF detection point of view.

CVE-2015-1398 : Authentication Bypass

The first discovery made by the auditors is the ability to use reflection to trick the application to load admin controllers from classic user context. The controller’s class names are constructed from values derived from the URL.

To load “Mage_Downloadable_Adminhtml_Downloadable_FileController.php” an authenticated administrator will request:

GET /index.php/admin/downloadable/file/ HTTP/1.1

A user will be able to reach the same result by requesting:

GET /index.php/downloadable/Adminhtml_Downloadable_File/ HTTP/1.1

But this behaviour is restricted to the controllers whose names are similar in admin and classic user contexts. This was useless to conduct further attacks. Digging deeper into the authentication process, another design flaw was discovered. Adding a simple parameter named “forwarded” to the request lead the application to continue the execution even if no admin credentials were found. The administrator’s modules with no additional checks for specific privileges were now in the scope of the auditors.

From the detection point of view, these design vulnerabilities are not detectable by default since they are highly specific to how the Magento application works. No generic payloads are discernible and these vulnerabilities need dedicated inspection rules.

CVE-2015-1397 : SQL Injection

The second vulnerability leading to command execution is a SQL injection. This vulnerability is triggered when the user specifies filters to apply to a templated view. To build an effective filter we must understand how these filters are conveyed to the application.

Let’s have a look at the code. The vulnerable function that sets these filters gets the filter string from classic HTTP parameters.

$filter = $this->getParam($this->getVarNameFilter(), null);
...
if (is_string($filter)) {
$data = $this->helper('adminhtml')->prepareFilterString($filter);
...
}

The “prepareFilterString” function defined in the “Mage_Adminhtml_Helper_Data” class applies the following normalization:

public function prepareFilterString($filterString)
{
$data = array();
$filterString = base64_decode($filterString);
parse_str($filterString, $data);
array_walk_recursive($data, array($this, 'decodeFilter'));
return $data;
}
...
public function decodeFilter(&$value)
{
$value = trim(rawurldecode($value));
}

From these code blocks, we can deduce that the filters will be specified using a base64 encoded string that contains parameters encoded with a classic query string pattern (param1=value1&param2=value2).

Once again we can conclude that the Magento design is creating an obstacle for efficient detection in a WAF. The exploitation payloads are in this case base64 encoded and will not be detectable without dedicated filtering.

CVE-2015-1399 : Remote / Local File Inclusion

Let’s now have a look to the third vulnerability used by Checkpoint to reach command execution. The LFi is triggered using the reflection mechanism dedicated to template loading inside Magento. This reflection mechanism allows us to use a specific parameters to load classes and execute methods on them. According to Checkpoint, the targeted parameter is using the following format:

{{FUNC_NAME PARAM_NAME=PARAM_VALUE}}

The LFi/RFi will occur when a PHP wrapper is set as a “script path” attribute of the loaded template. To set this attribute, we have to call the “setScriptPath” setter with the reflection mechanism. This can be done by specifying “ScriptPath=PAYLOAD”. The targeted parameter will look like this :

{{FUNC_NAME ScriptPath=phar://lolz.file/}}

How will this impact WAF inspection?

This depends greatly on how the inspection rules are written. The exploit payload is in clear text. But it is part of a more complex structure that is not related to the HTTP protocol. Should your WAF expect PHP wrappers to be located at the beginning of HTTP parameters? Or should it search for this kind of payload anywhere inside the parameters?

The Need for Application Templates

What to conclude from these inspection weaknesses?

First of all, we can predict that no WAF in the market is able to protect against Magento RCE at the time when this vulnerability was released. The final step to reach command execution was discernible and might be detected by some WAF. But when caught most of the exploit process was already achieved and the database, the most important asset of Magento users, was already compromised. Black Hats made no mistake about this and the first detected exploits in the wild were only targeting the SQL injection vulnerability, adding a new administrator to the application.

To understand how these WAF weaknesses can happen from time to time, we must understand the evolution of HTTP protocol usage. Initially designed to serve simple pages, this protocol is now used for multiple uses and all classic Internet services tend to migrate to this technology. This evolution is also discernible in the evolution of web browsers. Initially designed to render simple HTML pages, they now tend to replace even the exploit system (Chrome OS).

With the explosion of HTTP usage, lots of web application technologies were pushed toward building more specific protocols on top of the HTTP protocol to reach their desired functionality level. Magento reflection structures ( “{{FUNC_NAME PARAM_NAME=PARAM_VALUE}}” ) are a good example: this parameter format will not be found in any other web application. But other examples can be found in almost all integrated web technologies (frameworks, application server, …).

To keep up, WAF technologies are left with no choice other than to analyze these new “protocols” on top of HTTP, and to implement specific inspection processes on top of the classic HTTP inspection.

How Qualys Web Application Firewall Protects Against Magento RCE

The Qualys WAF security team has included dedicated Magento inspection on top of the classic inspection. All vulnerabilities discovered by Checkpoint will be handled in the latest security rule set, included by default in the 1.1.0 sensors.

More generically, the WAF team is currently working on defining a way for the end-user to specify which technologies are monitored by the Web Application Firewall. These specific configuration directives will activate dedicated inspection rules that will be able to understand and inspect “in-house” protocols used by these specific web technologies.