One of the most important aspects of security to get right is keeping software updated. This is true when talking about applying Windows updates on your home device, and it is true if you’re responsible for looking after the IT infrastructure of a large enterprise.
It is also important if you are an e-Commerce merchant. This particular post will explore how patching works in relation to Magento, but some of the basic principles will apply to other content management systems and e-Commerce platforms such as WordPress and OpenCart. We’ll also go over the implications of Magento patching for web developers, and for other PCI Forensic Investigators (PFIs) and consultants trying to get to grips with Magento patching.
First, it is worth noting that in order to be PCI DSS compliant on Magento, you must not use Magento 1 as this went end-of-life in June 2020. We have come across merchants who believed that because they had updated to the last released version of Magento 1, or because they had used third-party updates from organisations that claim to be able to keep Magento 1 installations PCI compliant, they were doing what they needed to do to stay compliant. Unfortunately, this is not the case. This can have serious repercussions for smaller merchants, as this will prevent them from being eligible for a PFI Lite in the event that payment card data is stolen from their site. Any security updates for an e-Commerce platform need to come from the official vendor of that platform (this is Adobe in the case of Magento).
How do I know which patches have been installed?
If you have had previous experience using Magento 1, then you might be aware of the “applied.patches.list” file, which showed the patches present. This file does not exist in Magento 2, so you will need to try alternative methods. Which methods work depend upon the methodology your developer has used to patch the site. If they simply update to the next quarterly release, you should be able to check the Magento version by logging into the admin panel and scrolling to the footer at the bottom of the page, which by default will show you your current stable Magento version. If you have installed a theme which removes this footer, then you could also go to Magento Connect Manager. The “Mage_All_Latest” entry in the “Package Name” column will show you which Magento version is in place.
Security-only updates and patches are also available, which allow merchants to stay secure without needing to immediately go to the next full version. A web developer might install these via Composer, which is a tool used to easily install PHP programs on a system. There is a file in Magento webroot directories called “composer.json”, which contains easy to read information generated by Composer. This should contain the details of any security patches and updates applied using Composer.
Some web developers will choose to download patches as ZIP files and install them manually. This can make it more difficult to find out which patches have been installed on your site, as these will not be added to the “composer.json” list. Some developers choose to maintain a “patches” directory which will contain the install files, while others maintain a separate list. It’s worth checking with your developer if they are keeping an eye on what patches you already have and which you’ll soon need to have. Remember that for the purposes of PCI compliance, it is your responsibility as the merchant to make sure your site is secure, so it is in your interest to ensure that any web developer you use is applying the necessary patches and knows what they need to do to help keep your site compliant.
What should I expect from my web developer?
The exact responsibilities of web developers will of course vary slightly given that different developers will have different contracts with different terms and conditions. Many merchants will have contracts in place with their web developer which specify that the developer has responsibility for patching as part of maintaining the website. If you have such a contract, you should expect your developer to be aware of which patches should be applied on your site now, and they should have a plan in place to address any patches which are due to be released. It is also useful for web developers to understand that it is a PCI DSS requirement for critical security patches to be implemented within one (1) month of release.
How do I keep a site PCI compliant?
When communicating with web developers, we have sometimes found there to be a lot of confusion regarding what the PCI standards actually are and how they might impact the work that developers of e-Commerce websites actually do. This can lead to particularly ugly outcomes where merchants have been hit with large penalty fees from the payment card brands, and have found that their developer had not done enough to keep the website compliant. Some merchants have gone so far as to take legal action against their developer for breach of contract. This tends to come about because, while many web developers are experts in particular e-Commerce platforms and the many benefits they bring to merchants, they are not as familiar with the regulatory environment they are working within.
Fortunately, there are resources available that will help web developers understand what they need to do to avoid the sort of situation described above. Of particular interest is PCI Requirement 6 (Develop and Maintain Secure Systems and Applications), which is the requirement that imposes the need for fully patched e-Commerce systems.
Requirement 6.2 states that critical security patches need to be installed within one (1) month of release. All security patches should also be vendor-supplied (i.e. Adobe for Magento). Any third-party patches or patches you develop and implement yourself are not acceptable for this purpose as far as the card brands are concerned. Even if you believe that they provide equivalent (or even better) fixes than those released by the actual vendor, this won’t be accepted, and your merchant will be deemed to not be compliant.
Another requirement that is worth being aware of is PCI Requirement 2 (Do Not Use Vendor-Supplied Defaults). If you are implementing an e-Commerce platform that has some default usernames or passwords, then you should make sure these are removed before the site goes live. Other requirements might have more or less importance depending on your contractual obligations. For example, if you have agreed to take on responsibility for the firewall, then being aware of Requirement 1 would be a good idea.
What patches should I install and when?
To start with, when we’re discussing patches, we specifically mean those that address security vulnerabilities. There has been confusion about this in the past, where web developers have believed they have met patching requirements, only to find that the patches they had implemented were performance enhancements or other improvements that had no relation to security at all.
The answer to the question is straightforward: you need to update security patches as soon as possible after they are released, within one month at the latest.
Having an understanding of how Magento patches are implemented is vital for any investigator or consultant working with a Magento-based merchant. It will help when auditing the PCI compliance of a merchant. It will also help investigators to establish what vulnerabilities would have been present at the suspected time of a breach.
How do I audit a Magento 2 store in terms of security patching?
There are different ways in which this can be done depending on how patches are applied to the store in question. A review of the “composer.json” file should show any patches that were installed using Composer, or a review of files present within the Magento installation can also be undertaken (but note that if a developer is applying hotfixes, then there’s no default installation location).
Third-party tools such as Magescan and MageReport will run vulnerability scans against a site to determine the level of patching and will flag if there are any patches missing. Note that web application firewalls will probably interfere with this, so you will need to ensure that your client has allowlisted the IP addresses you run your scans from before proceeding.
How do Magento patching versions work?
Up until recently, security fixes for Magento were released in the full quarterly updates, and only by upgrading to these quarterly versions could a site be kept secure and PCI compliant. This system was changed in 2019 as many merchants were delaying full quarterly updates to avoid breaking changes.
Now, security-only patches are available which provide the security benefits of the full quarterly update, but don’t include performance and quality enhancements. These security patches are released with the suffix “p1”, as in Magento 2.4.1-p1. While Magento 2.4.1-p1 is not the same as Magento 2.4.2, it contains the same security fixes and therefore offers equivalent security. This is true for most Magento 2 releases with the “p1” suffix, and this should be checked for when auditing a Magento store to avoid mistakes in assessing compliance.
There is an important exception to this. Magento 2.3.5-p1 is actually a quarterly release, not a security patch. This is due to the pre-release version of Magento 2.3.5 containing a major bug which had to be fixed prior to the full release. This bug change was different enough from the original version that Magento decided to add the “p1” suffix to it. As a result, Magento 2.3.5-p1 doesn’t actually offer equivalent security to Magento 2.3.6. The correct security only patch to achieve this is Magento 2.3.5-p2. If you see any “p1” version in future, then you should check the Magento release notes for that version as this will tell you whether it is a normal security only patch or not.
A large number of the Magento stores investigated by the 3B Data Security PFI team are found to not have been fully patched when they were breach. More widely, research from the industry in 2019 found that the largest risk to smaller merchants was attackers looking to exploit a lack of critical security patches on their stores, and this is certainly backed up by our anecdotal experience.
It is important to remember that attackers are opportunistic and will normally try to pick on easy targets. A small merchant with fewer resources to defend their e-Commerce environment are considered easy targets. Rather than try to attack specific sites, attackers will normally search the Internet for sites that contain known vulnerabilities. If they come across a site which has vulnerabilities that they know how to exploit, then they will try to attack that site and ultimately steal payment card data from it. This process is nearly always run with automated scripts. While this is a big problem for merchants, applying security patches in a timely fashion will protect against these attacks. It’s a simple enough solution to many of the threats that a Magento store will face, and yet it often seems to be overlooked, resulting in unnecessary stress and worry for so many businesses.
Merchants should also make sure that there is someone with the clear responsibility for keeping the website patch. Some contracts will specify that developers are responsible for the initial development of the site, but not necessarily ongoing maintenance. As a merchant, you should check the contract you have (which will help you fulfil PCI Requirement 12.8.5) to make sure that patching is specified as a responsibility for the developer. The main reason that patches seem to be so often missed is a genuine misunderstanding on the part of web developers. Sometimes they haven’t fully understood what the PCI requirements really mean, or in other cases they haven’t fully understood how the Magento patching versions work. These are all easy mistakes to make, and many merchants and developers have told us that they feel that there isn’t enough information available to help them understand what they need to do. There are links included at the end of this post which will hopefully point merchants and developers in the right direction.
If you need any assistance with the points raised in this post, or have any security needs more generally, then please get in touch with 3B Data Security.