Magento eCommerce Security: Guide and free MageBee audit

Security is a really hefty topic when it comes to eCommerce. A lot is at stake and if you don’t pay attention the losses can become immeasurable. So it is important to keep yourself safe and to paint a more clear picture.

We’ll look at the security standing of 13,000+ Magento stores and elaborate on our workflow for security patch installation and give you detail on the most common path vulnerabilities.

Security standing of 13,000+ Magento stores — do you pay enough attention to security while doing eCommerce?

It all started with an email from one of our future customers. Email subject was the following — “Do you perform virus checks?”

We allocated two developers to investigate the issue ASAP. Within the first minutes of the investigation, we have spotted some unknown users, and non-documented scripts that operated with customer data and transferred it further on, and 30 more lines of code with suspicious functionality. Cleaning that all up was not a simple task at that time, no guidelines, no documentation and no patches to fix it by executing a shell script.

Running a Free Magento eCommerce Security Audit

Finding one company with the security breaches, we decided to run the advanced audit for all our existing clients. In the course of time, we realised that problem with Magento security did not disappear by itself but becoming even more actual. For example, during only one month, we received 12 requests from various eCommerce stores to help with security or to perform Magento audit.

We have decided to make the free security audit for all companies that care about themselves and their customer’s data security. Today, we are ready to share complete statistics (anonymous, of course) and conclusions of done research about 13 000+ different Magento domains.

Some Magento shop owners think that it’s unnecessary to waste company budget for newly released security patch installation. Why? Since the shop works fine, or just don’t want to spend some additional development time and resources for such minor things. After all, a development team is always busy with something more urgent and important.

Rolands — Technical Support Manager:

“Unfortunately, Security Patches are often left behind, as they rarely bring new functional needed by merchants. But it is absolutely wrong, as when maintaining and building new functionality it is always best practice to build such on already patched and updated platform.
Same as patch installation is good time to re-test your platform, look into its functions and make sure that developers have not delivered any core rewrites into system. During patch installation it is routine procedure to check such things.
The worst case what you can do — is remembering about Magento patches when your website is already hacked. To our regret it happens too often and sometimes we even see that particular merchants go out of business due to such frauds. As leaving holes in site allows hackers to hijack customer credit cards for month long periods, affecting merchant reputation.”

SUPEE-5344 — SHOPLIFT BUG PATCH

So, what are the numbers, for patch 5344 by Magento? Even that all new Magento installations (both enterprise and community versions) have pre-installed 5344 patch, our statistics shows that still 5.68% of all shops are not protected from “shoplift bug”.

It’s a specific remote code execution (RCE) vulnerability known as the “shoplift bug” that allows hackers to obtain Admin access to your store. The Admin panel is vulnerable to SQL injection, which allows code to be inserted into the database and be executed. As a result, the store can be fully compromised by creating counterfeit administrator accounts and/or installing malware on the server.

SUPEE-5944 PATCH Vulnerabilities

SUPEE-5994 is a bundle of eight patches that resolve several security-related issues. Our statistics shows that 17.22% of web stores are not protected from eight different vulnerabilities, some of them are:

An attacker can force the Admin Login page to appear by directly calling a module, regardless of the URL. This exposes the Admin URL on the page and makes it easier to initiate password attacks.
Enables an attacker to obtain address information (name, address, phone) from the address books of other store customers. During the checkout process, the attacker can gain access to an arbitrary address book by entering a sequential ID.
This issue enables an attacker to obtain address (name, address, phone), previous order (items, amounts) and payment method (payment method, recurrence) information from the recurring payment profiles of other store customers.

SUPEE-6285 PATCH Vulnerabilities

By our research, there are 6.19% of Magento stores without the patch SUPEE-6285, that has severe vulnerability breaches.

SUPEE-6285 is also a bundle of patches (nine) that resolves several security-related issues. These patches are affecting Magento stores with Magento version older than 1.9 community and 1.14 enterprise editions. For example:

Improper check for authorized URL leads to customer information leak (order information, order IDs, customer details) which exposes customer email, shipping and billing address.
The redirection link on an empty cart page uses non-validated user input, which makes it possible to use URL parameters to inject JavaScript code into the page.
The vulnerability allows to include an unescaped customer name when “Wishlists” are sent. By manipulating the customer’s name, an attacker can use the store to send spoofing or phishing emails.
Cross-site request forgery in Magento Connect Manager allows an attacker to execute actions such as the installation of a remote module that leads to the execution of remote code. The attack requires a Magento store administrator, while logged into Magento Connect Manager, to click a link that was prepared by the attacker.

SUPEE-6788 PATCH Vulnerabilities

14.82%! That’s the percentage of websites that are vulnerable to major breaches — most of cases we had with security vulnerabilities were caused by missing 6788 patch. This patch was actually a trigger for this research.

SUPEE-6788 is a bundle of patches that resolve several security-related issues:

Error messages generated during the Magento installation, or during a failed extension installation, can expose the Magento configuration and database access credentials. In most cases, the database server is configured to prevent external connections. In other cases, the information can be exploited, or tied to another attack.
Email template filter functionality can be used to call blocks exposing customer information like last orders or integration passwords. While this functionality is used internally in Magento safely, we were informed about external extensions that use it to process user input like blog comments. This allows to access protected information from store front.

Scandiweb Workflow for eCommerce Security Patch Installation

Martins — Magento Solution Specialist:

First things to do when installing Magento Patches:

Download .sh patch files with specific update and for specific Magento version.
Research possible issues after patch installation. Usually, there is magento.stackexchange.com post about it (for example: Possible problems SUPEE 7405).
Check project’s behaviour before patch application. Try to test sections described in possible problem articles / posts.
Check official Magento update installation guides.
Execute patch installation using command sh patch-file-name.sh
Test project behaviour after patch installation.
After your patch application is tested and no issues are observed, commit Magento modified files into your feature branch of the ticket.

Some important notes:

Each update has requirements for previously installed SUPEE updates, if required updates not present — update cannot be applied.
On average time needed for installation of regular security updates within Scandiweb are estimated for 2.5–5 h
If something breaks in the result of patch installation, it should be reported to client about further actions needed.

Special case — SUPEE-6788 ( 404 error )

This update is special as it usually breaks most of the third party extensions that is not compatible with changes introduced by SUPEE-6788.
It changes rules for path how 3rd party extension controllers are accessed for Magento Back-end.
Most notable symptom is noticed in Magento Back-end, when opening 3rd party extension sections. If some part of the Back-end page is replaced by 404 error, you can be pretty sure it’s because of extension isn’t compatible with 6788 patch.
If, after patch installation, issues with 3rd party extensions are observed, and there is no extension compatibility updates, developer can use SUPEE-6788-toolbox. It’s set of scripts that attempts to iterate through all extensions and fix them automatically. This set of scripts usually mitigates some of manual work to fix extensions.

Special case — SUPEE-6285 ( User roles / Access denied issue)

Update breaks 3rd party extensions that are not compatible with Magento user role logic.
With this update, Magento returns access denied in Magento Back-end for extensions that does not comply with Magento user role logic.

Vulnerable paths for Magento eCommerce and other websites:

While patches have potential breaches and are endangering your store with various threats, it still requires a lot of efforts and hacking/breaching skill to do so.

With vulnerable paths it’s different! Anybody who can open the browser can get your customer data and vulnerabilities. All you have to know — standard Magento path and enter it into the browser next to your domain. Some of the most popular vulnerable paths:

downloader/index.php
app/etc/local.xml
app/etc/enterprise.xml
aittmp/index.php

We have divided all vulnerability paths into seven different groups

First group — severity 10

Let’s start with the most severe paths. Full customer data can be exposed by just accessing a link.

You just go to domain/ and add one of the following four paths:

var/log/payment_paypaluk_express.log
var/log/payment_paypal_standard.log
var/log/payment_paypal_express.log
var/log/payment_paypal_direct.log

As a result (if paths are not protected), you will get a text file, with all information about customer — as in example shown below:

It’s not a real order, but we do have Scandiweb warm socks!

What’s most frightening is a number of shops with this kind of vulnerability: 5.76% of all Magento shops have open PayPal paths!

Second group — /var/export/export_customers.csv

One more vulnerable path that has a rating 10 of severity, it works approximately the same as the previous vulnerability. But by a link, you get a .csv file (basically spreadsheet) with all customer data. Even all info is sorted out and split to tables.

Data is the same, but as an addition, you get more information about the customer like Name, Surname, Gender, Address, Billing Name, Surname (Name, Surname on your credit card), Billing Address, Phone, Mail, Company, Your ZIP, Password hash.

Also, customers cooperation with the store is exposed. Data shows to which customer group user belongs to, for example: Regular user, Retailer, Premium, Vendor, etc.

1.65% of all Magento stores have this vulnerability open.

Third group — /index.php/rss/order/NEW/new

It’s a vulnerability that is severe, and we gave it rating 8 of 10 since it takes some effort and programming knowledge to steal the data of customers.

The exploit roots are coming from using non-strict typisation in Magento:

Here is official example of vulnerability:

Pay attention on lines 95–96, that’s what makes this vulnerability possible

Example of an exploit:

By a simple line of code (5th), defining that “increment_id => TRUE” and “customer_id => TRUE” it allows hackers to get customer data and incomplete order information.

4.15% of Magento based stores have this path open and not configured correctly. In overall result, when we calculate overall vulnerability of customer data, it’s 11.56%!

Fourth group — /admin

Any of these paths open actually make your website vulnerable:

manage/
shopadmin/
management/
manager/
adminpanel/
administrator/
admin/
shopadmin/
site_admin/

The access to merchant Magento Admin panel is not closed and can be accessed by the link. That potentially exposes the security of Magento store and data; hackers can try to brute-force login/password to get access. Or get it by phishing from other services and mail servers.

Even if a merchant is sure that password is secure enough with somewhat 18 random symbols, if still makes impediments, since server resources are wasted on handling brute force attacks.

Do you need to test your luck and play with your business? Don’t think so!

22.26% — that’s the amount of web stores that have open Magento admin panel!

Fifth group — /downloader

Login to Magento Connect

It is something similar to access to admin panel, however it can be used to brute-force your Magento Admin password and install/run any code on your server. It allows you to access to Magento Connect section which allows you to install extensions directly from Back-end.

Some simple example. Hackers get access to Magento downloader and install an extension, with their code inside. It will be applied, and hackers get full access to the shop, transactions and whatever their code can do. It will be a long time when such things are detected, especially if there is no GIT installed on the project.

15.82% is total amount of web stores with /downloader open!

Sixth group — local.xml open, severity — 9

Local.xml contains credentials of your database with password, username, host and ports. Knowing all those, you can freely connect to database and do whatever the user can do. By that if you get admin access, and in most of the cases you do, then you can delete, copy, change, inject etc. Change payment methods and that’s just a top of an iceberg of how hackers can use access to Magento store database.

Rather small 2.18% number of web stores with local.xml open.

Seventh group — /magmi

Magmi Magento mass importer — a product importer offering better performance over the default Magento. This makes it a very powerful and simple, yet also dangerous tool as it effectively offers full access to your Magento webshop database. Through Magmi credentials, hackers can access full Magento store, and do whatever they like with it.

Example of magmi paths:
– magmi/web/magmi.php
– magmi/conf/magmi.ini
– magmi/

Just recently we faced a “famous” Magmi Magento hack. It’s a credit card collection hack that forwards all payment details of paying customers to the hackers.

9.06% that’s the amount of companies with open /Magmi paths.

Aftermath:

With all that being said, calculated and developed we want to encourage merchants and agencies to remain in safe Magento zone.

To make that happen, we provide a possibility to check and perform security audit for your website by the most Certified Magento developers team. Absolutely for FREE! Sign up here.

Make sure that you are among that 61% of Magento merchants that are customer friendly and safe!

Struggling with keeping your Magento eCommerce store safe? You’ve come to the right place! Scandiweb is the most certified Magento agency in the world with more than a hundred experienced coders and more than a decade of experience under its belt. We’re here to help, so if you have any questions – drop us a line at [email protected], check out our Magento eCommerce health monitoring tool MageBee, or our services page.

This article is produced by scandiweb