Fox.php - Segen oder Fluch?
Von meinem Server bekam ich die Mitteilung, dass jemand versucht hat ein PHP Script mit dem klingenden Namen fox.php hochzuladen.
Meine Nachforschungen über die IPv4-Adresse ergab eine IT Firma aus China, hochgeladen mit einem Windowsrechner der Safari als Browser nutzt.
Aber dem wollen wir nicht weiter Beachtung schenken, vielmehr interessiert das Script selbst!
Weil ich nicht weiß, ob dieses Script gutartig (wie z. B. ein Sicherheitspatch, Update) oder bösartig (wie z. B. Malware, Trojaner) ist,
werde ich hier nur einzelne Zeilen aus dem decrypted Quellcode zitieren und diese zur Diskussion stellen.
Sollte sich herausstellen, das dieses Script eindeutig unlautere Absichten verfolgt, wird selbstverständlich der gesamte Quellcode veröffentlicht!
Die 1. Ebene
Wenn man die
fox.php mit einem Editor öffnet, stechen einem sofort drei Teile ins Auge.
- Eine Funktion in welcher der Satz: I could not have a more welcome visitor 64 group of zain bani gut lesbar ist.
diese Funktion dient als Schlüssel zur Decodierung von ...
- einem durch die eval() Funktion ausführbar gemachten und verschlüsselten Inhalts und
- dem Schluss, welcher das Script nach Ausführung wieder vom Server löschen soll!
Wir entschlüsseln mittels Base64 und dekomprimieren den Inhalt um die zweite Ebene zu erhalten!
Die 2. Ebene
Hier zuerst eine Anmerkung. Die Schreiber_innen des Scripts arbeiten äußerst akkurat und definieren mittels einer !function_exists Fallunterscheidung
bzw. overrulen immer wieder benötigte Funktionen. Damit soll das Script auch auf älteren PHP Versionen ausführbar gemacht werden, bzw. es soll auch arbeiten wenn bestimmte Funktionen deaktiviert sind!
Ansonsten gibt es in der zweiten Ebene noch immer nicht viel zu lesen. Wir haben nur zwei Variablendeklarationen (die später Global gesetzt werden) und zwei Funktionen die wieder als Schlüssel
für die Decodierung des Inhalts dienen sollen.
Auffällig ist natürlich, dass der verschlüsselte Codeblock 20 mal mit der eval() Methode ausführbar gemacht werden soll.
Die Entschlüsselung der dritten Ebene sollte keine weiteren Probleme verursachen!
Die 3. Ebene
Jetzt endlich gibt es was zu lesen. Wir haben hier einige (sehr sauber gecodete) Funktionen, wie z. B. zum Schreiben, Speichern, Löschen, Stringoperationen, Contentreader (mit cURL) uvm. und weil Funktionen deklariert aufgerufen werden müssen, sind diese allein noch ein Indiz für die Eigenschaft des Scripts.
Darüber hinaus haben wir noch einen verschlüsselten Codeblock, den ich nicht geschafft habe zu entschlüsseln. Ich nehme an, das hier ein besonderer Zeichensatz verwendet wird (vielleicht ein Arabischer, Baltischer, Chinesisch, D..., F..., usw.). Womöglich soll damit auch Sichergestellt werden, das dieses
Script auch nur in einem bestimmten Sprachraum ausgeführt wird. Das sind aber nur Spekulationen. Was ich definitiv sagen kann: Der verschlüsselte Codeblock beinhaltet ein Array welches einer $GLOBALS Variable zugewiesen werden soll.
Und genau dieses globale Array gibt erst wirklich Auskunft über das Wesen des gesamten Scripts. Anmerkung: Die Schreiber_innen von fox.php arbeiten gerne mit globalen Variablen.
Manch einer würde sagen, dass globale Variablenvereinbarung kein guter Stil ist - ich bin so nicht der Meinung. Ich mag globale Variablen, aber Geschmäcker sind verschieden.
Gehen wir dazu über, jene Zeilen des Scripts zu zitieren, die ein Indiz für das Wesen des Scripts sein können.
Wie Eingangs schon erwähnt, können die Befehle sowohl einen Server kompromittieren aber auch reparieren.
Zur Erinnerung: Den Inhalt der $GLOBALS{K} konnte ich nicht ermittlen. Dieses K wurde auch von mir hinzugefügt, weil es im Originalscript ein kryptisches Zeichen jenseits von UTF-8 ist.
Das K wurde als Konstante definiert mit drei unlesbaren Zeichen als Wertzuweisung.
Starten wir mit:
$dirs = array($GLOBALS{K}{0x0033},$GLOBALS{K}[0x00034],"$root/wp-content/plugins/wordfence");
Diese Variablenvereibarung als Array zeigt uns, dass ein Verzeichnis auf einer Wordpress Installation manipuliert werden soll.
Zur Info: Wordfence ist ein Sicherheitsplugin. An dieser Stelle wurde ich das erste Mal nachdenklich über die Dichotomie des Scripst.
Des weiteren irritieren mich die geschwungenen Klammern.
@ini_set($GLOBALS{K}[0],NULL);
@ini_set($GLOBALS{K}{0x001},0);
@ini_set($GLOBALS{K}[0x0002],0);
Hier haben wir ein starkes Indiz für ein destruktives Script. Schließlich will niemand, dass ein fremdes Script Änderungen an der PHP-Konfiguration vornimmt.
Außergenommen natürlich, die Änderung ist Notwendig um ein Sicherheitsdispositiv aufrecht zu erhalten.
Da ich keine Wordpress Installation habe, will ich definitv nicht, das dieses Script diese drei Einstellungen deaktiviert.
Was auch immer in diesem $GLOBALS{K} Array steht! Die Fehlermeldungen für die Befehle werden unterdrückt!
chmod($root.$GLOBALS{K}{0x000035},0644);
unlink($root.$GLOBALS{K}[0x0000036]);
Die chmod Befehle wurden im Script des öftern abgesetzt. Immer mit dem Oktal 0644. Kein äußerst verdächtiges 0777 oder ähnliches.
Mit 644 will man auch nicht groß aufallen - das sind aber nur Spekulationen.
unlink() löscht eine Datei aus der Verzeichnisstruktur. Ich vermute in der $root Variable das Wurzelverzeichnis der Webspace-Installation.
Eigentlich will ich persönlich nicht, dass ein fremdes Script auf meinem Server ein chmod() bzw. unlink() ausführt.
Wie es bei Wordpress-Besitzer_innen ist, kann ich nicht beurteilen.
Würde das gesamte Script nur ein einfaches echo 'Hallo, ich war da!'; ausführen, dann hätte ich keine ernsthaften bedenken (selbst wenn ich sowas auch nicht will).
Da werden noch weitere Dateien gespeichert und mit chmod verändert. Außerdem wird noch ein JavaScript-Einzeiler mit einem location.href (also einer automatischen Weiterleitung) irgendwo untergebracht.
Fazit
Laut Google Recherche wurde das Script schon des öfteren behandelt und ebenso oft auch wieder von den online Präsenzen gelöscht.
Nicht unbedingt den haargenau gleichen Code aber in der Struktur ähnlich findet man auf:
Für die Hyperlinks kann ich keine Garantie abgeben.
Das ich dieses Script weder auf meinem Server (in Prod) noch in meiner XAMPP Sandbox (in Dev) ausgeführt habe, sollte wohl auf der Hand liegen.
Da ich zwar einen Beitrag zur allgemeinen Internetsicherheit leisten aber zugleich nicht Hackern ein Werkzeug geben will ist diese Arbeit äußerst gekürzt und nur auf Schlüsselsätze beschränkt die als
'Zitation von Unbekannt' gelten sollen. Besonders mag ich die Vorstellung, dass etwas sowohl nützlich als auch zugleich schädlich sein kann und nur ein kleines Element wirklich über das Wesen entscheidet.
Auch das man Vertiefung und Verständnis braucht um wirklich über Gut und Böse zu urteilen schmeichelt meinem Geist.
Ich stelle diese Arbeit zur Diskussion!