SQL-Injection in PrestaShop-Modulen: So erkennen Sie gefälschte Administratoren

Sie öffnen die Mitarbeiterliste im Backoffice und sehen Konten, die Sie nicht angelegt haben. Manchmal eines, manchmal mehrere hintereinander, mit ähnlichen E-Mail-Adressen und alle mit dem Profil SuperAdmin. Niemand hat sich mit Ihrem Passwort angemeldet: Ein Programm hat sie direkt in die Datenbank geschrieben und dabei ein Modul mit einer SQL-Injection-Lücke ausgenutzt.

Es ist eines der häufigsten Angriffsmuster gegen PrestaShop. Sehen wir uns an, wie es funktioniert, wie man es erkennt und was zu tun ist.

Was eine SQL-Injection in einem Shop ist

Ein Modul erhält einen Wert aus der Anfrage (eine ID, einen Suchtext, einen Filter) und fügt ihn ungeprüft in eine Datenbankabfrage ein. Kommt statt der erwarteten Zahl ein Stück SQL an, führt die Datenbank es aus. In PrestaShop ist die Grundabwehr einfach: in eine Ganzzahl umwandeln, was eine Zahl sein soll, und durch pSQL() schicken, was Text ist. Das Problem: Nicht alle Module tun das an all ihren Eingängen.

Am gefährlichsten sind die Front-Controller der Module: öffentliche URLs, ohne Anmeldung erreichbar, gedacht für den Warenkorb, eine Ajax-Suche, einen Filter oder die Rückkehr von einem Zahlungsanbieter. Hat einer davon die Lücke, kann sie jeder im Internet ausnutzen.

Wie eine typische Kampagne abläuft

1. Massenscan. Ein Bot durchsucht Tausende Shops nach Modulen mit bekannten Schwachstellen. Er wählt Sie nicht gezielt aus: Es reicht, dass die verwundbare Version installiert ist.
2. Ausnutzung. Er sendet die Anfrage, die ein INSERT in die Mitarbeitertabelle einschleust, oder ein UPDATE, das ein bestehendes Konto auf ein höheres Profil hebt.
3. Serie. Da der Bot nicht weiß, ob es geklappt hat, wiederholt er es. Deshalb findet man oft mehrere fast gleichzeitig angelegte Konten mit fortlaufenden IDs.
4. Spätere Nutzung. Mit dem Konto meldet sich jemand im Backoffice an, installiert ein Modul, das in Wirklichkeit eine Hintertür ist, ändert die Daten einer Zahlungsart oder schleust einen Skimmer in das Checkout-Template ein.

So erkennen Sie es in ps_employee

Die Mitarbeitertabelle (mit dem Präfix Ihres Shops, meist ps_) ist klein und leicht zu prüfen. In phpMyAdmin oder dem Datenbankwerkzeug Ihres Hostings:

SELECT id_employee, firstname, lastname, email, id_profile, active, last_passwd_gen FROM ps_employee ORDER BY id_employee DESC;

Worauf Sie achten sollten:

• id_profile = 1 ist das SuperAdmin-Profil. Zählen Sie, wie viele Sie haben und ob Sie alle kennen.
• Fortlaufende IDs am Ende der Liste, die niemand aus Ihrem Team angelegt hat.
• E-Mail-Adressen, die nicht zu Ihrer Domain gehören oder generische Namen tragen.
• Leere oder wiederholte Vor- und Nachnamen, die eine Anlage über das Backoffice nicht zulässt.
• last_passwd_gen mit Datumsangaben, die zu keiner Anlage passen, an die Sie sich erinnern.
• Alte Konten mit geändertem Profil: ein Mitarbeiter aus der Logistik, der plötzlich SuperAdmin ist.

Prüfen Sie bei derselben Gelegenheit auch die Webservice-Konten (Erweiterte Einstellungen → Webservice). Ein neuer API-Schlüssel mit Schreibrecht auf die Konfiguration ist eine Tür, die das Ändern aller Passwörter überlebt und im Mitarbeitermenü nicht auftaucht.

Was tun, wenn Sie eines finden

1. Noch nicht löschen: deaktivieren. Setzen Sie das Konto auf inaktiv und sichern Sie seine Daten. Sie brauchen sie, um herauszufinden, seit wann es existiert und was es getan hat.
2. Prüfen Sie, was verändert wurde. Kürzlich installierte Module, Änderungen an der Konfiguration der Zahlungsarten (IBAN für die Überweisung, Schlüssel des Zahlungsanbieters), Checkout-Templates, Mitarbeiter und Webservice sowie die URLs des Shops.
3. Suchen Sie nach neuen Dateien. Üblicherweise wurde mit dem Zugang eine Hintertür auf der Festplatte hinterlassen. Vergleichen Sie Core und Module mit ihren Originalpaketen.
4. Finden Sie das verwundbare Modul. Die Zugriffsprotokolle des Servers zeigen meist seltsame Anfragen an einen Modul-Controller kurz bevor das Konto auftaucht. Dieses Modul muss aktualisiert oder entfernt werden.
5. Ändern Sie die Zugangsdaten: die Passwörter aller Mitarbeiter, die Webservice-Schlüssel und, falls es Hinweise gibt, dass die Konfiguration gelesen wurde, das Datenbankpasswort.
6. Gleichen Sie die letzten Bestellungen mit der Bank oder dem Zahlungsanbieter ab, falls Geld umgeleitet wurde.

Warum Vorbeugung Module aktualisieren heißt

Massenkampagnen nutzen fast nie unbekannte Lücken. Sie nutzen veröffentlichte Schwachstellen, für die oft schon seit Monaten ein Patch verfügbar ist. Der Bot funktioniert, weil viele Shops ihre Module nicht aktualisieren oder weil das verwundbare Modul von seinem Autor aufgegeben wurde und niemand es ersetzt hat.

Einige konkrete Maßnahmen:

• Bestandsliste der Module mit Version und Herkunft. Zu wissen, was Sie haben, ist der erste Schritt, um zu wissen, was Sie betrifft, wenn eine Warnung erscheint.
• Aktualisieren Sie zuerst in einer Kopie und dann im Live-Shop, aber aktualisieren Sie. Ein Modul, das zwei Jahre nicht aktualisiert wurde, ist ein Glücksspiel.
• Entfernen Sie, was Sie nicht nutzen, einschließlich der Ordner deinstallierter Module, die noch auf der Festplatte liegen.
• Verfolgen Sie die Sicherheitshinweise von PrestaShop und den Autoren Ihrer Module.
• Halten Sie PrestaShop und PHP auf unterstützten Versionen. Viele Module erhalten für alte Versionen keine Patches mehr: Läuft Ihr Shop noch auf 1.6 oder einer frühen 1.7, steigt mit jeder neuen Warnung die Wahrscheinlichkeit, dass es für Sie keine Lösung gibt, und die Migration wird auch zu einer Sicherheitsmaßnahme.

Eine Web Application Firewall kann einen Teil der Versuche bremsen, ersetzt aber nicht den Patch: Es gibt viele Varianten derselben Injection, und es reicht eine, die durchkommt.

So lösen Sie es in PrestaShop

RKR Security Alert speichert einen Schnappschuss der Mitarbeiter, Module, Konfiguration, Shop-URLs und Webservice-Konten und vergleicht ihn bei jedem Laden des Backoffice und per Cron mit dem aktuellen Zustand. Deshalb erkennt es einen per SQL-Injection angelegten SuperAdmin, auch wenn dabei kein Hook durchlaufen wurde, und meldet ihn über Telegram als höchste Warnstufe, getrennt vom Rest; ebenso, wenn ein bestehendes Konto zum SuperAdmin hochgestuft wird oder ein neues Webservice-Konto erscheint. Sein Scanner enthält einen SQL-Injection-Analysator, der Werte aus der Anfrage markiert, die ohne Umwandlung oder Escaping in eine Abfrage gelangen. Wenn Sie bereits einen Verdacht haben oder der Vorfall schon da ist, übernehmen wir mit einem Rekire-Support-Stundenpaket das Audit, finden das Modul, über das der Angreifer hereinkam, bereinigen alles und bringen den Shop auf den aktuellen Stand.