Stellen Sie sich vor, ihre erstellte Webseite fällt einem Hackerangriff zum Opfer und Sie haben keinen Zugriff auf die Datenbank.
Kann nicht sein werden Sie vielleicht jetzt sagen. Nun, in diesem Fall war der Datenbankadministrator nicht mehr verfügbar und besaß zudem auch noch die Geschäftsbeziehung zum Hostinganbieter.
Was Sie in einem solchen Fall tun können, um Ihre Reputation durch Spamseiten nicht nachhaltig zerstören zu lassen und Ihre Webinhalte zu retten, erfahren Sie in diesem Artikel.
Was war geschehen?
Der Webseiteninhaber wurde durch den Hinweis auf Google, das seine Webseite als offensichtlich gehackt identifiziert hatte, auf den Missstand aufmerksam.
Auf den Webseiten selbst war auf den ersten Blick allerdings nichts festzustellen.
Erst die Ergebnisse des site: Befehls (site:domainname) und die Überprüfung mit einem Online-Tool (www.websicherheit.at/web-security-check/) ließen das Ausmaß des Schadens erahnen.
Hunderte von Seiten mit dubiosen Texten in englischer Sprache zu Wetten, Casinos, Autos, pharmazeutischen Produkten und anderen nicht für minderjährige geeigneten Inhalten waren ungewollter aber fester Bestandteil des Webauftritts geworden.
Dabei waren die Spamseiten als http://domain.de/page-n (n: 4-5 stellige Nummer) angelegt.
Analyse
Für eine gezielte Analyse der kompromittierten Dateien ist ein Zugang zum Web-Server sehr hilfreich. Leider bestand keine Möglichkeit auf den Server direkt zuzugreifen. Auch hatte der Nutzer zu diesem Zeitpunkt keinen Google Search Account zur Verfügung. Der administrative Zugriff auf das WorPress-Backend war allerdings möglich.
Das Mysteriöse: Im Backend waren weder in den Seiten noch in den Beiträgen Hinweise auf die angelegten Spamseiten zu finden.
Insofern galt die erste Analyse der WordPress-Version sowie den installierten WordPress-Plugins.
Tabelle 1: Installierte Plugins
Die WordPress-Version war auf dem aktuellen Stand (4.5.3).
Bei den Plugins befand sich der Exploit Scanner nicht auf dem aktuellen Stand. Die Version 1.4.12 war die letzte aktuelle für WordPress 4.5.2.
Die beiden Plugins SEO Adviser und WordPress Researcher sorgten dann für die Überraschung. Nach kurzer Recherche war klar, dass diese Plugins ungewollt und nicht selbst installiert wurden und in engem Zusammenhang mit gehackten Seiten stehen.
Abbildung 1: Unerwünschte Helferchen
Ein Blick in die Liste der Benutzer zeigte aber keine zusätzlichen Adminaccounts an, die typischerweise in diesem Kontext auftauchen. Möglicherweise waren sie zu diesem Zeitpunkt bereits gelöscht worden.
Nun sollten die Files untersucht werden. Um an diese heranzukommen (die Möglichkeit per ftp bestand ja nicht), musste zunächst ein Backup gezogen werden. Dazu wurde das Plugin BackWPup installiert.
In der heruntergeladenen wp-config.php wurde dann auch ein entsprechend verdächtiger Eintrag entdeckt, der als Schadcode identifiziert wurde.
<< require_once(ABSPATH.’wp-content/plugins/xcalendar/xcalendar.php‘); >>
Die Datenbank konnte über das bereits erwähnte BackWPup-Plugin gesichert werden. Die entzippte SQL-Datei hatte ein Größe von über 100 MB. Viel zu groß für die relativ kleine Webseite. Ein Blick hinein zeigte, dass insgesamt neun Tabellen mit dem Namen wp_core_log_xyz angelegt wurden, wobei xyz dreistellige Zahlen darstellten.
Die Tabellen waren, bis auf die Tabelle wp_core_log_311, leer.
In wp_core_log_311 hingegen befanden sich 146.741 Einträge. Die Tabelle hatte die Datenfelder id und info. Die id zählte einfach von 1 bis 146.741, während das Info Feld z.B. so aussah:
<< a:5:{s:2:“ip“;s:12:“66.249.64.45″;s:4:“time“;i:1443795825;s:3:“ref“;N;s:2:“ua“;s:72:
“Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)“;s:3:“url“;s:40:“http://domain/page-68063/“;} >>
Die nächste interessante Tabelle war wp_posts. Darin befanden sich alle bisher erstellten Beiträge und Seiten. Insgesamt 7.118 Einträge. Ein Blick auf die Inhalte zeigte schnell, dass es sich bei der Mehrzahl der Einträge nicht um vom Nutzer selbst erstellte Beiträge handelte. Lediglich 110 Einträge waren gewollte Beiträge. Die übrigen 7.008 gehörten zur Kategorie Spam.
Die Filterung gestaltete sich relativ einfach über das Feld post_author. Sinnigerweise hat sich der Spammer die post_author id = 0 gegeben.
Der erste Spam-Eintrag vom 22.07.2015 sah folgendermaßen aus:
<< (109, 0, ‚2015-07-22 14:32:27‘, ‚2015-07-22 13:32:27‘, ‚football betting
strategies‘,‚Football betting strategies‘, “, ‚publish‘, ‚closed‘, ‚closed‘, “, ‚football-betting-strategies‘,“, “, ‚2015-07-22 14:32:27‘, ‚2015-07-22 13:32:27‘, “, 0,‚http://domain/football-betting-strategies/‘, 0, ‚page‘, “, 0), >>
Ähnliche Einträge dieser Art folgten an diesem Tag, bevor eine längere Pause eintrat. Erst am 1. September 2015 ging es wieder los. Dann aber richtig.
In Spitzenzeiten wurden zum Teil mehrere Spameinträge pro Minute veröffentlicht!
Abbildung 2 zeigt den Verlauf der Attacke und die dadurch erzeugten Einträge in der wp_posts. Insgesamt wurden in 10 Monaten 2.447 Spam-Seiten publiziert. Das sind im Schnitt acht Seiten täglich!
Abbildung 2: Verlauf der erzeugten Einträge in der Tabelle wp_post
Mit dem letzten April 2016 reißt die Flut der veröffentlichten Spam-Seiten plötzlich ab und innerhalb der nächsten sieben Wochen werden lediglich noch Revisionen von Seiten in WordPress angelegt. Nach dem 19. Juni finden sich dann keine Eintragungen über schädliche Aktivitäten mehr in der Datenbank. Die hier noch angezeigten Einträge sind auf die Analyseaktivitäten zurückzuführen.
Der zweite Teil dieses Beitrags handelt dann von der Beseitigung der Spam-Seiten und zeigt Ihnen Maßnahmen, damit Ihre Webseite auch zukünfig sauber bleibt.
