Magento Arbitrary File Upload Vulnerability: What You Need to Know

by Tim Reynolds

Magento Arbitrary File Upload Vulnerability: What You Need to Know

by Tim Reynolds

by Tim Reynolds

Recently the fine folks over at DefenseCode published a security advisory regarding a severe Magento arbitrary file upload vulnerability. You can find that advisory here:

High Risk 0-day Vulnerability Found in Magento eCommerce

I wanted to take a moment to address this vulnerability, clarify some things they stated, and clear up any confusion for the community. This will be a quick article, I won’t go into the nitty-gritty technical details as they are covered in the advisory. Instead we will break it down for the average merchant.

Question 1: Are you vulnerable?

The answer to this is simple: Almost certainly not. What is not clearly stated in the advisory is that this ONLY affects Magento 2. Which is to say, if you are running any version of Magento 1, which most of you at this time would be, you are not affected by this in any way and can carry on. Of course, if you run Magento 1 and don’t apply your patches, you are probably at risk of any number of other more serious vulnerabilities! If you have any questions about whether your Magento site is up to date, please reach out to us. We would love to help. 

If you are running Magento 2 (ideally at the time of this writing you are running Magento 2.1.6, released March 27th, 2017), then you are only vulnerable in a few scenarios. Herein is where a lot of confusion seems to be coming. Either, but not both, of these conditions must be met to exploit this issue:

  1. You have a low-security Admin account (easy to guess Username AND Password), and have setup your Administration panel on an easy to guess URL (/admin, /manage, /control). If this is the case and someone is able to gain access to your administrative panel, then they will be able to exploit this by modifying the description of a product and including a link to a Vimeo video as described in the advisory.
  2. You have inexplicably disabled the on-by-default security setting of adding secret keys to all URLs in the Administration panel (note: DO NOT EVER DO THIS! If you think you need to do this, you are probably wrong. Reach out to us and we can advise), and after doing that, you were able to be tricked into visiting a malicious site that includes Javascript that will exploit the Vimeo video issue from the vulnerability. Note, for this exploit they will also need to have figured out what the Admin URL is for your site, which should not be easy unless you allow it to be. 🙂

Given that those are some very hard to achieve requirements, it is not likely your site will be exploited by this vulnerability at this time.

Question 2: Is this a real vulnerability?

The answer to this is a resounding YES. Although the possibility of exploitation is low right now, this issue does need to be resolved. There are a number of ways this can be resolved, but to us at Envalo we would prefer downloaded files never be dropped into any path that can be executed, to begin with. If possible, I would have downloaded the file into the /tmp location of the server or into some location under /var which would not be able to be executed at any point. After validating the file type, you would then move it over to a location that can be read. Additionally, the code that downloads the files should validate on file name as well. Although you can easily put a .jpg extension on a PHP file (many of the PHP viruses/malware we encounter do this very thing to hide themselves), you would never get the .htaccess file needed for execution there in the first place. If this is not fixed now, then there could come a time in the future where it is much easier to exploit.

Question 3: Was this a responsible disclosure of the vulnerability?

The work of the security community is paramount to keeping our online world running. They do the hard work of analyzing hundreds of thousands to millions of lines of very complex code to find vulnerabilities that require at times insanely difficult maneuvering to exploit. With the recent high-profile vulnerabilities found in things like OpenSSL (HeartBleedLogJam, DrownAttack), there seems to be a shift toward making security disclosures more… cool? Everything gets its own name. Everyone wants their vulnerability to hit the main news channels. And why not? It brings a lot of recognition to the problem and to the people who put the time in to find them. It’s human nature to crave recognition.

The downside to this has been the over-sensationalizing of more mundane vulnerabilities. Now, DefenseCode didn’t give this a clever name or make a stand-alone site to promote it, but they did state a few things that I didn’t agree with that definitely make this seem much worse than it really is.

First, they stated that Magento is powering over 200,000 online retailers pretty clearly up front. This is true, but only for Magento 1 at this time. The loosest estimates for live sites currently running Magento 2 are around 10,000. This information was taken from the site https://trends.builtwith.com. This to me serves to make the threat seem much greater than it is, however it could just be standard Magento copy that they include in their reports.

Second, they stated that this affects Magento versions 2.1.6 and below. This, combined with the fact that they fail to specifically indicate that this issue is only affecting the Magento 2 product family, further muddles the details of the actual surface area affected by the issue. A person unfamiliar with Magento, even if they are very technical, would rightly assume that an install at version 1.9.3 would be vulnerable, which is not the case. The accurate reporting on this should have stated that the vulnerable versions are from 2.0.0 – 2.1.6.

Third, they should not have indicated that the risk here is high. If exploited, yes, this is very bad, but the path to exploitation is so unlikely that rating it a High seems, to us, excessive. We will admit, however, we do not currently know the criteria used in their rating system.

In the end, they found an issue that nobody else seemingly had and for that we should thank them. We all make mistakes and hopefully learn from them. So, if you find any mistakes in my post, please let me know!

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Top