In a previous article (Mage.jpg Malware Derivative) we discussed an interesting evolution we were seeing in the eCommerce security arena, that of asymmetric encryption techniques being used to obfuscate harvested payment card data. This is something that became prevalent many years prior with binary malware created for brick and mortar compromises.
How Asymmetric Encryption is Used in Magento Malware Attacks
The use of asymmetric encryption techniques makes the role of a digital forensic analyst somewhat tricker as we cannot (generally) provide any empirical insight into the contents of the harvest files. As such, the details of the exposure have to take a "worst case" approach which generally impacts the victim's organisation detrimentally.
Anyway, back on topic. In the past couple of weeks we have come across the dropper and installer components of this same malware. Illustration 1 below gives a high level depiction of the deployment process and it is clear from the operation of the components that the malware is completely focused on Magento installations. The dropper, which needs to be introduced to the environment through an initial exploitation, has a number of functions that it is responsible for, some of which seem counter intuitive for malware.
- Enable error reporting
- Remove the .htaccess file of a "media" directory below the document root
- Create a "protected" backdoor in the "skins" directory called "skins.php". This backdoor code is embedded within the dropper as a base64 encoded string.
- Create the main malware installer, also in the "skins" directory named "test1.php". The installer code is also embedded within the dropper as a base64 encoded block.
Random "message" strings are displayed to inform the attacker of the successful (or unsuccessful) creation of the installer and the backdoor code. It is assumed that the "messages" are random strings in an effort to make the dropper more difficult to detect, as plain text error messages might be easily identified, but this is obviously supposition though.
The first action of the dropper is unusual for malware that generally attempts to maintain a degree of stealth, but the second action to remove the .htaccess file would lift any access or security controls applied to that directory. The backdoor that is created is extremely simple and executes arbitrary commands presented to the page, provided a specific cookie is also presented. The contents of the cookie are hashed with the MD5 algorithm before a comparison is made. With the backdoor available, the attacker(s) have a free passage back to the system should the original vulnerability be closed.
The installer code that is produced is a fully automated, remotely controlled installer for the main malware sample that implements the asymmetric encryption. Amusingly the malware actually contains the Magento licence depicted below.
The installer creates the directory "adminhtml/default/default/images" unless it already exists and attempts to find files that follow a naming pattern that it maintains. Matching files are used as a template to create a similarly named file which would become the harvest output file. The installer is careful to make sure the timestamp of the original file that was used as the template is also applied to the newly created harvest file, presumably in an effort to make it blend in further.
Once a harvest file had been selected (created) the installer iterates through a list of filenames that are presented below. These file contents are then read by the installer and searched for a previous "infection". The means by which this test is performed its unusually simple compared with the rest of the installer, but effectively ensures that multiple infections are not applied. If a previous infection is found the installer simply displays the message '[exists]'.
+ '../includes/config.php'
+ '../app/Mage.php'
+ '../index.php'
+ '../app/code/core/Mage/Core/Controller/Front/Action.php'
+ '../app/code/core/Mage/Core/functions.php'
+ '../lib/Varien/Autoload.php'
With a suitable file selected for modification, the file's timestamps are recorded after which the malware's main code (including the public key and asymmetric encryption) it inserted into the file. Once the changes are saved, the previously saved timestamps are reapplied in an attempt to make sure the changes remain unnoticed as long as possible. At this point the installer displays '[suc]' or '[fail]' to the attacker as appropriate. The attacker may then instruct the installer to delete the intermediary files -- something it would seem wasn't done for the sample we have.
Once in place the modified core Magento files would harvest payment card details to the harvest file, encrypted with the the public key that is embedded within the malware.
Attacker exploits site and uploads dropper
Dropper removes security controls on media directory
Dropper produces back-door and installer
Installer inserts harvesting code into Magento core files
Attacker instructs installer to self delete
Subscribe to our Blog
