Call us on 03450 21 21 51

Magento Exploits – a technical review
The SRM Blog

Magento Exploits – a technical review


Written by SRM

6th November 2015

Share this article


By Mustafa El-Jarrah Information Security Consultant, Security Risk Management Ltd

Exploits appear in trends with the magnitude and duration of these trends exacerbated by the community edition download zip not being updated with the latest patches, often requiring the end user to run patches immediately after installation. This combined with sluggish patching practices in live deployments (often out of fear of breaking something) lead to exploits still being prevalent in the wild several months after their public disclosure date.

The most common type of evidence left is usually Access Log data from the server software, less commonly, there can also be execution and error log data for the PHP preparser software.

Unfortunately, these PHP logs are uncommon and often disabled by default but when present, can be instrumental in definitively distinguishing legitimate code and access from malicious ones.

MAGMI Plugin

In the first 2 quarters of the year, the prevalent exploit within the Magento ecosystem was a vulnerability within the Magento Mass Import (MAGMI) plugin that allowed file uploads to bypass the Magento authentication steps.

Artefacts associated with this type of exploit were often located within the /plugins/ or /magmi/ directories of the compromised site.

Magento version 1.8 and older is affected.

Magmi version 0.7.17a and older is affected.

Key Identifiers

Proof of concept:

Under upload new plugins:
Click on “choose file”

Magento plugins are zipped php files; create or obtain a php shell and zip the file.

File: Once the file has been uploaded, it will say: Plugin packaged installed.

Your malicious example.php file is extracted. You can access it by navigating to your file from:
Artefacts associated with this type of exploit were often located within the /plugins/ or /magmi/ directories of the compromised site.


Towards the second quarter of the year, an exploit that leveraged a vulnerability in the visual (what you see is what you get, or “wysiwyg”) page editor build into the Magento administrator tools.

This allowed an attack to run code or commands, retrieve security tokens and inject data into the database.

This attack was most visible in the server access logs where abnormally large numbers of ‘POST’ requests were being directed towards the WYSIWYG system, often with requests to either uploaded shells or pages requiring a security token in the URL.

Magento version and prior is vulnerable.

Key Identifiers

The attack in this example is written in Python and is implemented through a ‘POST’ method. Typical exploit attempts would look like the following within logs. – – [23/Apr/2015:00:45:44 -0400] “POST /index.php/admin/Cms_Wysiwyg/[HIDDEN] HTTP/1.1″ 403 1880 “-” – – [22/Apr/2015:00:42:38 -0400] “POST /index.php/admin/Cms_Wysiwyg/[HIDDEN] HTTP/1.1″ 200 2211 “-”


Lines 1-3 create an account and sets the target for exploit. The target consists of the target’s domain and a static vulnerable URL which is exploited for this attack.
Lines 5-14 is a SQL statement that is executed by the target servers. It inserts a new admin user inside the database.
Lines 19-22 is the ‘POST’ process with the encoded form of the ‘getCsvFile’ function which was identified to be exploitable and acts as the entry point for the SQL injection.
Lines 24-27 contain a condition statement to verify whether the exploit was successful – if it was, it prints out “SUCCESSFUL” along with the username and password. If it wasn’t successful, it prints out “UNSUCCESSFUL”.


Although the method of entry was not identified on this attack, once the attacker gains access to the site. They inject app/mage.php with code that captures ‘POST’ data being sent to the server. The code encrypts the captured data which includes credit card and billing details and places inside a fake image file entitled ‘mage.jpg’; hence the name of the attack. The image name can be different however this is the most common one that we have come across and the same name reported by other people that have seen the compromise.

The encrypted image can only be opened by the attacker as he would have the private key corresponding to the public key incorporated within the exploit code.

Key Identifiers

Open the file app/Mage.php.
The first part of the file should contain ‘Notice of License’ as follows


* Magento




* This source file is subject to the Open Software License (OSL 3.0)

* that is bundled with this package in the file LICENSE.txt.
If there is other code present prior to the code above then this most likely indicates an issue. There could be a legitimate reason as to why there is other code present however, in the majority of cases this would likely be of a malicious nature.

Web Shells

Common Web Shell capabilities that we’ve encountered:

File Browser/Editor
File Uploader
Permissions Editor
Database UI and SQL interface
Basic Bruteforcing tools
Basic Hash Cracking for passwords (3 providers)
Live PHP execution
Encypted POST variable back door (this is unusual, it’s often either/or with the GUI or POST vars execution)
Encrypting functionality (also unusual, looks like it was used for hiding what data was extracted)
Reverse Shell functionality (when supplied with an IP and port, the shell can be made to run a Perl script to Dial Home)
Functionality to hide from search engines (checks requests for known search engine UserAgent IDs and returns a HTTP 404 response)
Ajax enabled Web console
Cookie handling
Hex Dumping file data
Scraping of ExploitDB for known vulnerabilities matching the installed system
Important to note that web shells have generically been base64 encoded in the past and it was relatively easy decoding them to analyse their functionality/capability. However, as of recent times, we are seeing a new approach to web shells where they are obfuscated with base64 encoding and also encrypted with a password.

This means traditional means of decoding are failing and after doing some research, there doesn’t seem to be a viable way of decrypting them which leaves us with very little when it comes to describing their capabilities in the PFI reports.

Back to top