01 · Aufgabe
Aufgabe
Der Inhaber eines WooCommerce-Shops erfuhr von Kunden von dem Problem: Bei der Zahlung erschien ein zusätzliches Fenster, das nach Kartendaten fragte. So arbeitet ein Skimmer: ein in den Shop eingeschleustes Skript, das beim Kauf die Daten von Zahlungskarten abfängt und an die Angreifer schickt, während die Bestellung normal durchläuft, sodass niemand etwas bemerkt. Der im Shop installierte Virenscanner meldete einige verdächtige Dateien, aber ihr Löschen änderte nichts. Es galt festzustellen, wie der Angreifer Zugang bekommen hatte, was er genau getan hatte und wie viele Bestellungen über die manipulierte Zahlung gelaufen waren, und das in einer Form aufzubereiten, die der Anwalt des Kunden für die Meldung an die Datenschutzbehörde nutzen konnte.
02 · Lösung
Lösung
Ich habe mit den Server-Logs begonnen, nicht mit den Dateien. Der zeitliche Ablauf zeigte eine Serie von Anfragen an einen Endpunkt der WordPress-API, über den die Angreifer eine kurz zuvor veröffentlichte Lücke im Kern ausnutzten, Administratorkonten anlegten und ohne Passwort ins Backend kamen, über gefälschte Sitzungscookies. Einige Tage später schleuste eine der Gruppen den Skimmer ein. Nicht in Dateien, sondern in ein Einstellungsfeld eines Plugins zum Einfügen von Skripten, gespeichert in der Datenbank. Deshalb hat der Dateiscanner ihn nicht gesehen.
Weitere Schritte:
- Ich habe alle Dateien des WordPress-Kerns mit der offiziellen Version verglichen und den Server auf fremde Dateien geprüft: keine Webshells, die Meldungen des Scanners waren Fehlalarme,
- die Konten der Angreifer gelöscht, das Feld mit dem Skimmer geleert und alle Schlüssel und Passwörter ausgetauscht, für Backend, Datenbank und Anmeldesitzungen, wodurch gestohlene Zugangsdaten unbrauchbar wurden und jede angemeldete Person abgemeldet wurde,
- festgestellt, warum der Shop die Updates nicht ausgeführt hatte: Zwei Mechanismen für automatische Updates blockierten sich gegenseitig. Das habe ich behoben und geprüft, ob Sicherheitsupdates wieder laufen,
- auf der Firewall eine Regel hinzugefügt, die den im Angriff genutzten API-Endpunkt blockiert, und Plugins mit bekannten Lücken aktualisiert,
- aus den Logs das tatsächliche Zeitfenster des Skimmers und die Zahl der betroffenen Bestellungen bestimmt und geprüft, ob es Spuren eines Abzugs der Kundendatenbank gab.
03 · Ergebnis
Ergebnis
Der Shop verkauft wieder, mit sauberem Code, funktionierenden Updates und blockiertem Angriffsvektor. Der Anwalt des Kunden erhielt Material mit einem konkreten Zeitfenster und der Liste der betroffenen Bestellungen statt Vermutungen, was die Benachrichtigung auf die tatsächlich betroffenen Kunden begrenzte. Wie ich bei solchen Fällen vorgehe, beschreibe ich unter Malware aus WordPress entfernen.