Auch Entwickler brauchen Platz zum Spielen

20. Februar 2009 /

WordPress-Wurm treibt sein Unwesen: Blogger als Sicherheitsrisiko

Offenbar reicht es heutzutage nicht aus, allein das Betriebsystem des heimischen Computers gegen Viren und Hacker zu schützen. Denn, aktuell macht sich ein Wurm im internationalen Raum breit, der explizit auf WordPress-Blogs abgesehen hat und sich im Template des verwendeten Theme einnistet. Seine Absichten: Ausgehende Links zu einschlägigen Seiten wie Online Casinos auf die Blogroll zu setzen. Etwa eine Sicherheitslücke? Wenn schwache Passwörter eine sind, dann ja.

Der unsichtbare Schädling
Im letzten Monat heuften sich auch im deutschsprachigen Raum die Fälle, wo Anwender über neu hinzugekommene, wie von der Geisterhand angelegte Links innerhalb der Blogroll berichteten. So auch heute in der WordPress-Gruppe bei XING. Ich durfte den außergewöhnlichen Fall inspizieren, protokollieren und analysieren.

Der Hintergrund in ausführlicher Form: Über Nacht wurde die Linkssammlung (auch Blogroll genannt) um einen oder mehrere Links erweitert – allerdings nicht vom Inhaber des Blog, vielmehr ungewollt und unkontrolliert. Die Löschung des überflüssigen Link im Administrationsbereich der WordPress-Installation brachte keine gewünschte Wirkung: Die Verknüpfung war spätestens beim nächsten Aufruf der Blogseite wieder sichtbar und linkte auf das hinterlegte Ziel.

Eins steht jetzt fest: Es war kein Versehen! Der „böse“ Link muss von einem Script manipuliert und überwacht sein. Erfinderisch: Scheinbar prüft ein eingeschmuggeltes Script bei jedem Aufruf des Blog auf die Existenz des gesetzten Link. Wurde dieser händisch aus der Blogroll entfernt, so wird prompt ein neuer angelegt. Zack! Schnell entsteht daraus eine „The NeverEnding Story“.

Der Link bleibt also hartnäckig und lässt sich nicht entfernen – was tun? Man begibt sich auf die Suche nach dem Beschützer-Script, welches das Dasein der zu eliminierenden Verknüpfung steuert und deckt. Meine erste Vermutung war die functions.php, die eigentlich für nachträglich hinzugefügte Funktionen gedacht ist und solch ein Codeschnipsel dort bestens aufgehoben wäre. Pustekuchen!

Der Wolf im Schafspelz
Zunächst kommen Templates in den Verdacht, den böswilligen Code implantiert bekommen zu haben. In der Tat! Das Template header.php wurde mit einem PHP-Code infiziert: Gleich nach dem <body>-Tag versucht sich ein überdurchschnittlich langer Befehl in Form einer kodierten Zeile zu verstecken. Geschickte Platzierung und perfekte Wahl der Template-Datei sorgen für den seitenweiten Befehlsaufruf und permanente Überwachung der Linkssammlung.

Warum sind die Funktionsaufrufe eigentlich kodiert?

  • Kodierter Code enthält keinerlei Klartext, verwischt die Spuren, erschwert die Suche nach den Anhaltspunkten.
  • Kodierter Code versteckt tückische PHP-Befehle, die auf einen fremden Code hindeuten würden.
  • Kodierter Code kann in einer Zeile hinter dem sowieso bestehenden BODY-Tag unauffällig platziert werden, die Anzahl der Zeilen bleibt erhalten.
  • Kodierter Code springt bei der Pflege und Wartung der Templates nicht unbedingt sofort ins Auge, da der Code auch zum Theme gehören könnte. Die Erfahrung hat gezeigt, dass viele Theme-Entwickler den Copyright-Hinweis im Template ebenfalls einer Kodierung unterziehen, um die Löschung des Copyrights zu erschweren.
  • Kodierter Code kann mit internen PHP-Mitteln (base64_decode) schnell und einfach dekodiert werden, erfordert also keine zusätzlichen Bibliotheken.

Weshalb wurde ein Template und keine Core-Datei infiziert?

  • Templates werden nach der Fertigstellung des Blog kaum bearbeitet bzw. begutachtet. Die Templatedateien sind zwar nicht ideal zur Aufbewahrung eines Fremdcodes (Zum Vergleich: Templates enthalten nur wenig Code, Core-Dateien sind dagegen eine wahre Code-Wüste), der wp-content-Ordner verfügt aber meist über mehr Rechte als Verzeichnisse mit Systemdateien.
  • Änderungen in den Core-Dateien gehen nach einem Upgrade der WordPress-Instanz verloren, da die Files bei der Aktualisierung überschrieben werden. Dies würde die Lebensdauer des Eindringlings enorm verkürzen.

Infiziertes Header-Template mit ausführbarem Code
Header-Template mit einem Teil des Befehls

Weiter schlimmer…
Nun ist der Übeltäter gefasst, Ende der spannenden Odyssee? Natürlich nicht. Aus Neugier verschaffen wir uns den Einblick in den kodierten Code des Schädlings. Dekodierter Kokon beinhaltet in sich eine smarte Anwendung, die bösartiger ist als vermutet:

  1. Es wird eine ausgehende Verbindung zum Server im Internet aufgebaut. Je nach Erreichbarkeit steht ein zusätzlicher Server zur Verfügung, um gestellte Anfragen bzw. Requests sorgfältig und zeitnah verarbeiten zu können.
  2. Beim Verbindungsaufbau werden Daten des Blog übermittelt.
  3. Vom entfernten Server bekommt das eingenistete Script einen PHP-Code als Antwort übersendet.
  4. Der empfangene PHP-Code wird im Blog ausgeführt.

Der letzte Listenpunkt lässt jeden Blogger zittern! Denn es ist in der Tat so, wie es klingt: Ein beliebiger Code wird von außerhalb in den Blog eingeschleust und zum Laufen gebracht. Wie die Geschichte endet, entscheidet ganz alleine der Virus und die dahinterstehende Zielsetzung. Denkbar wären eine komplette Leerung der lokalen Datenbank, Übermittlung der Daten aus den WordPress-Tabellen an den entfernten Server oder Missbrauch der Hardware für weitere Angriffe. Katastrophale Folgen bringt eine derartige Infizierung mit sich.

Ausschnitt aus dem dekodierten Code des WordPress-Wurms
Ausschnitt aus dem dekodierten Code des WordPress-Wurms

Wenn man sich die Domains der aus dem Script angesprochenen Server anschaut, wird schnell klar: Diese Server haben die alleinige Aufgabe, den nach Hause funkenden Wurm zuverlässig und performant mit entsprechender Antwort zu beliefern. Dank übermittelten Blogdaten sind die Server der Angreifer in der Lage, jedem befallenen Blog abhängig von seinen Eigenschaften unterschiedlichen Code zur Ausführung zurückzusenden.

Directory Listing Denied beim Zugriff auf Hacker-Server
„Directory Listing Denied“ beim Zugriff auf Hacker-Server

An der Tür geklopft und eingebrochen
Nach der Bloßstellung des Sündenbocks gilt nun herauszufinden, auf welchem Weg das Script ins Template des Blog geschrieben wurde. Da es sich um die neuste WP-Version handelte, sind bereits bekannte Sicherheitslücken z.B. in der Snoopy-Class ausgeschlossen. Massenweise Access- und FTP-Logs wurden von mir ausgewertet, ich bin der festen Überzeugung, dass die für eine Injektion notwendige Änderung via FTP erfolgt hatte. Die scheinbar sehr zügig erratenen Zugangsdaten werden vom Roboter zwecks weiteren Schreibversuchen gemerkt und zur Verifizierung beim FTP-Server benutzt.

Übrigens, nach der Aktualisierung der Templatedatei setzt der Bot das Änderungsdatum zurück und vermeidet somit, dass die Datei durch das Datum unnötig auffällt. Die Krönung des Konzepts: Im FTP-Protokoll lässt sich wunderbar sehen, dass der gleiche Roboter den FTP-Server mit befallenem Blog in bestimmten Zeitintervallen aufsucht, um nachzuschauen ob das Script im Template seine Arbeit fleißig verrichtet. Wurde der Betrug rechtzeitig erkannt und das Script aus dem Template eliminiert, wird der bereinigte Code in header.php vom Bot immer wieder aufs Neue verseucht.

Erkenntnis und Lösung
WordPress trägt in diesem Fall keine Schuld. Weder Sicherheitslücken noch frei zugängliche Schnittstellen sind für die Infizierung verantwortlich. Blogger und die zu einfach gewählten Eintrittsdaten stellen ein enormes Sicherheitsrisiko dar und verhelfen aktiv der Verbreitung des Wurms.

Also? Die Zugangsdaten zum FTP-Server schärfen stellen – nicht erst nach einem Virusbefall (auch wenn es jetzt keine Epidemie ist), vielmehr spätestens nach der Inbetriebnahme des Blog. Das Passwort muss mindestens 7 Zeichen lang sein und ein Sonderzeichen enthalten.

Mehr Tipps und Tools zur Absicherung des Blog:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.