Heute morgen wurde ich nicht nur von starkem Schneefall überrascht sondern auch von einer E-Mail meines Kollegen Ralf der mir einen Link zu einem Heise-Artikel und einer BSI-Pressemitteilung schickte.
Inhalt der Artikel sind mit Malware infizierte Magento Shops.
Das Thema selbst ist für mich (und auch Ralf) ein alter Hut. Sicherheitslücken in Magento selbst sind nichts neues. Seit Jahren versuchen wir hier bei Veröffentlichung einer Lücke mit besonderem Drang die Lücken direkt zu schließen. Ich weiß nicht wie es euch geht, aber ich kann nicht ruhig schlafen, wenn die Lücken nicht zeitnah geschlossen werden.
Mit zeitnah meine ich - innerhalb von 24h - nach Veröffentlichung der Patches. Und mit Patchen meine ich nicht, dass der Patch im Source-Code eingespielt und getestet wird. Der Patch sollte natürlich auch in Produktion gehen. Das hört sich selbstverständlich an, ist es aber nicht.
Kontrolle über viele Projekte
Bei netz98 habe ich dazu ein Tool entwickelt. Wir nennen das Tool „Project Control Center“. Der Zweck ist das globale Aggregieren von Daten aus diversen anderen Systemen an einer Stelle. Ein Punkt dabei sind die eingespielten Patches in einem System. Diese lesen wir direkt aus dem „master“ Branch des GIT Repositories aus.
Interessant wird das ganze dann erst in Verbindung mit einer angelegten Patch-Datenbank.
Sobald ein Patch veröffentlicht wird, hat dies bei netz98 immer Priorität. Wir lassen dann alle Feature-Entwicklungen erst einmal liegen und spielen zuerst den Patch ein. Entwickler und Projektleiter arbeiten gemeinsam daran den Patch so schnell wie möglich in die Produktionsumgebung zu bekommen.
Im Project-Control-Center können wir dann alle Projekte im Überblick behalten und feststellen bei welchen Systemen noch kein Patch eingespielt wurde.
Ablauf eines Patch-Tages
Da wir alle Projekte zeitgleich (Kunden mit Support-Vertrag zuerst) aktualisieren, fallen Probleme meist schnell auf und können im Haus direkt unter den Entwicklern geteilt werden. Ein Standardproblem ist, dass die Patches oft den Downloader von Magento betreffen. Da wir den Downloader schon seit Jahren aus dem Shop aus Sicherheitsgründen entfernt haben, schlägt das Einspielen manchmal fehl. Der Patch wird angepasst und dann wieder den anderen Entwicklern zur Verfügung gestellt. Die Patches selbst halten wir ebenfalls unter Versionskontrolle. Damit bleibt alles nachvollziehbar. Zusätzlich sind wir bekannt dafür, dass wir Shops mit vielen automatisierten Tests abdecken. Nach dem Einspielen eines Patches wird die gesamte Test-Suite des Kundenprojekts automatisch gestartet. Mögliche Problem fallen hier meist schnell auf. Auch hier gilt es zu priorisieren. Selbst wenn noch kleinere Problem im Shop durch einen eingespielten Patch aufschlagen, wird der Patch trotzdem im Regelfall in Produktion genommen. Das Motto lautet hier: Safety first
Ursachen für Sicherheitslücken
Nun zu dem vom BSI genannten Patch. Ich hatte Eingangs geschrieben, dass dies ein alter Hut ist. Bisher waren wir mit keinem Kundenprojekt betroffen. Die Wahrscheinlichkeit, dass ein Kundensystem durch die im BSI-Artikel genannte Malware betroffen sein wird, ist äußerst gering. Wir beschrieben sind wir immer sehr aktuell mit dem Patchen der System. Zusätzlich wird die Shop-Version auf dem Server oft ersetzt da wir durch einen automatischen Rollout immer neue Versionen in Betrieb nehmen. Selbst wenn ein Angreifer Quellcode auf dem Server manipulieren würde, würde dieser also nicht lange auf dem Server verweilen da er mit dem nächsten Deployment durch eine neue Version ersetzt werden würde.
Wie kommen nun solche Problem zustande? Wie können mehr als 1000 Magento Shops alleine in Deutschland von solchen Problemen betroffen sein?
Der Grund ist äußerst banal: Shopbetreiber kalkulieren kein Geld für den Betrieb und die Wartung des E-Commerce Systems ein. Oft wird am falschen Ende gespart. Die Balance zwischen Weiterentwicklung und Stabilisierung ist nicht gegeben.
Ich selbst habe schon eine Menge solcher Online-Shops im Rahmen von Analysen gesehen. Es ist immer wieder das gleiche Bild anzutreffen:
- Die Magento Version ist stark veraltet
- Es sind sehr viele Drittmodule installiert
- Es wird keine Software-Versionskontrolle (z.B. GIT oder SVN) eingesetzt
- Rollouts sind nicht automatisiert
- Die PHP Version auf den Servern ist nicht aktuell
- Das Betriebssystem der Produktionsumgebung wird nicht aktualisiert (Uptime >300 Tage und keine neuen Linux-Kernel-Patches)
- Es werden unsachgemäße Änderungen am Magento-Core vorgenommen
- Es gibt keine richtige Qualitätssicherung
- Modulanpassungen werden direkt im Produktivsystem vorgenommen
- Es existiert kein Staging-System um Dinge zu testen
Mein Fazit
Das sind erstmal die Dinge die mir direkt eingefallen sein. Ein professioneller E-Commerce Betrieb ist aus meiner Sicht nur möglich, wenn alle Punkte hier erfüllt werden.
BSI-Präsident Arne Schönborn wird wie folgt zitiert:
“Leider zeigt sich nach wie vor, dass viele Betreiber bei der Absicherung ihrer Online-Shops sehr nachlässig handeln. Eine Vielzahl von Shops läuft mit veralteten Software-Versionen, die mehrere bekannte Sicherheitslücken enthalten.”
Ich kann ihm hier nur zustimmen. Aus meiner Sicht müssten Shopbetreiber hier viel mehr in die Pflicht genommen werden. Ob Strafen hier ein geeignetes Mittel sind, kann die Politik beantworten. Ein professioneller E-Commerce Betrieb ist nur mit geeignetem und erfahrendem Personal möglich. Wer nicht selbst über die notwendigen Ressourcen verfügt sollte sich hier professionelle Unterstützung einkaufen. Gute Magento Agenturen lassen sich nach kurzer Recherche durchaus finden.
Das waren erst mal meine zehn Cent zu diesem Thema.
Mich würde hier gerne eure Meinung interessieren…