We checked 30,000 Magento stores for three publicly available vulnerabilities that are sometimes found in older Magento installations. Despite the most recent of the three vulnerabilities being fixed over a year ago, a considerable percentage of web stores are still vulnerable.
Lately, we have been focusing on Magento security and the most common mistakes made by online retailers. To dig deeper, we went through some old publicly available Magento vulnerabilities that will be explained in more detail later in this post.
The interesting thing about these security issues is that they have been patched for at least a year. We knew that some do not regularly update their system, so we expected a few to be vulnerable, but it is interesting to see what the actual numbers tell us.
The vulnerabilities we looked at here were not discovered by us and we do not want to give the impression that doing the research was a hard thing to do. In fact, it is how easy it was to get these numbers that is concerning.
Please observe that it is probably even worse in reality. The most interesting vulnerabilities cannot be checked for without breaking the law, but chances are there are much worse vulnerabilities out there that can be automated.
We checked the most popular web sites in the world according to Alexa ranking and picked out about 30k web sites that were running Magento. This means that the tested sites are not some hobby installation that has been forgotten, but actually active web stores.
In short, to test for these issues we requested three different paths on all sites with the result and details presented below.
This was a configuration file containing the hidden path to the admin panel as well as the database password in plaintext. As it is an .xml-file in the web root, the default behaviour for a web server is to serve this file when requested. Magento solved this by also including a .htaccess file to prevent anyone from access this file.
Figured out the problem yet? .htaccess is only supported by Apache while Magento can be installed on other web servers, such as nginx. Nginx will ignore the .htaccess file and therefore gladly serve the configuration file to anyone who requests it.
This behavior was changed years ago, so instances vulnerable against this have not been updated in quite a while.
Even when this file existed Magento screamed at you if you published it publicly, so for this mistake to happen you would have to ignore a security warning.
So how many are affected? Out of the 30k web stores that we scanned, about 500 have this configuration file fully available for anyone to request. Around 20% of those in turn have port 3306 open.
This issue was brought up by Hanno Böck during Sec-T, which inspired us to look for it.
This vulnerability was patched in 2015, and yet 1,500 out of the 30k tested sites are vulnerable to it.
This is an API for order history. The problem is that there was no authentication server-side whatsoever. Anyone could send a request to it, no need to even log in. The exposed data is order history, that means which customer bought what and when. Names and addresses, the sum of orders and dates, amongst other things.
Keep in mind that we are talking about 1500 relatively popular web stores, so the amount of customer data that is publicly available is massive. By just crawling these public files one could build a very scary data leak.
Exposing the admin panel under something as easy to guess as /admin is far from a best practice. As people have a tendency to choose weak passwords, or to even re-use them, this can lead to a dangerous situation. Exposing the admin panel generates a security warning in Magento.
About 7,000 of the scanned web stores answered with an admin panel when we requested/admin. That is over 20%, or one fifth. Considering that these web stores are the biggest ones alongside the fact that the admins have intentionally ignored the security warning, one can only wonder what other best practices have been overlooked.
This number would be even higher if we included more common paths other than just /admin.
50.16% of the stores we checked did not use HTTPS per default, which is a surprisingly high percentage of our sample. Website visitors can’t be expected to manually switch to HTTPS, which is why forcing HTTPS by default is a simple precaution that prevents attackers from intercepting credit card details.
This issue is not by any means limited to Magento. We focused on Magento when testing these specific files, but everything indicates that every CMS (without auto-update support) has similar issues.
To add to this, for two of these three issues, Magento implemented security warnings that have to be ignored by admins. This is perhaps not the most well though-out situation, but Magento have done what they could do inform users of the security risks.
If it is possible to enable auto-update, do so! Keeping your system updated is the most efficient and one of the easiest way to stay secure.
If this is not possible, make it a routine to actually update the system regularly and add it to your calendar to make sure you log in and update once a month or at another interval that works for you.
Another option is to run a service such as Detectify, that of course both looks for these kinds of files and exposures but also warns you if you have not updated your system. If this post caught your interest, sign up for a free two-week trial and see whether you have also accidentally published any sensitive files (or any other kind of vulnerabilities we check for).
Is your Magento store vulnerable? Why it’s time to put security first
Magento security 101: How to secure your Magento site
GDPR Compliance Checklist for eCommerce by our friends at Divante
[VIDEO SEMINAR] Magento security from a hacker’s perspective
Have you ever wondered how a hacker would analyze and attack a Magento website? We picked the brains of two ethical hackers to find out. Linus Särud, 18, and Fredrik Almroth, 27, share their best insights and advice on Magento security to help you keep your Magento store safe from hackers.
