Modx-Website gehacked – was tun?

Zum ersten mal ist ein altes, schon länger ungewartetes Projekt von mir gehacked worden. Und ich frage mich, ob ich bei der Reparatur alles richtig gemacht habe. Was meint ihr?

Der Hack

Modx Revolution 2.1.x gehacked

Das Projekt basiert auf meinem Lieblings-CMS Modix Revolution. Es gibt viele Gründe, Modx-Revo zu lieben. Wartbarkeit ist allerdings keiner davon. Von einem bequemen Autoupdate wie bei WordPress ist Modx leider noch weit entfernt und so bin ich wohl etwas nachlässig gewesen.

Screaming SEO Frog als Hackfinder

Tatsächlich hatte ich die Seite seit Monaten nicht mehr angeschaut und gestern auch nur, weil ich gesehen hatte, dass die Sichtbarkeit nach langem Niedergang wieder etwas angestiegen war. Um das noch weiter zu pushen, wollte ich nun doch mal die ausgehenden Links auf eventuelle 301er prüfen. Hätte man auch mit Xenu Link Sleuth machen können, weil ich aber auch noch einen Blick auf die Verzeichnisorganisation werfen wollte, hab ich den Screaming SEO Frog verwendet.

Ich kenne meine Seiten sehr gut und weiß, welche ausgehenden Links ich setze. Diese gehören eindeutig nicht dazu…

Spamlinks - Website gehacked

Spamlinks von gehackter Website

Der Blick in den Quellcode hat dann auch schnell bestätigt, dass auf sämtlichen Seiten (außer der Startseite) zwischen Trackingcode und dem schließenden Body-Tag Spamlinks eingebaut waren. Für normale Besucher unsichtbar, aber für Suchmaschinen schnell zu entdecken, per CSS aus dem sichtbaren Bereich der Website geschoben.

Quellcode der gehackten Seite

Blick in den Quellcode: Spammige Links.

Schritt 1 – Informationen einholen

Die Suche nach „modx gehacked“ hat auch gleich einige brauchbare Links gebracht. Beruhigend: Der Angriff ist bekannt und hat etliche Webseiten betroffen. Ich nehm’s nicht persönlich. Hier die beiden besten Treffer:

Die Artikel stammen von Mai und August 2013 – sind also schon deutlich über ein Jahr alt. Gut möglich, dass die Website schon damals gehacked war. Betroffen sind Modx-Revo-Installationen bis zur Version 2.2.4.

Im Blog von DAE finde ich wertvolle Informationen, wonach ich suchen muss:

Basically, look for: @eval(@gzuncompress(@str_rot13(@base64_decode(

Ich finde den String tatsächlich an mehreren Stellen: einmal in der Datenbank (MySQL table “modx_site_plugins“) und in folgenden Files.

  • /assets/cache.idx.php
  • /assets/xPDO.idx.php
  • /core/cache/xPDO.idx.php

Schritt 2 – (vor?)schnelles Handeln

Da ich auf schnelle Ergebnisse hoffe, lösche ich die entsprechenden Passagen manuell. Überraschender Weise sind die Spamlinks noch immer da. Also lösche ich den Modx-Cache und weil das auch nichts bringt, beschließe ich auf die neueste Modx-Version 2.3.1 upzugraden. Erfolg? Null.

Ich probiere noch ein paar andere Tipps, auf die ich im Internet stoße. Zum Schluß lade ich das komplette Webverzeichnis per FTP auf die Festplatte und durchsuche mit Ultrafinder die Dateien nach verdächtigen Strings. Nichts. Irgendwo sitzt noch Schadcode und ich finde ihn nicht.

Und ich ärgere mich im Nachhinein: Durch das Update habe ich die Timestamp aller Dateien verändert. Mit Bordmitteln kann ich nicht mehr herausfinden, wann die Dateien verändert wurden. (Ich könnte es beim Hoster versuchen. Oder durch Log-Auswertung, etc. Aber ob da viel rumkommt? Schätze ich muss damit leben, nichts über den Zeitpunkt des Hacks zu erfahren.

Schritt 3 – Blick in die Tools

Vielleicht helfen die Tools weiter bei der Eingrenzung des Zeitraums.

Sichtbarkeit

Sinkende Sichtbarkeit

Die Sichtbarkeit sinkt seit Februar 2014.

Die Sichtbarkeit hatte sich ursprünglich sehr gut entwickelt. Anfang Februar 2014 ist der OVI der Seite plötzlich stark gefallen. Das hatte ich natürlich verfolgt – aber schließlich war das ein kleines Projekt von vielen, auf dem seit Monaten keine neuen Inhalte mehr geschaltet wurden und die Links waren auch nicht so ganz sauber. Da erschienen mir die rückläufige Sichtbarkeit als natürliche Folge.

Besucherzahlen

Besucherzahlen seit März rückläufig.

Besucherzahlen seit März rückläufig.

Die Entwicklung der Besucherzahlen korreliert mit der Sichtbarkeit. Besucher-Höhepunkt war gegen Jahreswechsel. Der Januar war toll, aber eventuell nur ein Ausreisser.

UPDATE: Der Januar ist natürlich kein Ausreißer, sondern deckt sich perfekt mit der Sichtbarkeitskurve. Das fällt mir erst jetzt aus wo ich dem Projekt wieder mehr Aufmerksamkeit schenke.

Spätestens seit Februar/März 2014 gingen die Besucherzahlen aber deutlich zurück.

Webmaster Tools – Content Keywords

Content Keywords

Diese Keywords hätten mich stutzig machen sollen.

Schnell ein Blick in die Google Webmaster Tools. Da muss die Seite doch irgendwo sein. Ist sie aber nicht. Ist sie nicht? Offenbar hatte ich das Teil nie in den WMT angemeldet. „Und das mir…“, denke ich. Also hole ich das jetzt nach.

Und siehe da: Ein Blick auf die Content-Keywords zeigt, dass die spammigen Texte ihre Wirkung getan haben.

Buy, Online, Comprar, Where – auf einer deutschsprachigen Website recht überraschende Keywords. Eines davon sogar auf Position vier. Kein gutes Zeichen.

Webmaster Tools – Sicherheitsprobleme

Wenigstens haben die Webmaster Tools kein Sicherheitsproblem erkannt. Das Dashboard zeigt „Keine neuen Nachrichten oder neuen kritischen Fehler“ und es wurden auch keine manuellen Maßnahmen eingeleitet.

Keine Sicherheitsprobleme

Wenigstens keine Sicherheitsprobleme in den Google Webmaster Tools

Schritt 4 – Entscheidung

Je länger ich mich mit dem Hack befasst hatte und je mehr Dateien ich händisch bearbeitet hatte, desto klarer wurde mir, dass es mit einem einfachen Saubermachen nicht getan ist: Irgendwo liegt noch  Schadcode, den ich nicht entdeckt habe. Die Hacker haben Zugriff auf’s Backend, vielleicht sogar auf mein Passwort, die Datenbank oder den FTP-Zugang.

Ich habe es nie verstanden, wenn Leute ihre vireninfizierten Rechner mit irgendeiner billigen Antivirensoftware „desinfiziert“ haben und dann glaubten, es könne weitergehen wie bisher. Wenn ein Rechner infiziert ist, sichert man die Daten, macht die Festplatte samt MBR platt (am besten kauft man eine neue) und dann fängt man nochmal ganz von vorne an: Neuinstallation des OS und dann die mehrfach gecheckten Daten – und zwar nur die allerwichtigsten – auf die neue Festplatte kopieren.

Ein Webseitenhack ist zwar irgendwie was anderes, aber ich mach das jetzt genauso. Schließlich weiß ich, dass der Angreifer noch irgendwo festsitzt.

Schritt 5 – Neuanfang

Nachdem ich Backups von Datenbank und Inhalten gemacht habe, habe ich folgende Schritte durchgeführt:

  1. Neue Datenbank mit neuem Passwort anlegen & die alte DB löschen
  2. Neuen FTP-Zugang mit neuem Passwort anlegen & den alten Zugang löschen
  3. Modx Revolution in der aktuellen Version neu installieren & neuen Admin mit neuem Passwort anlegen
  4. Aus dem Backup (SQL-Dump) der Datenbank nur die wichtigsten Einträge ins neue System kopieren

Also bin ich heute Nachmittag das Backup der Datenbank Eintrag für Eintrag mit dem Texteditor durchgegangen und habe in vielen Einzelschritten die unbedenklichen Inhalte Stück für Stück zurückgespielt.

Und dabei habe ich am Ende sogar noch den hartnäckigen Schadcode entdeckt: Getarnt als „xPDO Core Services„, ein in der Datenbank verstecktes Plugin, das man alleine schon auf Grund seines Namens nicht einfach so entfernt. Hier ein Ausschnitt:

Schadcode

Wenn etwas so aussieht ist es entweder Kunst oder ein Hack.

Wäre ich auf das Plugin schon früher gestoßen, hätte ich u.a. diesen Beitrag entdeckt:

http://forums.modx.com/thread/89564/warning-hacking-attack-on-revo-2-2-4-using-core-services-plugin

Vielleicht hätte mir das etwas Sucherei erspart. An der Entscheidung, nicht mit einem kompromittierten System weiterarbeiten zu wollen, hätte das nichts geändert.

Fazit

Die Website läuft wieder. Die Spamlinks sind gelöscht und ich bin wahnsinnig gespannt, ob sich das positiv auf Sichtbarkeit und Besucherzahlen auswirken wird. Tatsächlich kann ich ja nichtmal sagen, ob Hack und Sichtbarkeitsverlust überhaupt kausal zusammenhängen.

Über die Entwicklung der Seite halte ich euch auf dem Laufenden.

Ich mag Modx immer noch, habe es aber in den letzten Projekten kaum noch genutzt. WordPress bietet so viele hervorragende Themes, Funktionen und Plugins, lässt sich komfortabel warten und ist darüber hinaus super SEO-tauglich – ich fürchte, dass Modx da nicht mithalten kann. Zur Zeit habe ich zwar noch sechs weitere Projekte auf dem CMS laufen, die ich heute alle ebenfalls manuell aktualisiert habe, mehr werden es aber nicht mehr.

Was mich interessieren würde, ist:
Habe ich in Schritt 5 wirklich alles getan um die Hacker auszusperren?
Darf ich mich (vorerst) sicher fühlen oder habe ich etwas vergessen? Was meint ihr?

3 Kommentare
  1. Heinz-Günter sagte:

    Hallo Philipp,
    ich teile Deine ambivalenten Gefühle zu MODX, ziehe es aber meist WordPress vor, da allein das individuelle Templating für WordPress (oder das nachträgliche Anpassen von free oder gekauften Templates) mich in den Wahnsinn treiben kann. Das Templatimg ist die große Stärke von MODX, und auch tolle Extensions. Es gibt ein paar Bemühungen, das Update von Revo besser zu machen. Ganz spannend ist ein MODX-Update Script, ich habe es selbst wegen aktuell zu viel Zeitdruck noch nicht getestet, liegt hier: https://github.com/jenswittmann/modx-update Mal sehen, wann ich es testen kann. In diesem Sinne, schöne Grüße

    Antworten
    • Philipp Clarin sagte:

      Hallo Heinz-Günter, danke für den Tipp mit dem Update-Script. Du hast völlig recht: Das Templating für Modx ist ein Traum. Mit HMTL und ein bisschen Scriptsprache lassen sich extrem schnelle Webseiten ohne jeden Overhead erstellen. Bei Modx weiß man immer, warum sich was wo im Quelltext befindet. Ich finde vor allem die Template-Variablen sehr nützlich. Schwachpunkt ist leider wirklich das Update. Hier könnte das CMS nochmal ordentlich punkten.

      Antworten
  2. Zentis sagte:

    Hallo Phillipp,
    zum updaten von modx habe ich mir auch schon Gedanken gemacht.
    Meine aktuelle Lösung: ich zippe mir die undate-relevanten Ordner (connector, core, manager und sutup) und nutze ein php-unzip script. Dann das setup laufen lassen. Zum Schluss die php und zip dateien vom Webspace entfernen.

    Zeitaufwand: ca. 5 Minuten – 10 Minuten (je nach Internetverbindung, da man ja die Daten hochladen muss.)

    Gruß Zentis

    Antworten

Hinterlasse einen Kommentar

An der Diskussion beteiligen?
Hinterlasse uns deinen Kommentar!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert