Out of the box: security updates for Magento 1

June is fast approaching and with it our first Mage One year is coming to an end.

I'll take you on a journey through the questions and answers to: "How to keep Magento 1 running safely after support ends?" Because that was the question that started it all. And "Come on, we'll take over the support" ... "But, how actually?"

Two years already!

What a year! Actually, it's been two years already, since the Mage One founders first specifically met together almost to the day in May 2019 to nail down the concept for the idea "we do support for Magento 1". Looking at the photos from that day, it seems strange because we were just sitting like that in a pub, without masks and tests, the word "Corona" known only when ordering beer.

So in May 2019, the Mage One idea started to become real and concrete. Then in 2020, it became really real and VERY concrete. And now, in 2021, we're flirting with the word "routine" and calling ourselves old patches.

Before the launch

So in 2019, we considered how it would be possible to make patches for Magento 1 and got together for a "workshop" meeting over a few days to nail down all the boundary parameters it takes to run something seriously.

• What kind of costs are we looking at?
• What is the legal situation?
• Is it even allowed to do that?
• What is our pricing model?
• Do we form a limited liability company?
• Who does what?
• How do we get to the security holes?
• How and how often do we communicate most effectively?

Shortly after that, we founded the GmbH, because the goal was to focus all our attention on Magento security - completely seriously and not as a paint-by-numbers hobby.

We spent the time leading up to the actual end of life date of 6/30/2020 building our booking and download platform, choosing a payment provider, tax advisor, lawyer, staff, building a bug bounty program, deciding on a ticketing platform for customer questions and yet another ticketing platform after the first one proved impractical, partner building, and the fun endeavor of opening an account.

Some things were very well thought out from the beginning, some things we considered more "agile", as it was clear to us that gaining experience was a not insignificant part of the whole thing. After all, we were planning to offer something that didn't even exist yet: unknown security holes.

The start

In order to be able to finance the whole thing halfway, we thought of offering our customers the possibility to sign contracts before July in exchange for a certain discount. And then basically nothing happened. Or relatively little. We didn't know whether what we had in mind actually represented a need. We still thought it was a good idea, but maybe nobody needs it after all?

And so we sat there, staring at the calendar, which then flipped in slow motion at some point to July 1, 2020 - paddaaaaam - and then it started. But really. Because then the contract signings came in such numbers, along with the support tickets, that we felt like we were in a forest fire with a watering can.

What surprised us at first was that a lot of enterprise customers were coming our way. On closer inspection, however, it was logical that they would have a much higher level of security awareness, since their stores also contain significantly more customer data and incur significantly higher losses in the event of a hacker attack.

We were also surprised that there were many stores that did not operate their store with the latest Magento update or had not installed all the patches available to date. Surprising from a security point of view, but not from a practical point of view, as it seemed that many had understood the Magento updates as feature updates rather than security updates. The never-change-a-running system was a no-brainer.

The way

We had thought long and hard in advance about how far we would test. Do we test only the latest Magento version (1.9.4.5) or also older ones? Maybe back to version 1.7? Do we test unpatched stores? Do we test stores under all PHP versions and if so, which one do we start with? How extensive should our patches be? Do we put all the gaps in one patch or do we do individual ones? Do we release them as soon as a gap is patched or do we collect them?

One rock that briefly got in our way was the Bug Bounty program. Actually, we wanted to take over the program from Magento, but there were all kinds of licensing hurdles, so we decided - since we already had good contact with "the hackers" - to set up our own bug bounty program with a corresponding platform. We were very relieved that this was so well received - and also that there wasn't a big surge in bugs and then it ebbed away, but bugs are still being reported. The athleticism and finesse with which the "hackers" spot gaps amazes and delights us enduringly and repeatedly. It thrills to be able to take a peek into those brains that come up with such far-fetched ideas that can then actually cripple a store.

Another consideration, which was tossed around for a long time, was what the duration of the contracts should look like. We wanted the hackers to know that they should keep searching and that we would always have enough financial resources to pay for their brainwork. Therefore, we decided on a subscription model with terms of one year. This ensured that we would be able to fund Bug Bounty premiums for at least one year in any case, knowing that we would have the revenue. Likewise, we wanted to enable small stores to take advantage of the service, so we made the prices revenue-based and the entry prices correspondingly low.

One question that became incredibly relevant was the "PCI question." Basically, the question of whether the guidelines for payment interface providers (PCI), allowed our service to be recognized as part of the required standards. Here it is required that the store software is provided with security updates by the "vendor", i.e. the "provider". So define "vendor" was the follow-up question everyone was struggling with. It was basically never really answered. Some said, "yeah sure, Mage One is the security update provider". Some said, "no, no, Mage One is not Magento". But there are still payment interfaces to Magento that continue to be concerned about security and keeping their interfaces up to date - and we are very happy about that.

Some of them are among our partners. This means that they also always receive our patches "first hand" to cross-check them with their software. In return, our partners let us know when they notice an attack.

Today

After the big run in July 2020, our first big wave (to speak pandemic) began. It was actually followed by a second one, when an attack on Magento 1 stores occurred via the so-called "downloader". This had a certain amount of media attention and as a result, the need for security among store operators was once again heightened.

Even today, one year later, there are still many store operators who sign new contracts. Because, just as Christmas and the DSGVO came surprisingly suddenly, the End Of Life of Magento 1 also came all too suddenly for many. In addition, the agencies, programmers and freelancers did not have the resources to migrate all stores to a new system in a timely manner. Many had not even made a decision on what the system of choice should be and others wanted to see their investments in the existing store amortized before planning a new project. Therefore, surprisingly for many, the decision for continued security support was not even close to the end of life.

Example: Wish List Patch

Some store problems were also reported to us by store operators. For example, we received e-mails informing us that their store was subject to considerable form spamming. Someone used a form in the store and sent e-mails to thousands of addresses. Some stores were then blocked by their hoster (not maxcluster!), others had their email address blacklisted so that they could no longer be reached via their main email address. We looked into the problem and found that the Wishlist form was being used. Surprisingly, they were using a form that you couldn't send until you had a customer account and were logged in. So first help was first: turn off wishlist. But since many stores like to use this "wish list", we created a patch that adds the option to hide the form and prevent sending via it to the system configuration.

Tomorrow

Some questions we didn't have in our focus at all. One of them was how long we actually want to do this. For us it was clear: as long as there is a need. We quickly realized that this was an overly vague statement for our customers, completely contradicting the need for security. We therefore decided to offer our service for at least 5 years, i.e. until at least 2025.

Will there still be gaps then? We assume that there will be. There will probably be fewer, but it's never a question of whether a system will be hacked, but when. And we're doing everything we can to make sure that "when" doesn't happen until we no longer have any customers.

Definitions

• Patches: correct bugs in existing programs without having to reinstall the whole program. So only wounds or errors are changed. Patching means therefore something like "mend".
• Support end: means no customer support, but means the circumstance that a company cares actively for the maintenance of the quality of a software, thus also for its security.
• Bug Bounty program: With the help of "bounties" (bounty) the finding of security holes (bugs) is paid. Programmers (or "hackers") attempt to hack a system and if they succeed, they offer the vulnerability for sale. They then receive a payout based on the severity of the gap.

Personal details: Carmen Bremen is a freelancer (neoshops.de), developer for Shopware and Magento, speaker, Magento Master 2017/18/19 and part of the organizing team of the MageUnconference.

Image: Mage One

Published on 28.05.2021 | NM