Letzte Woche hatte es auch mich und meinem Server erwischt, dass dieser durch eine Sicherheitslücke mit Schadcode in Form eines kleinen Skripts kompromittiert wurde. Durch diesen „WordPress Redirection Hack“ wird im Allgemeinen ein Webbrowser beim Aufrufen (m)einer URL dann dazu genötigt, auf eine fremde URL zu verweisen, wo für den PC des Benutzers die eigentliche Malware zum Download bereitsteht, die den User durch weitere Angriffsformen schädigt. Es gibt da mehrere Möglichkeiten, wo so ein Skript für die Weiterleitungen versteckt werden kann. Bei mir war es die Variante, bei der ein Skript durch eine SQL-Injektion in die WordPress-Datenbank eingeschleust wurde. Konkret wurde die Entwicklung und Pflege des von mir eingesetzten WordPress-Plugins für die DSGVO-konforme Cookie-Information eingestellt. Dadurch blieb wohl mindestens eine Sicherheitslücke im Programmcode des Plugins, mit der die SQL-Injektion durchgeführt werden konnte. Bei meiner Recherche im Internet, den kompromittierenden Code im WordPress aufzuspüren, bin ich direkt auf einen guten Ansatz gestoßen, wie man bei der SQL-Injektion die fremden Schadskripte auch wieder loswird.

• Am besten eignet sich hierfür der Mozilla Firefox Webbrowser. In einem neuen, leeren Tab trägt man in der Adressleiste view-source:, gefolgt von der zu untersuchenden Website ein. In meinem Fall also view-source:https://sommteck.net. Dabei holt sich der Firefox den Quellcode der Seite, tut ihn aber nicht interpretieren und ausführen, sondern nur darstellen.

• Jetzt muss man Ausschau halten und die eingeschleusten Skripte mit den fremden URLs – auf die für die Angreifer weiter geleitet werden soll – finden. Hilfreich ist, vielleicht erstmal eine Volltextsuche über das gesamte HTML-Dokument mit dem Stichwort script durchzuführen. Mit 45 Treffern waren das gar nicht mal so viele Ergebnisse wie ich erwartet hätte. Jetzt gilt es zu prüfen, ob die mit dem HTML-Tag script versehenen URLs plausibel sind. Schon nach rund der Hälfte der Tags hatte ich auch schon eine URL auf die verwiesen wurde, die als Sub-Domain einen „store“ zugewiesen bekommen hat und als Top-Level-Domain .ga besaß. Die Top-Level-Domain .ga steht für das afrikanische Land Gabun. Ich hatte in meinem Fall zwar im Hinterkopf, dass das DSGVO-Plugin gegen Bezahlung erst noch weitere Funktionen angeboten hatte, aber auf der Homepage, beziehungsweise im PHP-Quellcode einer Standard-WordPress-Installation ist eine solche Domain und URL als unseriös zu betrachten. Das vollständige Skript, in das die URL eingepackt ist, sollte man sich in die Zwischenablage kopieren. Aber hier ist noch anzumerken, dass die Kommentierungen vor und nach den HTML-Tags schon verraten haben, wie sie in den Quellcode gelangt sind. In meinem Fall ist es das WordPress-Plugin für das Cookie-Banner gewesen.

• Im nächsten Schritt wird mit dem in die Zwischenablage gespeichertem Skript eine Volltextsuche über die gesamte Datenbank durchgeführt. Am besten geht das zum Beispiel mit der PhpMyAdmin Web-Oberfläche. Wird hier nun als Ergebnis mindestens ein Treffer aufgezeigt, dann sollte klar sein, dass der Redirection Hack mindestens über eine SQL-Injektion in die Webseite platziert wurde.

• Jetzt kann man in den oder die einzelnen Datenbankeinträge gehen und das Script entfernen. Danach konnte vom Webbrowser die HTML-Seite wieder ganz normal interpretiert und dargestellt werden.

• Zuletzt sollte man das nicht mehr gepflegte und lückenhafte WordPress-Plugin deaktivieren und löschen.

In der Konsequenz hat der WordPress Redirect Hack bei mir dazu geführt, dass ich nochmals kritisch das Thema WordPress-Plugins überdacht habe. Plugins bieten für ein Online Content-Management-System durchaus einen Mehrwert, in dem sie es um neue nicht vorhandene Funktionen erweitern. Plugins sind aber auch zusätzliche Software, die auch zusätzlich Programmierfehler mit sich bringen können. Wenn ein Plugin nicht mehr kompatibel ist und in der Konsequenz auch nicht mehr funktioniert, weil es nicht mehr weiterentwickelt und gepflegt wird, dann ist das vielleicht das geringere Problem. Es ist eben aber auch möglich, dass es noch voller Programmierfehler steckt, die das Plugin zu einem Sicherheitsrisiko für die gesamte Webseite macht. Meine Einstellung zu Plugins war sowieso schon immer: so viele wie nötig, so wenig wie möglich. Auch ist die Empfehlung vielleicht nicht schlecht, dass wenn Plugins nicht benötigt werden, sie nicht nur zu deaktivieren, sondern sie dann auch zu löschen. So habe ich angefangen, meine WordPress-Plugins mal wieder ein wenig zu entrümpeln.
Vor knapp zehn Jahren habe ich so zum Beispiel mir das Podlove-Plugin installiert, weil WordPress keine Audiodateien in die Mediathek mit aufnehmen und auch nicht wiedergeben konnte. Für einen Blog-Artikel habe ich diese Funktionalität aber benötigt. Vor gut fünf Jahren wurde WordPress dann endlich um die Funktion der Audiowiedergabe erweitert. So brauchte ich nun nur den Beitrag etwas anpassen und konnte wieder ein Plugin einsparen und deinstallieren.
Eins anderes Beispiel ist das Duplicator-Plugin für Backups von WordPress-Blogs. Lange Zeit habe ich es für Backups und Migrationen des Web-Servers verwendet. Aber spätestens seit ich die Piwigo-Bildergalerie als Unterverzeichnis im Web-Server habe, ist die Größe des httpdocs-Verzeichnisses so stark gestiegen, dass es nur noch funktionieren wird, wenn ich die Bezahloption des Plugins in Anspruch nehme. Aber mal ganz ehrlich: Schon bevor es Plugins für Backups von Content-Management Systemen gab, mussten ganze Web-Verzeichnisse und Datenbanken auf andere Instanzen hin und her migriert werden.

Links:

• WordPress (engl. Wikipedia)
• WordPress (Projektseite)
• WordPress Plugins (Projektseite)
• phpMyAdmin (engl. Wikipedia)
• SQL-Injection (engl. Wikipedia)