Magento, a popular e-commerce platform, has a vulnerability which allows attackers to upload arbitrary files through a chain of vulnerabilities that can lead to the possibility of an attacker uploading and executing arbitrary files.
Researchers from security testing company DefenseCode discovered the vulnerability during the security audit of Magento Community Edition. The vulnerability could potentially lead to remote code execution and as a result expose the system including the database containing sensitive customer information like stored credit card numbers and other sensitive information.
The vulnerability was discovered in November 2016, and after being disclosed to Magneto was published as an advisory by DefenceCode. It seems that even though the vulnerability was disclosed almost half a year ago, the latest version of Magento is still unpatched.
The Chain of Vulnerabilities
The researchers wrote that “when adding Vimeo video content to a new or existing product, the application will automatically retrieve a preview image for the video via POST request taking a remote image URL parameter.” The request is protected against cross site request forgery (CSRF) attacks by including a token which is checked. However, when the HTTP method is changed to GET, the CSRF token is not checked.
To take advantage of the vulnerability, the attacker needs to send a link to or lure the Magento administrator to a malicious website. In both situations it will contain the CSRF link which for example could be through an invisible iFRAME, or through an image request.
The files are checked by Magento to verify that they are indeed images and not anything else (Like a backdoor). However, after checking the image, it is not removed from disk, and is still stored, and may be accessed from the web. The files are stored in directories according to their first two letters. For example an image named test.php will be uploaded to the directory /pub/media/tmp/catalog/product/t/e/test.php.
In order to allow execution of the files, a custom .htaccess file also needs to be uploaded to the same directory. Magento would store that file in the directory /pub/media/tmp/catalog/product/_/h/.htaccess.
Note that it replaces the dot “.” with an underscore “_”. So if the attacker uploads both .htaccess and .hXXXXXX.php, he now has access to an active backdoor at .hXXXXXX.php.
Through that file, the attacker can upload additional files, read details from other files, send spam, or even access the site’s database.
So What Can I do to Protect Myself?
If you are an Incapsula client, and have Illegal Resource Access rules in blocking mode, the exploit attempts will be blocked automatically.
Our security research group gets vulnerabilities information from two main sources:
- Suspicious traffic going through our CDN, which is analyzed in order to find new attacks
- Security intelligence
In this case we got the information from our security intelligence sources, and started to analyze the vulnerability to write rules that would block this attack. It was relatively straightforward, since the report by DefenseCode is very thorough and shows the exact vulnerability. We often have cases where we may need to recreate environments, compare sourcecode diffs and other variables.
When we prepare rules to block such vulnerabilities, we usually create several rules. We then run them in parallel in silent mode on our network, so that we can also see if there are more variants to such attacks.
We run the rules for a certain period of time in silent mode to lower the risk of blocking false positives (legitimate traffic). The next step is move them to blocking mode across our CDN.
If you are not protected by Incapsula, and are using Magento, we recommend that you both patch your software as soon as there’s a new security update, and block any GET requests to ADMIN_DIRECTORY/product_video/product_gallery/retrieveImage.
Is Someone Already Testing for this Vulnerability?
So far, we had the vulnerability tested only on 10 of our clients. The low number is due to the fact that this vulnerability is relatively new, and that it requires a CSRF, which means that the site administrator needs to be logged in when getting a malicious link.
We’ll keep you updated if we see any other developments.
Try Imperva for Free
Protect your business for 30 days on Imperva.
