Web Shells in PrestaShop: was sie sind, wo sie sich verstecken und wie Sie sie finden

Wenn jemand in einen Shop eindringt, stiehlt er fast nie als Erstes. Als Erstes sorgt er dafür, dass er zurückkommen kann. Dafür hinterlässt er eine Web Shell: eine PHP-Datei, die ihm beim Aufruf per URL erlaubt, Ordner aufzulisten, Dateien zu bearbeiten, Datenbankabfragen abzusetzen oder Befehle auf dem Server auszuführen. Selbst wenn Sie die Schwachstelle schließen, über die er hereinkam, und alle Passwörter ändern, bleibt er damit drin.

In diesem Artikel geht es darum, wie sie aussehen, wo sie sich in PrestaShop einnisten und wie Sie danach suchen, ohne sich in Fehlalarmen zu verlieren.

Was genau eine Web Shell ist

Ein kleines Programm in derselben Sprache wie der Shop, das mit den Rechten des Webbenutzers läuft. Es muss nichts weiter ausnutzen: Wenn der Server in diesem Ordner PHP ausführt, funktioniert die Shell. Es gibt sie in vielen Größen:

• Einzeilige Loader. Dreißig oder vierzig Bytes, die nur eine andere Datei einbinden. Der Schadcode steckt in dieser anderen Datei, die oft eine Bildendung trägt.
• Vollständige Dateimanager. Eine Oberfläche, um auf dem Server zu navigieren, zu bearbeiten, hochzuladen, umzubenennen und zu löschen, geschützt durch ein Passwort, das in der Datei selbst steht.
• Befehlsausführer. Sie nehmen einen Parameter entgegen und reichen ihn an das Betriebssystem weiter.
• Ganze Module. Ein Ordner mit der Struktur eines PrestaShop-Moduls, einer tadellosen Hauptdatei und der Nutzlast versteckt in einem Controller.

Wo sie sich in PrestaShop verstecken

Der Angreifer sucht Stellen, an denen eine neue Datei nicht auffällt. In PrestaShop gibt es einige Klassiker:

Zusätzliche Dateien in Standardmodulen

Eine ajax.php oder config.php im Ordner eines offiziellen Moduls, das diese Datei im Originalpaket nicht hat. Niemand schaut in die Module, die mit dem Shop kommen, und der Name wirkt, als wäre er schon immer da gewesen. Erkennen lässt sich das nur, indem man den Ordner mit dem Paket vergleicht, das sein Autor veröffentlicht hat.

Verwaiste Module

Ordner deinstallierter Module, die noch auf der Festplatte liegen. Sie erscheinen nicht im Modulmanager, niemand aktualisiert sie, und ihr PHP bleibt per URL erreichbar. Sie sind ein bequemes Versteck und zugleich ein Einfallstor.

Der Core und vendor/

Eine Zeile, angehängt ans Ende einer Core-Datei (die Produktklassen, der Dispatcher, der Autoloader) oder einer Bibliothek in vendor/. Viele Scanner schließen vendor/ aus, weil es viele Treffer erzeugt, und genau deshalb ist es ein guter Ort. Bei echten Vorfällen wurden in legitimen Dateien ein und desselben Shops mehr als ein Dutzend Hintertüren gefunden, alle am Ende angehängt und ohne ein einziges verdächtiges Wort im Blickfeld.

Bilder mit PHP darin

Ein vollkommen gültiges JPEG oder PNG, das sich in jedem Bildbetrachter öffnen lässt, mit PHP-Code am Ende. Für sich allein wird es nicht ausgeführt; das übernimmt ein Loader, der es einbindet. Wenn Sie also eines finden, suchen Sie auch das andere.

Datenordner

upload/, download/, img/ oder translations/ sollten nie eine ausführbare .php enthalten. Taucht eine auf, gibt es keine harmlose Erklärung.

Wie sie sich tarnen

Die Shells, die monatelang überleben, sind nicht die, die eval(base64_decode(...)) herausschreien. Es sind die, die wie normaler Code aussehen:

• Sie tragen den Lizenzkopf von PrestaShop, kopiert aus einer anderen Datei, mit Kommentarblock und Versionsprüfung am Anfang.
• Sie heißen wie etwas Harmloses: uninstall.php, index.php, cron.php oder mit einem Titel, der von einem QR-Code-Leser spricht.
• Sie setzen die Namen gefährlicher Funktionen zur Laufzeit zusammen, aus einzelnen Buchstaben einer langen Zeichenkette. Im Text taucht keine verbotene Funktion auf.
• Sie antworten mit 404, wenn sie nicht den richtigen Schlüssel bekommen, genau wie eine URL, die nicht existiert. Den Shop nach Pfaden abzufragen findet sie nicht.
• Sie behalten das Änderungsdatum der Originaldatei, damit sie beim Sortieren nach Datum nicht auffallen.

Wie Sie gezielt danach suchen

Die Reihenfolge zählt. Gehen Sie vom Eindeutigsten und Günstigsten zum Aufwendigsten:

1. Ist sie identisch mit dem, was der Autor veröffentlicht hat? Vergleichen Sie den Core mit dem offiziellen ZIP Ihrer exakten Version (dem des Releases, nicht dem Repository, das Entwicklungsordner enthält und Hunderte falscher Abweichungen erzeugt) und jedes Modul mit seinem Paket. Eine Byte für Byte identische Datei ist nicht infiziert.
2. War sie im Paket? Was nicht drin war, hat jemand später hinzugefügt. Diese Frage findet Dateien, die kein Muster erkennen würde, weil sie tadellos geschrieben sein können.
3. Hat sie sich seit dem letzten Mal geändert? Wenn Sie eine Integritäts-Baseline aus der Zeit haben, als der Shop sauber war, ist jede Änderung ohne zugehöriges Update eine Antwort.
4. Was kann sie? Für alles ohne Referenz: Verzeichnisse auflisten und Dateien mit einem per Parameter übergebenen Pfad schreiben, Befehle ausführen, Systemdateien lesen, Passwörter, die mit einem im Code selbst gespeicherten Hash verglichen werden.
5. Von wo ist sie erreichbar? Ein Controller unter controllers/front/ eines Moduls ist aus dem Internet ohne Sitzung aufrufbar; einer unter controllers/admin/ verlangt eine Mitarbeitersitzung. Das entscheidet, ob Sie heute Nacht oder morgen handeln müssen.

Und eine Regel gegen das Rauschen: Wenn Sie etwas als sicher markieren, dann über den Hash des Inhalts, nicht über den Pfad. Eine Ausnahme nach Pfad deckt diese Datei auch noch an dem Tag, an dem jemand sie austauscht.

Warum Löschen nicht reicht

Die Shell zu löschen ist der letzte Schritt, nicht der erste. Bevor Sie sie anfassen:

• Sichern Sie eine Kopie des Shops im aktuellen Zustand, um zu wissen, was sie getan hat und seit wann.
• Prüfen Sie, ob weitere Türen offen sind. Schlüssel in authorized_keys der Serverkonten, neue Mitarbeiter im Backoffice, Webservice-Konten mit weitreichenden Rechten und geplante Aufgaben, die alle paar Minuten etwas herunterladen und ausführen. Eine Datei zu löschen schließt weder einen SSH-Schlüssel noch einen Cronjob.
• Finden Sie den Einstiegsweg. Ein verwundbares Modul, ein gestohlenes FTP-Passwort, eine ungepatchte PrestaShop-Version. Wenn Sie ihn nicht schließen, ist die Shell in wenigen Tagen zurück.
• Ändern Sie die Zugangsdaten nach der Bereinigung, nicht vorher: Datenbank, FTP, Hosting-Panel, Mitarbeiter und den Cookie-Schlüssel, wenn Sie vermuten, dass die Konfiguration gelesen wurde.

Und wenn alles sauber ist, das Übliche: PrestaShop, PHP und Module aktuell halten. Die überwiegende Mehrheit der Einbrüche nutzt Lücken, die in Versionen längst behoben sind, die der Shop nicht installiert hatte.

So lösen Sie es in PrestaShop

RKR Security Alert durchsucht die Dateien des Shops nach Skimmern, Hintertüren und Web Shells, auch nach solchen ohne gefährliche Signaturen: Es erkennt Shells an dem, was sie können, Loader, die ein Bild einbinden, in gültigen Bildern verstecktes PHP und Dateien mit per Index zusammengesetzten Funktionsnamen. Es vergleicht den Core mit dem offiziellen ZIP, gibt bei jedem Fund an, ob er per URL und ohne Sitzung erreichbar ist, und führt eine Integritäts-Baseline, die erst angelegt wird, wenn Sie das erste Audit als geprüft bestätigen, damit eine bereits vorhandene Infektion nicht als sauber gilt. Es meldet sich über Telegram, speichert die Warnungen im Shop und schickt keine Datei vom Server weg. RKR Sentinel ergänzt die Überwachung und meldet PHP-Fehler, 500-Antworten und Zahlungen, aus denen keine Bestellung wird, oft das erste sichtbare Anzeichen dafür, dass etwas verändert wurde.