Zufällig haben wir eine gehackte Website im Netz gefunden und dem Betreiber (in diesem Fall ein Verein) unsere Hilfe angeboten. Die Hilfe bestand zuerst in der kostenlosen Schadensanalyse, um zu sehen, wie viel Aufwand es wäre, die Website von dem Schadcode zu säubern und wieder sicher lauffähig zu machen.
Die Website war mit einem Hack infiziert, der für WordPress auch schon länger bekannt ist. Es gibt zu diesem Hack im WordPress Support Forum Einträge, die bereits mehrere Jahre zurückliegen.
Wie verhält sich die Website?
Wenn man direkt über die Eingabe der URL im Browser die Website aufruft, verhält sich diese ganz normal, die Website wird wie erwartet geladen und es sind keine Probleme ersichtlich.
Der Hack greift grundsätzlich nur, wenn man die Website über die Google Suche erreichen will. Klickt man auf die Website in den Google Suchergebnissen, wird man auf eine Spam-Seite weitergeleitet.
Dabei sind folgende Dinge interessant:
- Es wird nicht immer auf die gleiche Seite weitergeleitet
- Es wird nur ein paar Mal weitergeleitet (ca. 3 Mal), dann verhält sich die Seite wieder normal.
- Der Hack greift nicht nur auf die Startseite, sondern auch auf den Unterseiten.
- Google verlinkt in der Suche auf die richtige Domain, die Weiterleitung erfolgt dann erst auf der Seite selbst.
- Man wird auf dubiose Seiten weitergeleitet, die Browser Notifications aktivieren wollen. Ein Klick führt zur nächsten Weiterleitung und es geht immer so weiter.
- Kommt man von anderen Suchmaschinen wie bing.com, ecosia.org oder duckduckgo.com verhält sich die Website ganz normal.
Welche Schlüsse können daraus gezogen werden?
Der Hack scheint nur Traffic zu betreffen, der direkt über die Google Suchmaschine kommt. Das Ganze spricht dafür, dass irgendwo der Referrer (Herkunft des Besuchers einer Website) abgefragt wird. Die Frage ist nur, wo.
Von den schadhaften Websites, auf die weitergeleitet wird, werden Cookies gesetzt. Diese Cookies verhindern offenbar, dass bei mehrmaligem Aufruf aus Google die Weiterleitungen wieder passieren. Zusätzlich zu den Cookies werden aber vermutlich auch IP-Adressen geloggt und nach X Aufrufen über die gleiche IP-Adresse werden die Weiterleitungen nicht mehr ausgeführt. D.h. es macht den Anschein, als ob das Problem nur ein temporäres wäre und gibt den Benutzer*innen das Gefühl, dass man vielleicht irgendwo falsch geklickt hat.
Aufgrund des Verhaltens kann man folgende Theorien aufstellen, wie der Hack funktioniert:
- Weiterleitung über eine gehackte .htaccess Datei
- Weiterleitung per JavaScript
- Weiterleitung per PHP-Redirect über gehackte Seiten im WordPress (ist in diesem Fall am naheliegendsten)
Schritt für Schritt dem Hack auf der Spur.
Wie findet man nun raus, was passiert ist?
Folgende Vorgehensweise hilft, den Hack aufzudecken:
- Login via WordPress – verwende ein Passwort, das du sonst nirgendwo verwendest. Die Seite ist gehackt und kann dein Passwort mitloggen und weiterleiten. Eventuell das Passwort direkt zurücksetzen vor dem Login.
- Verbinde dich via FTP oder SSH zum Server und mach dich auf die Suche nach auffälligen Dateinamen und kryptischen Verzeichnissen.
- Durchsuche den Code nach dem Vorkommen von base64_decode oder eval. Code wird oft verschlüsselt abgespeichert und wird mit base64_decode entschlüsselt. Lade den Code dazu runter oder führe die Suche direkt am Server durch.
Achtung: Nimm die Website nicht über einen lokalen Webserver in Betrieb! Wenn du die Seite lokal startest, kann das auf deinem Rechner erheblichen Schaden verursachen, indem Dateien gelöscht, Malware downgeloadet wird oder bestehende Dateien infiziert werden.
Was ist passiert?
In unserem Fall haben uns als Erstes über FTP verbunden, weil wir über keinen WordPress Admin verfügen. Dabei haben wir am 1. Blick schon Übles entdeckt.
Im root Verzeichnis liegt schon die gehackte index.php.
Anhand des zuletzt geändert Datums der index.php haben wir eine erste Idee, wann der Hack passiert ist. In diesem Fall ist die Datei am 23.1.2023 verändert worden.
Nach Analyse mehrerer Dateien können wir den Angriff zwischen 18.1. und 23.1.2023 einordnen. Zu diesem Datum bzw. dazwischen gibt es eine große Anzahl an kryptischen Dateien, die in den WordPress Core eingeschleust wurden.
Zum einen eine gehackte index.php:
Wenn man den Code genau ansieht und versucht diesen zu entschlüsseln, sieht man, dass eine Datei unter folgendem Pfad eingebunden wird: /wp-includes/Requests/Transport/.ebfbb52c.ico
In dieser Datei befindet sich verschlüsselter PHP-Code, der über eval() ausgeführt wird.
Im root Verzeichnis entdecken wir noch weitere Dateien mit kryptischen Namen:
Wenn man sich Dateien aus dem WordPress Core ansieht, die an diesem Datum bearbeitet wurden, kann man ebenso sehen, dass hier Schadcode eingeschleust wurde.
Im nächsten Schritt werfen wir einen Blick in die Verzeichnisse des WordPress Cores und achten speziell auf ein Änderungsdatum im Jänner 2023, da hier offensichtlich der Hack passiert ist.
Die Dateien, die ein Änderungsdatum im Jänner 2023 aufweisen, sehen wir uns genauer an und finden auch hier wieder eingeschleusten Code:
In den WordPress-Verzeichnissen liegen viele Dateien mit auffälligen Dateinamen und kryptischen Inhalten, die da definitiv nicht hingehören.
Es wurde auch ein Plugin-Verzeichnis angelegt, namens „882r8005“. Dieses Verzeichnis enthält einige kryptische Dateien und Inhalte und ist wahrscheinlich der Ursprung allen Übels.
Das Datum der zuletzt geänderten Dateien passt mit dem Datum zusammen.
In einem Backup Verzeichnis finden wir aber noch eine Datei mit dem Datum 5.5.2011. In dieser Datei liegt ebenfalls Schadcode, aber vermutlich schon von einem früheren Hackerangriff.
Weiters gibt es gehackte Files und Verzeichnisse im Themes Verzeichnis, die wiederum ein anderes Datum aufweisen. Also vielleicht noch ein dritter Hack.
Wir konnten durch den Blick in die Verzeichnisstruktur schon mehrere, vermutlich voneinander unabhängige Hacks entdecken.
Aber wie sind die Hacker nun reingekommen?
Wie sind die Hacker reingekommen?
Was wir wissen:
- Der komplette WordPress Core ist verseucht mit gehackten Dateien.
- Es gibt zusätzliche Dateien, die erstellt wurden, aber auch Dateien, die editiert und mit Code verseucht wurde. Dabei ist der Code getarnt, dass man zB mit der Suche nach base64 nichts findet, weil der Code erst zur Laufzeit erzeugt wird.
- Mehr Informationen zu base64_decode unter diesem Link.
- In diesem Projekt gibt es ein Plugin, das 2 Tage vor Hackbeginn aktualisiert wurde. Es ist ein Plugin, das den WordPress Login absichern soll. Es kommt interessanterweise nicht selten vor, dass Plugins, die WordPress gegen Angreifer schützen sollen, selbst Sicherheitslücken beinhalten und Hackern dadurch Zugriff verschaffen.
- Nachdem auch in einem Verzeichnis namens themes-ai1ec-obsolete eine Datei namens wp-login.php gefunden wurde, mit ebenfalls kryptischen Inhalten, ist es nicht auszuschließen, dass über eine Sicherheitslücke im „All In One Event Calendar“, das die Abkürzung ai1ec trägt, passiert ist. Es gibt bekannte Sicherheitslücken in älteren Versionen dieses Plugins, die es möglich gemacht haben, sich Zugriff via XSS (Cross Site Scripting) zu verschaffen.
Eines ist sicher, und zwar, dass die Angreifer in diesem Fall über Sicherheitslücken in WordPress oder Plugins eingedrungen sind.
Jedes WordPress-Plugin stellt ein zusätzliches Sicherheitsrisiko dar. Darum gilt: so viele wie nötig, so wenig wie möglich installieren. Und die, die installiert sind, auf aktuellem Stand halten und am besten mit einer Software wie SYSSY auf Sicherheitslücken überwachen lassen.
Da es sich bei dieser Seite um eine Seite handelt, auf die Benutzer*innen Dateien hochladen können, ist es auch nicht auszuschließen, dass eine schadhafte Datei über ein Formular hochgeladen wurde. Im uploads Verzeichnis wurde jedenfalls eine Datei admin.php gefunden, die ebenfalls Schadcode enthält. Pugins, die es Benutzer*innen ermöglichen, Dateien hochzuladen, sind mit Vorsicht zu genießen. Es können auch zB PNG Dateien gehackt sein und Schadcode beinhalten, der schließlich am Server ausgeführt wird. Bei solchen Plugins ist es wichtig, darauf zu achten, dass die Dateien nach dem Upload umbenannt werden, damit diese nicht mit ihrem ursprünglichen Namen über den Browser aufgerufen werden können.
Nachdem auch in einem Verzeichnis namens themes-ai1ec-obsolete eine Datei namens wp-login.php gefunden wurde, mit ebenfalls kryptischen Inhalten, ist es nicht auszuschließen, dass über eine Sicherheitslücke im „All In One Event Calendar“, das die Abkürzung ai1ec trägt, passiert ist. Es gibt bekannte Sicherheitslücken in älteren Versionen dieses Plugins, die es möglich gemacht haben, sich Zugriff via XSS (Cross Site Scripting) zu verschaffen.
Was kann man machen, um die Probleme zu beheben?
Ein einfaches Update aus dem WordPress Backend hilft nicht. Macht man ein Update über das WordPress Backend macht, werden zwar Dateien überschrieben, aber zusätzliche Dateien werden nicht gelöscht. D.h. die Dateien existieren weiter und verseuchen erneut.
Die zusätzlich installierten Plugins und Themes werden durch ein Update ebenfalls nicht entfernt. Die Plugins sind im WordPress Backend vielleicht auch gar nicht sichtbar.
Außerdem gibt es noch Schadcode im uploads Verzeichnis, das von Updates nicht betroffen ist.
Unser Vorschlag:
- Eine Kopie des Projektes anlegen und die Kopie säubern – eventuell unter einer Subdomain am Server laufen lassen.
- In der Datenbank bzw. im WordPress Backend nach Benutzernamen suchen, die man nicht selbst angelegt hat. Gibt es Benutzernamen, die man nicht kennt, sofort löschen
- Den kompletten WordPress Core löschen (via FTP) und mit einem frischen ersetzen
- Alle Plugins Schritt für Schritt mit einem Plugin-Download vom WordPress Repository ersetzen. Ein einfaches Plugin-Update kann vielleicht nicht ausreichen. Vorher prüfen, ob man die Plugins überhaupt benötigt. Großes Ausmisten macht hier Sinn. Ordner mit auffälligen Namen im Plugin Verzeichnis, die nicht nach offiziellem Plugin aussehen, am besten löschen.
- Alle Verzeichnisse auf kryptische Dateien durchsuchen und diese löschen
Die Bereinigung kann sehr aufwändig sein und macht nur Sinn, wenn es die Website noch Wert ist gerettet zu werden. Eine einfache Kosten-Nutzen-Rechnung. Ist die Seite schon sehr veraltet und ist es günstiger die Seite neu zu machen, dann macht es vermutlich Sinn, die Seite neu aufzusetzen und im Zuge dessen gleich zu modernisieren und sich von allen Altlasten zu befreien.
In diesem konkreten Fall ist die Seite schon über 10 Jahre alt und weist abgesehen von dem Hack auch noch einige DSGVO-Probleme auf. Es werden außerdem Plugins eingesetzt, die seit über 10 Jahren nicht mehr aktualisiert wurden und nicht mehr supportet werden.
Mein Rat in diesem Fall wäre also, die Seite neu zu machen.
Eigentlich müsste die Seite sofort abgedreht werden, da Benutzer*innen aufgrund der Weiterleitung auf die dubiosen Seiten Schaden zugefügt werden kann. Vor allem, wenn man einen Onlineshop betreibt und es die Möglichkeit gibt, Kreditkartendaten einzugeben, sollte die Seite umgehend deaktiviert werden.
Wie kann man sich als User bzw. als Website Besucher*in schützen?
- Die Browser-Einstellungen so einstellen, dass zB Drittanbieter Cookies nicht akzeptiert werden
- Browser Extensions installieren, die solche Dinge erkennen und blockieren. Für Firefox gibt’s zB uBlock Origin, hier werden solche Weiterleitungen blockiert
- Auf keine Links klicken, wenn die Seite dubios aussieht. Am besten den Browser oder den Browser Tab gleich schließen und die Website nicht mehr besuchen. Eventuell Cookies und Browserdaten löschen.
- Stellt man als Besucher*in fest, dass eine Website gehackt wurde, sollte man umgehend den Inhaber/die Inhaberin der Website informieren
Wie kann man sich als Website Betreiber*in schützen?
Informationen, wie man die Website besser absichern kann und wie man feststellen kann, ob die eigene Website gehackt wurde, gibt es in dem Artikel Gehackte Websites erkennen und vermeiden.
Deine Website wurde gehackt?
Wir können dich bei der Bereinigung deiner Website unterstützen.
