Magento 2 absichern: Patches, ClickFix, PolyShell und CosmicSting

Shops auf Basis von Magento 2 und Adobe Commerce sind ein dauerhaftes Ziel automatisierter Ausnutzungskampagnen. Jede neue 2.4.x-Version bringt eine Reihe von Sicherheitspatches mit, und Angreifer analysieren diese Patches innerhalb weniger Tage, um funktionierende Exploits gegen Shops zu bauen, die noch nicht aktualisiert wurden. Dieser Artikel beschreibt die wichtigsten Bedrohungen der letzten Monate, wie sich ihre Spuren auf einem Server erkennen lassen und welche konkreten Schritte zur Beseitigung und zur Vorbeugung des nächsten Eindringens führen.

Warum ungepatchte 2.4.x-Installationen das Hauptziel sind

Adobe veröffentlicht in regelmäßigen Abständen Sicherheitshinweise für Magento Open Source und Adobe Commerce, und jeder Hinweis listet die in dieser Version behobenen Schwachstellen auf. Der Abstand zwischen der Veröffentlichung eines Patches und dem Erscheinen eines öffentlichen Proof of Concept wird heute in Stunden gemessen, nicht in Wochen. Ein Shop, der auf einem älteren Patchstand bleibt, betreibt faktisch bereits veröffentlichte und bewaffnete Schwachstellen. Die erste Gegenmaßnahme ist daher immer dieselbe: den Kern auf die neueste sichere Version aktualisieren und alle offiziellen Patches und Hotfixes für den eigenen Zweig einspielen.

ClickFix: die gefälschte Mensch-Verifizierung

ClickFix ist eine Social-Engineering-Technik, die Magento nicht direkt ausnutzt, sondern das Vertrauen der Besucher in eine vertraute Oberfläche missbraucht. In einem kompromittierten Shop wird die Kasse oder die Landingpage so verändert, dass ein gefälschtes Cloudflare-Widget mit der Aufforderung 'Bestätigen Sie, dass Sie ein Mensch sind' erscheint. Der Besucher setzt das Häkchen genau wie auf einer echten Prüfseite, und ein Skript wird still in die Zwischenablage geschrieben. In diesem Moment geschieht nichts Schädliches, und die Seite wirkt möglicherweise sogar völlig normal.

Die Gefahr entsteht im zweiten Schritt. Die gefälschte Seite fordert den Besucher auf, unter macOS oder Windows ein Terminalfenster zu öffnen und den kopierten Inhalt zur Bestätigung einzufügen. Befolgt der Besucher dies, lädt der eingefügte Befehl eine zweite Nutzlast herunter und führt sie auf dem Rechner des Clients aus. Die Regel für Anwender ist einfach und absolut: niemals Befehle von einer Webseite in ein Terminal einfügen. Die Regel für Administratoren lautet, das eingeschleuste Skript zu finden, zu entfernen und den Einstiegspunkt zu schließen, der die Veränderung ermöglicht hat.

Kompromittierung auf Serverseite: PolyShell, CosmicSting und env.php

Mehrere Schwachstellenfamilien dominieren die Incident-Berichte zu Magento 2. PolyShell missbraucht uneingeschränkte Datei-Uploads über die REST-API, um polyglotte Dateien abzulegen, die gleichzeitig gültige Bilder und gültiges PHP sind. CosmicSting zielt auf die Template-Engine und kann zu nicht authentifizierter Remote-Code-Ausführung führen. StyleSmuggler und BlockStrap folgen ähnlichen Mustern aus Template-Injection und Filterumgehung. In den schwersten Fällen liest der Angreifer env.php, entnimmt daraus die gespeicherten kryptografischen Schlüssel und fälscht gültige Administrator-Token. Damit behält er dauerhaften Zugriff auf das Backend, selbst nachdem der verwundbare Pfad geschlossen wurde.

Verschleierten Code in app, vendor und cache aufspüren

Schadcode ist selten offensichtlich. Angreifer verstecken ihn in standardmäßigen .phtml-Templates, in Kernmodulen und in generierten Dateien der Verzeichnisse cache und var. Eine einfache Textsuche nach gängigen Schlüsselwörtern liefert oft nichts, weil die Nutzlast zur Laufzeit aus base64-Zeichenketten oder aus mehreren aneinandergehängten Fragmenten zusammengesetzt wird. In einem aktuellen Fall war eine infizierte .phtml-Datei im vendor-Ordner nur geringfügig verändert, wobei die schädliche Zeichenkette auf mehrere Variablen verteilt war.

Vergleichen Sie Ihre Installation mit einer sauberen Kopie derselben Version. Nutzen Sie eine Dateiintegritätsprüfung, prüfen Sie Änderungszeitstempel und untersuchen Sie jede Datei, die vom offiziellen Paket abweicht. Wenn Sie eine infizierte Datei finden, löschen Sie nicht einfach die Nutzlast: Stellen Sie die Originalversion aus dem offiziellen Archiv wieder her und aktualisieren oder sperren Sie anschließend den verwundbaren Pfad, der das Schreiben erlaubt hat.

pub/media darf niemals PHP enthalten

Das media-Verzeichnis ist für Bilder, PDFs und andere statische Ressourcen gedacht. Es gibt keinen legitimen Grund, warum unter pub/media eine Datei mit der Endung .php, .php7, .phtml oder .phar liegen sollte. Angreifer laden solche Dateien dennoch ständig hoch, und die beliebtesten Verstecke sind pub/media/custom_options/ und pub/media/custom_options/quote/, wo hochgeladene Optionsdateien gespeichert werden. Durchsuchen Sie diese Verzeichnisse rekursiv, entfernen Sie jede ausführbare Datei und stellen Sie sicher, dass die Upload-Konfiguration unerwartete Endungen ablehnt.

Am Rand blockieren mit Cloudflare, Nginx und Apache

Den Server zu bereinigen reicht nicht, solange der Einstiegspunkt offen bleibt. Sperren Sie die verwundbaren Pfade, bevor die Anfrage Magento erreicht. In Cloudflare können Sie eine WAF-Regel erstellen, die Anfragen an /pub/media/custom_options/ und ähnliche Verzeichnisse ablehnt oder jede Anfrage herausfordert, die eine PHP-Datei im media-Pfad erreichen will. Auf dem Ursprungsserver fügen Sie gleichwertige Regeln in Nginx oder Apache hinzu, damit der Schutz auch dann greift, wenn der Datenverkehr das CDN umgeht.

Bedenken Sie, dass eine Regel am Rand nur die Anfragen stoppt, die Sie bereits kennen. Kombinieren Sie sie mit dem Patch, mit Dateiüberwachung und mit einer regelmäßigen Prüfung der Codebasis.

Checkliste zur Bereinigung

Fazit

Magento-Sicherheit ist ein Kreislauf, keine einmalige Aufgabe. Patchen Sie schnell, prüfen Sie die Integrität Ihrer Dateien, halten Sie ausführbaren Code aus dem media-Verzeichnis heraus und sperren Sie Pfade, die Sie nicht benötigen. Wenn Sie eine ClickFix-Injection vermuten, warnen Sie Ihre Kunden sofort: Der schnellste Weg, den Schaden zu begrenzen, besteht darin, dass niemand etwas in ein Terminal einfügt.