Aus dem Nähkästchen: Sicherheitsupdates für Magento 1

Der Juni naht in großen Schritten und damit neigt sich auch unser erstes Mage One-Jahr dem Ende zu.

Ich nehm Euch mit auf eine Reise durch die Fragen und Antworten zu: „Wie kann man Magento 1 nach dem Support-Ende noch sicher weiter betreiben?“ Das war nämlich die Frage, mit der alles anfing. Und „Komm, wir übernehmen den Support“ … „Aber, wie eigentlich?“

Schon zwei Jahre!

Was für ein Jahr! Eigentlich sind es sogar schon zwei Jahre, da sich die Mage One-Gründer fast auf den Tag genau im Mai 2019 zum ersten Mal gezielt gemeinsam trafen, um das Konzept für die Idee “wir machen Support für Magento 1“ festzuzurren. Wenn man die Fotos von diesem Tag betrachtet, mutet es merkwürdig an, weil wir einfach so in einem Lokal saßen, ohne Masken und Tests, das Wort "Corona” nur bei Bierbestellungen bekannt.

Im Mai 2019 begann die Mage One-Idee also real und konkret zu werden. 2020 wurde sie dann wirklich real und SEHR konkret. Und jetzt, 2021, liebäugeln wir mit dem Wort “Routine” und bezeichnen uns als alte Patchhasen.

Vor dem Start

2019 überlegten wir also, wie es möglich ist, Patches für Magento 1 herzustellen und trafen uns zum “Workshop”-Treffen über ein paar Tage, um all die Randparameter festzustecken, die es braucht, wenn man etwas ernsthaft betreiben will:

• Was kommen für Kosten auf uns zu?
• Wie sieht die rechtliche Lage aus?
• Darf man das überhaupt?
• Wie sieht unser Preismodell aus?
• Gründen wir eine GmbH?
• Wer macht was?
• Wie kommen wir an die Sicherheitslücken?
• Wie und wie oft kommunizieren wir am effektivsten?

Kurz danach gründeten wir die GmbH, denn das Ziel war, unser ganzes Augenmerk auf die Sicherheit von Magento zu richten ‒ völlig ernsthaft und nicht als Mal-Schaun-Was-Wird-Hobby.

Die Zeit bis zum tatsächlichen End of Life-Datum am 30.06.2020 verbrachten wir mit dem Bau unserer Buchungs- und Download-Plattform, mit der Auswahl eines Zahlungsanbieters, Steuerberaters, Anwalts, Personal, dem Aufbau eines Bug Bounty-Programms, der Entscheidung für eine Ticketplattform für Kundenfragen und noch einer Ticketplattform, nachdem die erste sich als unpraktisch erwiesen hatte, dem Partneraufbau und dem spaßigen Unterfangen einer Kontoeröffnung.

Einiges war von Anfang an sehr durchdacht, einiges betrachteten wir eher “agil”, da uns klar war, dass Erfahrungen sammeln ein nicht unwesentlicher Bestandteil des Ganzen war. Denn immerhin planten wir etwas anzubieten, das es noch gar nicht gab: unbekannte Sicherheitslücken.

Der Start

Wir hatten uns, um das ganze so halbwegs anschubfinanzieren zu können, ausgedacht, dass wir unseren Kunden gegen einen gewissen Preisnachlass, die Möglichkeit bieten, schon vor Juli Verträge abzuschließen. Und dann passierte im Grunde: nichts. Oder relativ wenig. Wir wussten nicht, ob das, was wir da vorhatten, tatsächlich einen Bedarf darstellt. Wir fanden die Idee immer noch gut, aber braucht das vielleicht doch niemand?

Und so saßen wir da, auf den Kalender starrend, der dann in Zeitlupe irgendwann auf den 1. Juli 2020 umschlug ‒ paddaaaaam ‒ und dann ging es los. Aber so richtig. Denn dann kamen die Vertragsabschlüsse so zahlreich, zusammen mit den Supporttickets, dass wir uns fühlten, wie bei einem Waldbrand mit Gießkännchen.

Was uns anfangs überraschte: Es kamen sehr viele Enterprise-Kunden auf uns zu. Näher betrachtet war es jedoch logisch, dass diese ein deutlich höheres Sicherheitsbewusstsein haben, da es bei ihren Shops ja auch um deutlich mehr Kundendaten und um deutlich höhere Verluste, im Falle eines Hackerangriffs geht.

Ebenfalls erstaunte uns, dass es viele Shops gab, die ihren Shop nicht mit dem letzten Magento-Update betrieben oder nicht alle bis dato zur Verfügung stehenden Patches installiert hatten. Aus Sicherheitssicht verwunderlich, aber aus praktischer Sicht nicht, da es den Anschein hatte, dass viele die Magento-Updates eher als Feature-Updates verstanden hatten, denn als Sicherheitsupdates. Das Never-Change-A-Running-System war ein nicht von der Hand zu weisender Aspekt.

Der Weg

Wir hatten uns im Vorfeld lange überlegt, wie weit wir testen. Testen wir nur die letzte Magento Version (1.9.4.5) oder auch ältere? Vielleicht bis zur Version 1.7 zurück? Testen wir ungepatchte Shops? Testen wir Shops unter allen PHP-Versionen und wenn ja, mit welcher beginnen wir? Wie umfangreich sollen unsere Patches sein? Packen wir alle Lücken in einen Patch oder machen wir einzelne? Veröffentlichen wir sie, sobald eine Lücke gefixt ist oder sammeln wir sie?

Ein Stein, der uns kurz im Weg rumlag, war das Bug Bounty-Programm. Eigentlich wollten wir das Programm von Magento übernehmen, aber da gab es dann doch allerlei lizenzrechtliche Hürden, sodass wir uns entschlossen ‒ da wir auch bereits einen guten Kontakt zu “den Hackern” hatten ‒ ein eigenes Bug Bounty-Programm mit entsprechender Plattform aufzuziehen. Wir waren sehr erleichtert, dass das so gut angenommen wurde ‒ und auch, dass es nicht einen großen Schub an Lücken gab und danach verebbte, sondern nach wie vor Lücken gemeldet werden. Die Sportlichkeit und Finesse, mit der die “Hacker” Lücken ausmachen, erstaunt und freut uns nachhaltig und immer wieder. Es begeistert, einen Blick in diese Hirne werfen zu können, die auf so abwegige Gedanken kommen, die dann tatsächlich einen Shop lahm legen können.

Eine andere, lange hin und her gewälzte Überlegung, war, wie die Laufzeit der Verträge aussehen soll. Die Hacker sollen ja auf jeden Fall wissen, dass sie weiter suchen sollen und dass wir immer genügend finanzielle Ressourcen haben, ihre Hirntätigkeit zu bezahlen. Daher hatten wir uns für ein Abomodell entschieden mit Laufzeiten von einem Jahr. So war sichergestellt, dass wir in jedem Fall mindestens ein Jahr lang die Bug Bounty-Prämien finanzieren können, da wir um die Einnahmen wissen. Ebenfalls wollten wir kleinen Shops ermöglichen, den Service in Anspruch zu nehmen, sodass wir die Preise umsatzbezogen machten und die Einstiegspreise entsprechend niedrig.

Eine Frage, die eine unfassbar große Relevanz bekam, war die “PCI-Frage”. Im Grunde die Frage, ob die Richtlinien für Anbieter von Zahlungsschnittstellen (PCI), es ermöglichten, unseren Service als Teil der geforderten Standards anzuerkennen. Hier ist gefordert, dass die Shopsoftware von dem “Vendor”, also dem “Anbieter”, mit Sicherheitsupdates versorgt wird. Definiere “Anbieter” war also die Folgefrage, mit der sich alle rumschlugen. Die wurde im Grunde niemals wirklich beantwortet. Einige sagten: “ja klar, Mage One ist der Anbieter von Sicherheitsupdates”. Einige sagten: “Nein, nein, Mage One ist ja nicht Magento”. Es gibt aber nach wie vor Zahlungsschnittstellen zu Magento, die weiterhin auf Sicherheit und Aktualität ihrer Schnittstellen bedacht sind ‒ und darüber sind wir sehr froh.

Einige davon gehören zu unseren Partnern. Das bedeutet, dass sie auch unsere Patches immer “aus erster Hand” erhalten, um diese mit ihrer Software gegenzuprüfen. Im Gegenzug geben uns unsere Partner Bescheid, wenn sie einen Angriff wahr nehmen.

Heute

Nach dem großen Run im Juli 2020 begann unsere erste große Welle (um pandemisch zu sprechen). Es folgte tatsächlich noch eine zweite, als ein Angriff auf Magento 1-Shops über den sogenannten “Downloader” erfolgte. Dieser hatte eine gewisse mediale Aufmerksamkeit und dadurch war das Sicherheitsbedürfnis von Shopbetreibern nochmals geschärft.

Auch heute, ein Jahr danach, gibt es immer noch zahlreiche Shopbetreiber, die neue Verträge abschließen. Denn, so wie Weihnachten und die DSGVO überraschend plötzlich kamen, so kam auch das End Of Life von Magento 1 für viele allzu plötzlich. Hinzu kam, dass die Agenturen, Programmierer und Freelancer nicht die Ressourcen hatten, alle Shops zeitnah auf ein neues System zu migrieren. Viele hatten noch gar keine Entscheidung getroffen, was das System der Wahl sein sollte und wieder andere wollten erstmal ihre Investitionen in den bestehenden Shop amortisiert wissen, bevor sie ein neues Projekt planen. Daher war auch überraschenderweise für viele die Entscheidung für einen weiterführenden Sicherheitssupport gar nicht in zeitlicher Nähe zum End of Life treffbar.

Ein Beispiel: Wunschlisten-Patch

Einige Shop-Probleme werden uns auch von Shopbetreibern genannt. So erreichten uns z.B. E-Mails mit der Information, dass ihr Shop erheblichem Formular-Spamming ausgesetzt war. Irgendwer verwendete also ein Formular im Shop und versendete über dieses E-Mails an zigtausend Adressen. Einige Shops wurden daraufhin von ihrem Hoster (nicht maxcluster!) gesperrt, bei anderen landete die E-Mail-Adresse auf einer Blacklist, so dass sie über die Haupt-E-Mail-Adresse gar nicht mehr erreichbar waren. Wir haben uns das Problem angesehen und festgestellt, dass das Wishlist/Wunschlisten-Formular verwendet wurde. Erstaunlicherweise wurde ein Formular verwendet, das man erst versenden konnte, wenn man ein Kundenkonto hat und eingeloggt war. Erste Hilfe war also erstmal: Wunschliste abschalten. Da viele Shops diesen "Merkzettel" aber gerne nutzen, haben wir einen Patch erstellt, der die Systemkonfiguration um die Option erweitert, das Formular auszublenden und ein Versenden darüber zu unterbinden.

Morgen

Einige Fragen hatten wir gar nicht in unserem Fokus. Eine davon war, wie lange wir das eigentlich machen wollen. Für uns war klar: solange Bedarf da ist. Wir merkten schnell, dass das für unsere Kunden eine allzu schwammige Aussage war, die dem Sicherheitsbedürfnis komplett widerspricht. Daher haben wir uns entschieden, unseren Service für mindestens 5 Jahre anzubieten, also bis mindestens 2025.

Ob es dann noch Lücken geben wird? Davon gehen wir aus. Es werden vermutlich weniger werden, aber es ist ja nie die Frage, ob ein System gehackt wird, sondern wann. Und wir tun alles dafür, dass das “wann” erst dann eintritt, wenn wir keine Kunden mehr haben.

Definitionen

• Patches: korrigieren Fehler in bestehenden Programmen, ohne, dass das ganze Programm neu installiert werden muss. Es werden also nur Wunden oder Fehler verändert. Patchen bedeutet daher sowas wie “flicken”.
• Support-Ende: meint keinen Kundensupport, sondern meint den Umstand, dass sich ein Unternehmen aktiv um die Aufrechterhaltung der Qualität einer Software kümmert, also auch um deren Sicherheit.
• Bug Bounty-Programm: Mit Hilfe von “Kopfgeldern” (Bounty) wird das Auffinden von Sicherheitslücken (Bugs) bezahlt. Programmierer (oder “Hacker”) versuchen ein System zu hacken und wenn ihnen das gelingt, bieten sie die Sicherheitslücke zum Kauf an. Sie erhalten dann eine Auszahlung, die sich an der Schwere der Lücke orientiert.

Zur Person: Carmen Bremen ist Freelancer (neoshops.de), Developer für Shopware und Magento, Speaker, Magento Master 2017/18/19 und gehört zum Organisationsteam der MageUnconference.

Bild: Mage One

Veröffentlicht am 28.05.2021 | NM