Magento Web Exploit Case Studies

Magento is an extremely popular e-commerce platform leading market share at around 30% in e-commerce businesses and it’s handling over 50 billion dollars a year. As a result of Magento being widely used platform for many web shops, it also draws attention. Extra attention attracts hackers which is why there have been some flaws in its software causing damage to website owners and customers. This is the reason why knowing your system and software and having the best protection from attackers with latest security patches and Magento updates is crucial. Magento has an open source code version which is one of the reasons it can be exploited more often. Website potential intruders can easily analyze and test code themselves and determine which parts of the code have weaknesses. Although Enterprise version does not have free code access, many parts of software mixes and coincides with Community Edition version, enterprise version also being vulnerable. It’s always recommended to follow the latest patch and Magento updates and scan your website for security flaws regularly. In this blog post, I will go through a few of the cases of when and how Magento was vulnerable to different exploits and how they were prevented.

MySQL injection case

The database contains all the sensitive information and MySQL injection exploit gives the attacker basically full control of the database. Magento Community Edition (CE) 1.9.1.0 and Enterprise Edition (EE) 1.14.1.0 were vulnerable to an SQL injection exploit. This case was formally identified as CVE-2015–1397 which widely spread at the moment. Function getCsvFileinside class Mage_Adminhtml_Block_Widget_Grid was responsible and had a weakness. This vulnerability allowed remote admin users to execute arbitrary SQL commands via the popularity[field_expr] parameter when the popularity[from] or popularity[to] parameter is set. While many of website owners did make procedures to avoid these attacks, many did not.

Magneto uses modules which are directories and these directories contain functionality. Modules mostly have controllers which are PHP files and contain classes and public methods. By Magento standards, this means that requests with parameters can be sent to these controllers using url paths. Most of the modules have implemented specific checks for privileges which attackers just do not have however there are few modules that do not have privilege check since they do not have anything in the interest of attackers. In this case, attackers target url was http://www.example.com/index.php/admin/Cms_Wysiwyg/directive/index/ where CMS_Wysiwyg controller under the Adminhtml module only has one action named ‘directive’. This actions loads image with given path, but will throw an exception once anything other than a valid image will attempt to load.

However, inside this action we have a filter() function:

$url = Mage::getModel('cms/adminhtml_template_filter')->filter($directive);

where $directive parameter passed to filter function is being read from the post parameter:

$directive = $this->getRequest()->getParam('___directive');

This means that by creating post request with ___directive parameter as an encoded base64 string which contains SQL queries, the system decodes malicious request and executes SQL query like this:

popularity[from]=0&popularity[to]=3&popularity[field_expr]=0);

SET @SALT = 'rp';
SET @PASS = CONCAT(MD5(CONCAT( @SALT , 'asdf') ), CONCAT(':', @SALT ));
SELECT @EXTRA := MAX(extra) FROM admin_user WHERE extra IS NOT NULL;

INSERT INTO `admin_user` (`firstname`,`lastname`,`email`,`username`,`password`,`created`,`lognum`,`reload_acl_flag`,`is_active`,`extra`,`rp_token`,`rp_token_created_at`) VALUES ('Firstname','Lastname','email@example.com','sadmin',@PASS,NOW(),0,0,1,@EXTRA,NULL, NOW());

INSERT INTO `admin_role` (parent_id,tree_level,sort_order,role_type,user_id,role_name) VALUES (1,2,0,'U',(SELECT user_id FROM admin_user WHERE username = 'sadmin'),'Firstname');

This SQL query set new passwords, added new admin users and set admin roles which lead to full control of database and back end panel, gaining access to all necessary data to cause damage.

What makes this exploit even more dangerous - this exploit script was available publicly to anyone:

https://github.com/joren485/Magento-Shoplift-SQLI/blob/master/poc.py

This exploit was registered and officially confirmed by Magento and was fixed under Magento provided SUPEE-5344 security patch update and they recommended to apply it as soon as possible. Though many website owners and developers just were not aware of this issue and proposed a fix. This is how one missing patch can affect your online business.

XSS — Cross Site Scripting

Cross-site scripting does not require high complexity skills and is a relatively easy exploit method and allows unauthorized modification. In simple words, XSS vulnerability can be exploited by cause of not properly processed or sanitized user input fields which gives access to run custom javascript codes and can have a high impact on your business security.

Although this can happen to any custom input field which is not properly filtered, one of the cross site scripting cases was referenced as CVE-2014–9758 DOM-based vulnerability. In this case several Adobe Flash files that came with Magento 1 package were detected as vulnerable to DOM based Cross Site Scripting (XSS). Following files were identified as being exposed:

http://magentourl.com/skin/adminhtml/default/default/media/editor.swf

http://magentourl.com/skin/adminhtml/default/default/media/uploader.swf

http://magentourl.com/skin/adminhtml/default/default/media/uploaderSingle.swf

Malicious JavaScript code can be injected with specially created link or form post. Upon execution, usually injected JavaScript code can take control of users session cookies which allows to gain access to user’s session. This gives attacker ability to gain sensitive data and perform actions from the gained user account session. There was a code within each of the affected files where bridgeName parameter is passed to ExternalInterface.call without being filtered for malicious inputs.

function dispatchInit(param1)
{
	if (ExternalInterface.available == false) {
		return;
	}

	if (bridgeName == null) {
		bridgeName = baseObject.root.loaderInfo.parameters["bridgeName"];

        if (bridgeName == null) {
            bridgeName = "flash";
        }
    }

    _registerComplete = ExternalInterface.call("FABridge__bridgeInitialized",[bridgeName]);
    dispatchEvent(new Event(FABridge.INITIALIZED));
}

As proof of concept the following link used under 1.9.0.1 Magento version before patches would run JavaScript alert() function:

http://magentourl.com/skin/adminhtml/default/default/media/editor.swf?bridgeName=1\%22]%29%29;alert%281%29}catch%28e%29{alert%281%29}//

Detected vulnerabilities at the moment could’ve been fixed by giving these files restricted access. Vulnerabilities were fixed under further Magento versions by adding proper filtration for the bridgeName parameter and input fields.

Remote Code Execution

In 2016 Magento announced and warned users of security vulnerabilities of possible remote code execution in checkout. Magento released their security advisor which did not give a lot of details, but a warning about this possible issue was released. This issue was identified as APPSEC-1484 and was a serious concern for all Magento business owners. In brief, this vulnerability was known for malicious PHP code execution during checkout and was affected for all Magento CE (Community Edition) versions prior to 1.9.3 and Magento EE (Enterprise Edition) prior to 1.14.3. It was classified with rating 9.8 (critical) which required high attention. APPSEC-1484 remote code execution vulnerability was considered a very serious and critical issue which allowed hackers to insert PHP code in payment gateways and by that gain complete access to your Magento site. This case is also referenced to SUPEE-8788 since this is the patch that was provided by Magento to fix this and also various other less critical issues. This critical issue was outlined in more detail by Netanel Rubin — http://netanelrub.in/2016/05/17/magento-unauthenticated-remote-code-execution/

Another similar remote code execution was vulnerable for Magento versions under 2.1.6 with identifier DC-2017–04–003. This high-risk vulnerability was discovered during a security audit of Magento CE (Community Edition). It could lead to remote code execution resulting in compromising Magento shop and gaining access to the database which consists of sensitive data, like customer information and possibly credit card numbers. The issue hides behind Vimeo video content upload to new or existing products. Magento will automatically upload preview image via POST request taking remote image URL parameters. In POST request there is a form_key parameter which serves as CSRF (cross-site request forgery) token which would prevent malicious actions. This is why changing request from POST to GET which has a lack of form_key parameter will open doors for attacks.

The GET request could look something like this:

Magento validation will check whether url has a valid image instead of, for example, PHP file and respond with an error message, but the file will be downloaded regardless, which is basically the hole in the system. The file would be saved by default under:

/pub/media/tmp/catalog/products/<X>/<Y>/<originalfilename>

X and Y being the first and second character of the file name. There are two files necessary under this path to exploit remote code execution, one being .htaccess file and second — PHP script to be executed. Accordingly using GET request attacker can upload a .htaccess file which would save under /pub/media/tmp/catalog/product/_/h/ (“.” is being replaced by underscore “_”) which means PHP script file should start with “.h”. Newly added .htaccess file settings could be as simple as “php_flag engine 1” which would turn PHP parsing on. PHP script file content could look something like this:

<?php echo shell_exec($_GET['cmd']); ?>

This would allow accessing this file via a link like:

<magentoroot>/pub/media/tmp/catalog/product//h/.hshell.php?cmd=whoami

and in this case execute the command: “whoami” which gives the attacker access to the command line.

One of the advice is to enable the option “Add Secret Key to URLs” which would provide protection against these type of attacks and also configure .htaccess file to prevent remote code execution through arbitrary file upload in affected directories. Although in most recent Magento versions this vulnerability is avoided.

Conclusion

It is important to follow Magento most recent patch and version updates to get the latest security fixes if there are some. Having older versions than Magento provides means you get stuck not only on the version, but also PHP and MySQL if you are far behind, which simply means you get stuck on your shop and business. It should be a healthy action to upgrade your software and fix security holes to avoid any attacks to your e-commerce shop and customers you are serving. Having detailed analysis and digging deeper into the Magento exploits gives developers valuable insights on how system and software can be manipulated and once you know how systems can be hacked, you can also improve and adjust your website security and protect businesses from malicious attackers.