WordPress-Wurm treibt sein Unwesen: Blogger als Sicherheitsrisiko

Artikel vom 20. Februar 2009

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:

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.
Beim Verbindungsaufbau werden Daten des Blog übermittelt.
Vom entfernten Server bekommt das eingenistete Script einen PHP-Code als Antwort übersendet.
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

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:

Nachgefragt
Jemand unter euch davon betroffen (gewesen)? Schon mal etwas vom Phänomen “Woher kommt dieser Link in meiner Blogroll?” gehört? Wie lange ist das Passwort in eurem Blog bzw. auf dem FTP?

[Der Autor] Sergej Müller ist enthusiastischer Software Engineer mit Schwerpunkten Webentwicklung und WordPress. Seit 2007 programmiert und vertreibt er wpSEO, das weltberühmte und patentierte SEO-Plugin für WordPress-Blogs.

36 Kommentare zum Artikel

#1 mr.gene am 20. Februar 2009 um 21:56

Klingt ja mal äußerst spannend…so kommt man auch an massig Backlinks ;-P

Nee im Ernst: Das ist ja mal ganz schöner scheiss…ich hoffe mal, dass meine Passwörter sicher genug sind, deine 10 Schritte zur Sicherheit werd ich mir aber morgen trotzdem nochmal intensiv anschauen ;)

#2 flöschen am 20. Februar 2009 um 21:56

Uhhh… Sehr beängstigend. Danke für die sehr genaue Analyse und Erklärung dieses Schädlings.

#3 solar22 am 20. Februar 2009 um 22:19

Oha..mir ist ein Schauer über den Rücken gelaufen bei der Schlagzeile…
Aber zum GLück ist nicht WP schuld, ich denke mein Zufallsgeneriertes PW mit Zahlten und Buchstaben (Groß und Klein) errät das Teil nicht so schnell vor allem weil Benutzername und PW vom FTP nichts mit den Daten vom Blog gemeinsam haben :D

#4 CyMotion (Sven) am 20. Februar 2009 um 22:21

Wer mit aus Faulheit und Bequemlichkeit resultierenden Standardpasswörtern hantiert der brauch sich nicht wundern… Ich hab trotzdem mal meine Links und die Templatedateien gecheckt obwohl ich mir recht sicher bin ein gutes Passwort gewählt zu haben aber wenn man dieses im Browser bzw Computer gespeichert lässt ist es schon wieder nicht sooo sicher ^^ Ich benutze inzwischen ein USB Stick + Passwortverwaltungsprogramm um solche Daten nicht permanent angreifbar zu halten.

#5 solar22 am 20. Februar 2009 um 22:24

Kannst du mal den ganzen php code veröfentlichen der dann da steht, dann kann man nen Gegencode schreiben :)

#6 Sergej Müller am 20. Februar 2009 um 22:28

Ist schon ungewöhnlich und unerwartet einen Wurm für WordPress zu sichten und entschärfen zu müssen. Gott sei Dank nicht in meinem eigenen Blog.

Ich will gar nicht wissen, welcher Unsinn noch mit der dynamischen Auslieferung des ausführbaren Code getrieben wird. Ich meine, sie hätten den Code für die Vervollständigung der Blogroll um eigene Links auch direkt im Script positionieren können, ohne ausgehende Verbindungen herstellen zu müssen. Aber nein, sie legen den Server offen, dafür können Sie jederzeit den Code im infizierten Blog frei und zeitlich steuern. Schachmatt.

#7 Sergej Müller am 20. Februar 2009 um 22:39

@solar22
Wenn du willst, kann ich dir den dekodierten Code zusenden, öffentlich legen würde ich den ungern.

#8 solar22 am 20. Februar 2009 um 22:44

@Sergej:
Das wäre nett, meine Mailadresse hab ich ja mit meinen Kommentaren hinterlegt :)

#9 Sergej Müller am 20. Februar 2009 um 22:47

Hab ich dir geschickt, aber keinen Unsinn damit treiben ;)

#10 solar22 am 20. Februar 2009 um 22:48

Nene, sowas hab ich nicht nötig ^^
Ich werd mal versuchen das Script auszutricksen :D

#11 Sergej Müller am 20. Februar 2009 um 22:49

Aber hast du nicht oben gesagt, deine Passwörter seien sicher?

#12 solar22 am 20. Februar 2009 um 22:50

RIchtig, ich möchte mal versuchen ein Script zu schreiben, welches dieses Script unschädlich macht.
–
Was wohl passiert wenn man den body Tag löscht ?

#13 Sergej Müller am 20. Februar 2009 um 22:53

Zugegeben verstehe ich noch nicht, wie du das Script “unschädlich” machen willst? Noch bevor es eingeschleust wird oder danach?

#14 solar22 am 20. Februar 2009 um 22:54

Wie genau weis ich auch nich nicht ^.^
Ich werd mir mal ein WP lokal aufsetzen und ein wenig experimentieren.
Vllt find ich ja einen Weg…^^

PS: Bis jetzt ist keine Mail angekommen

#15 Sergej Müller am 20. Februar 2009 um 22:57

Die E-Mail ist mit Sicherheit bei dir angekommen und der Virus hat sich im Hintergrund installiert und die E-Mail anschliessend gelöscht ;)

Nein, Scherz. An die E-Mail-Adresse aus deinen Kommentaren hab ich vor ein paar Minuten geschickt.

#16 solar22 am 20. Februar 2009 um 23:00

Komisch die Blogmails kommen immer sofort an…

ah…gefunden :D
Du bist im Spamordner gelandet, und zwar der spamordner der nur in der webmailsichtbar ist…

#17 Sergej Müller am 20. Februar 2009 um 23:01

Naja, im Body der E-Mail ist auch böswilliger Code ;)

#18 solar22 am 20. Februar 2009 um 23:01

Das kann natürlich sein, das der Virenscanner Alarm geschlagen hat…

#19 Sergej Müller am 20. Februar 2009 um 23:03

Genau, wir brauchen einen Virenscanner für WordPress ;)

#20 solar22 am 20. Februar 2009 um 23:04

Das wär’s doch :o)
Wäre aber ne gute Sache, einen AVScanner für Webapplikationen…

#21 Nick am 21. Februar 2009 um 10:18

Also ich denke mit einem Antivirusprogramm für Wordpress kann man viel Geld verdienen..was sich automatisch updatet :)

Sergej….für den Vorschlag will ich eine lebenslange Lizenz dafür haben ;)

Grüße

#22 Sergej Müller am 21. Februar 2009 um 11:58

@Nick
Aber das hatte ich doch gestern solar22 vorgeschlagen ;)

#23 Julian am 21. Februar 2009 um 12:02

Das beste Passwort bringt auch nichts, wenn man FTP und nicht FTPS (FTP in verschlüsselt) oder SFTP (über SSH) benutzt, weil das Passwort sonst eh unverschlüsselt durch das halbe Internet übertragen wird.

#24 Sergej Müller am 21. Februar 2009 um 12:09

@Julian
Gebe dir generell Recht, macht aber der Hoster nicht immer mit. Meiner zum Beispiel stellt auch kein SFTP zur Verfügung. Daher bin ich auch doppelt so vorsichtig und lasse meine Passwörter einmal im Monat neu generieren. Aufwändig, dafür aber nachhaltig sicherer.

#25 Sergej Müller am 21. Februar 2009 um 15:41

FYI:
Der Artikel wurde um die Listen “Warum sind die Funktionsaufrufe eigentlich kodiert?” und “Weshalb wurde ein Template und keine Core-Datei infiziert?” vervollständigt.

#26 secco am 22. Februar 2009 um 12:59

Interessante Analyse, jedoch fehlen mir folgende wichtigen Infos:

1. Welche WP Version war betroffen?
2. Liegen Informationen zu Grunde, wie der Hacker in das Blog kam?

Übrigens kann man solche Hacker-initiierten Skriptänderungen sehr schön mit dem Plugin File Hash Trace verfolgen.

#27 Sergej Müller am 22. Februar 2009 um 14:30

@secco

WordPress 2.7 war installiert (hab den Artikel um den Hinweis erweitert).
Wie ins Blog kam? Der Bot hat die Templatedatei per FTP infiziert. Oder was meinst du?

#28 Nirak am 22. Februar 2009 um 20:46

Wurde der Wurm bei WordPress.org oder WP.com gesichtet, oder trifft er beide? Ich “twitter” den Artikel auf jeden Fall mal. Danke und Liebe Grüße

#29 Sergej Müller am 23. Februar 2009 um 09:05

@Nirak
Es sind nur eigengehostete Blogs betroffen.

#30 Peter am 23. Februar 2009 um 09:56

Wie haben zwar noch keinen aktiven Befall, werden aber sofort alle Vorsichtsmaßnahmen ergreifen.

Für uns sind aber im Moment auch die Massen von “Pharma-Referenten” lästig, die unseren Blog mit Trackbacks plagen und sich immer wieder als User in unserem Blog http://www.stuttgart-aktiv.de anmelden.

#31 Sergej Müller am 23. Februar 2009 um 10:01

Peter, gegen Spam via Trackback kann ich dir mein Antispam-Plugin Antispam Bee empfehlen. Das mit der Registrierung ist so eine Sache, eine Abschaltung kommt in eurem Fall wohl nicht in Frage, gell?

#32 SEO-Handbuch am 25. Februar 2009 um 19:10

Hallo Sergej, klasse Sache dein Tool :) Weiter so!

#33 Binary am 17. März 2009 um 00:51

Wegen Idee Virenscanner:
Ich kenn mich nicht genug mit WP aus, um Plugins zu schreiben. Aber als Gegenmaßnahme würde sich IMHO anbieten, über ein PlugIn bei einem Seitenaufruf die (aktuellen) Templatedateien zu hashen. Stimmt der Hashwert nicht mehr mit dem vorherigen überein, so wird eine Mail an den Admin verschickt…
Alternativ: Dateigröße – Die Datei muss ja bei gleicher Funktionalität größer werden.
Evtl. mit Begrenzung, dass dieser Check nur alle x Aufrufe, oder erst x Minuten nach dem letzten Check wieder läuft um das ganze performanter zu machen.
Nur: Wenn sich das Template ändert, muss natürlich ein neuer Vergleichswert in die DB – und das darf nicht so einfach durch den Virus erledigt werden können.

#34 Sergej Müller am 17. März 2009 um 00:59

@Binary
Ja, gar nicht so schlecht die Idee, jedoch müsste man das Plugin bei jeder gewollten Änderung der Templates aufrufen, um Bescheid zu geben, dass die getätigte Anpassung beabsichtlicher Natur war. Wenn man viel am Anpassen und Experimentieren ist, kann es schon nervig werden. Auch viele Plugins verlangen manuelle Eingriffe in die Templates, um dort die Funktionsaufrufe zu positionieren….

Da finde ich meine Technik doch schon pflegeleichter.

#35 Experimentator am 29. März 2009 um 21:39

Hochinteressante Angelegenheit.
Prinzipiell besteht die Gefahr ja neben dem Knacken des FTP-Zugangs grundsätzlich auch in frei verfügbaren verseuchten Themes, die vom Benutzer selbst aus freiem Willen hochgeladen werden. Dürfte sich dann wohl in jedem Fall empfehlen, fremde Themes vorher nochmals (mit den AntiVirus-Plugin) zu checken. Gäbe es evtl. eine Möglichkeit das mit dem AntiVirus-Plugin vielleicht sogar schon zu machen, bevor das Theme als Standard aktiviert wird?

#36 Sergej Müller am 30. März 2009 um 09:04

@Experimentator
AntiVirus für WordPress scannt nur das aktuell aktive Theme durch – wenn man ein frisches Theme herunter geladen und im Backend aktiviert hat, spricht nichts dagegen das AntiVirus-Plugin gleich drüber laufen zu lassen.