Aus der Reihe „gute Idee, schlechte Idee“ heute: Backups

Es klingelt das rote Telefon – dran ist ein potentieller Neukunde, der sich nicht mehr in sein WordPress einloggen kann. Klingt auf den ersten Blick nach einem einfachen Job – allerdings machen mich die Details dann doch stutzig, denn die „Passwort vergessen“-Funktion bringt auch keine Lösung. Also lasse ich mir die Zugangsdaten geben und schaue mir das mal im Detail an. Der Webspace-Scan zeigt keine Auffälligkeiten, in der Datenbank stolpere ich dann allerdings über die Einträge in der wp_users-Tabelle: Usernamen wie „admin“, „admin1“, „admin2“ sind definitiv nicht normal, die zugehörigen Passworthashes in MD5(!) und die Mailadressen erst recht nicht.

Als Sofortmaßnahme ändere ich also erst einmal die Zugangsdaten für die Datenbank, stelle die alte wp_users-Tabelle aus einem sauberen Backup wieder her und ändere dann für alle User vorsorglich nochmals das Passwort.

Danach geht es an den forensischen Teil der Arbeit. Da es sich um ein 08/15-Webhostingpaket handelt, sind die Logfiles nicht allzu ergiebig, außer erheblichem Grundrauschen (die üblichen Aufrufe von xmlrpc.php und wp-login.php aus allen möglichen Winkeln der Welt inklusive diverser ec2-Locations…) findet sich keines der gängigen Muster.

Eine Sache finde ich allerdings doch in den Logfiles: Zwei Tage bevor der Login nicht mehr funktionierte, gab es einen Abruf der wp-config.php.bak – Moment, was? Richtig. Vor geraumer Zeit wurde die wp-config.php bearbeitet und dabei vorsichtshalber ein Backup angelegt. Was in vielen Fällen löblich und sinnvoll ist, wird hier zur Zeitbombe: Für den Webserver ist die Datei wp-config.php.bak eine ganz normale Datei wie jede andere auch – und damit lässt sie sich wie ein Bild oder PDF auch herunterladen.

Damit stehen dem Angreifer dann gleich mehrere Vektoren für einen erfolgreichen Angriff zur Verfügung: Zum einen erhält er so die Salts, die WordPress verwendet, und zum anderen bekommt er die Zugangsdaten zur Datenbank auf dem Silbertablett präsentiert. Das verschafft im konkreten Fall dem Angreifer zwar noch keinen direkten Zugriff auf die Datenbank von außen, aber da als Datenbankhost „localhost“ eingetragen ist, reicht eine einzige infizierte Website auf dem Server, um über die Backdoor dort auch Zugriff auf „meine“ Datenbank zu bekommen. Da es sich um einen großen Hoster handelt, ist diese Theorie durchaus plausibel – beweisen lässt sie sich von außen nur schlecht. Allerdings passt sie sehr gut zur Faktenlage, da vor allem Auffälligkeiten in den Logfiles der betroffenen Domain fehlen und auch keine Infektion auf dem Webspace selbst zu finden war. Natürlich könnte es immer noch eine unbekannte Lücke in WordPress, dem Theme oder einem Plugin sein, aber auch das würde in den Logfiles deutliche Spuren hinterlassen.

Vorsichtshalber lösche ich also die wp-config.php.bak und ändere auch noch die Salts in der wp-config.php mit dem Salt-Generator von wordpress.org. Als Nachsorgemaßnahme schaue ich in den folgenden Tagen wiederholt in die Datenbank und in die Logfiles, allerdings bleibt es vorerst bei diesem einen Angriff. Zwar ärgert mich die unvollständige Erklärung zur Art und Weise des Angriffs schon etwas, aber mehr lässt sich aus den vorhandenen Informationen kaum machen.

Mein Fazit bleibt: Egal welche Lücke man versehentlich schafft, ausgenutzt wird sie früher oder später auf jeden Fall. Bei „Standardlücken“ geht es schneller, bei anderen etwas langsamer. Im vorliegenden Fall lag die Backup-Datei schon seit über einem halben Jahr auf dem Webspace, aber in den Logfiles war nur ein einziger Abruf zu finden – dafür aber unzählige Versuche, bekannte Lücken zu nutzen. In dieser Hinsicht gleichen die Logfiles praktisch der Liste entdeckter Lücken, selbst schon vor Jahren behobene Exploits werden immer noch automatisiert durchgetestet.

Aus welchen Gründen auch immer Updates nicht einzuspielen, kann also keine Lösung auf Dauer sein. Man muss nicht gleich ins andere Extrem verfallen und alles ohne Rücksicht auf Verluste aktualisieren, im Zweifelsfall sollte die Sicherheit der eigenen Website aber immer Vorrang haben. Wenn es beim Sicherheitsupdate zu Problemen kommt, lassen die sich in aller Regel vom Experten leicht beheben.

Kommentare (3) Schreibe einen Kommentar

  1. Oha! Und solch eine *.bak ist nun wirklich nicht unüblich bei vielen Website-Betreibern – auch bei Agenturen.

    Bist du sicher, dass bei dem Hoster der DB-Zugang nur über „localhost“ möglich war? Wie schaut’s mit dem Zugriff über phpMyAdmin aus?

    Antworten

    • Mir erschien das auch erst wenig plausibel, aber auf dem Webserver ist von außen kein Datenbankserver zu erreichen, und phpMyAdmin ist bei dem Hoster nur von innerhalb des Kundenlogins erreichbar, nicht von außen. Da bleiben nicht viele Möglichkeiten offen.

      Antworten

  2. Gut zu wissen, dass man einen Fachmann für solche Probleme hat. 😀
    Ich brauch mich um nichts zu kümmern und du guckst nach dem Rechten. 😀

    Antworten

Schreibe einen Kommentar

Pflichtfelder sind mit * markiert.


  • © 2016-2018 WP-Retter.de
Top