daily.out

2011-10-11/16/18/25 AV-Firma noch ahnungsloser als Mac-Trojaner-Autor

F-Secure, eine Anti-Malware-Firma mit den üblichen Tools gegen Schädlinge, berichtet über ein Trojanisches Pferd, das auch von Mac OS X selbst erkannt wird: OSX.FlashBack.A. Sie beschreiben, was es tut, wie es funktoniert und wie man es beseitigt. Dabei ist diese Stelle auffällig:

Man soll in der Datei ~/.MacOSX/environment.plist den Eintrag <key>DYLD_INSERT_LIBRARIES</key><string>%path_of_detected_file_from_step_1%%</string> löschen.

Daran sind zwei Dinge sehr merkwürdig: Der Malware-Autor hat keine Ahnung und F-Secure auch nicht, denn keinem von beiden fällt auf, was hier falsch ist. Na, wer bemerkt den Fehler?

Was soll das?

Was möchte der Bösewicht mit dem Eintrag in dieser Datei überhaupt erreichen? Wenn man eine dynamisch geladene Library testen möchte, dann kann man auf der Kommandozeile beim Aufruf eines Programmes die Umgebungsvariable DYLD_INSERT_LIBRARIES setzen und Pfade zu zu verwendenden Libraries übergeben, die dann Vorrang haben. Wenn man jetzt ein Fiesling ist und eine bösartige Library irgendwo abgelegt hat und möchte, daß die von jedem Programm geladen wird, dann sucht man nach einem Mechanismus der Umgebungsvariablen wie diese für alle Programme setzt. Und das ist tatsächlich mit Einträgen in ~/.MacOSX/environment.plist möglich für den jeweiligen User und für seine Login-Session. Was dort an Umgebungsvariablen eingetragen wird, wird beim User-Login gesetzt. So wird beispielsweise dort JAVA_HOME als Umgebungsvariable definiert. Ab Werk ist ~/.MacOSX/environment.plist jedoch nicht vorhanden.

Der Trojaner-Autor hofft also, daß er die Umgebungsvariable DYLD_INSERT_LIBRARIES in ~/.MacOSX/environment.plist so definieren kann, daß seine Malware-Library von Programmen verwendet wird. Er könnte damit dann vorhandene Funktionen in anderen Programmen zur Laufzeit überschreiben oder ergänzen. Man nennt das dann "Hook". Man fängt damit Aufrufe auf bekannte Funktionen ab und verändert das Verhalten. Soweit so gut, ein schöner Plan.

Der Haken mit dem Hook

Der Haken an der Sache ist, daß es nicht funktioniert: Mac OS X ignoriert diesen Eintrag in der ~/.MacOSX/environment.plist, denn es werden laut der Anzeige von /usr/bin/env alle Einträge dort ignoriert, die mit DYLD_ beginnen. Damit stellt Mac OS X sicher, daß mit dieser Umgebungsvariable zusätzliche dynamische Libraries nur individuell, aber nicht für alle Programme, gesetzt werden können. Man muß also tatsächlich explizit beim Aufruf eines Programmes diese Umgebungsvariable direkt übergeben.

Die Malware hat noch andere Funktionen, aber ich finde es interessant, daß der Autor augenscheinlich nicht viel Ahnung von Mac OS X hat und zudem sein Schadprogramm nicht ausreichend getestet hat, sonst wäre ihm aufgefallen, daß das nicht funktioniert. Vieleicht hat er es auch getestet und wundert sich noch heute, warum es nicht klappt.

Und F-Secure schreibt, daß diese Umgebungsvariable einen bestimmten Teil der Schadsoftware laden kann, wenn der Benutzer eines infizierten Systems ein Programm startet. Darum soll man diesen bösen Eintrag auch wieder löschen.

Offenbar wußten auch die Spezialisten bei F-Secure nicht, daß das so nicht funktioniert. Und ich frage mich, für wen das wohl peinlicher ist: Den Malware-Autor oder die Antiviren-Firma?

Getestet

Wie habe ich das geprüft? Ich habe es an einem konkreten Beispiel ausprobiert. Zum einen kann man im Terminal per "env" sich die Umgebungsvariablen anzeigen lassen, die geladen wurden, und schon daran erkennen, daß die Variable nicht übernommen wurde. Zum anderen habe ich es mit einer kleinen "dynamically linked shared library" mal getestet, die einmal direkt beim Aufruf angegeben wird und dann eine Funktion, die das gestartete Programm nutzt, tatsächlich überschreibt, dies jedoch nicht passiert, wenn ich mich nur auf den einzelnen Eintrag in ~/.MacOSX/environment.plist verlasse.

Wer jetzt glaubt, das wäre bestimmt eine Neuerung der letzten Mac OS X-Versionen, der irrt: Ich habe es auf verschiedenen System-Versionen getestet. 10.7, 10.5 und die älteste war ein 10.3. Es funktionierte auf keiner. Alle ignorieren den Eintrag. Das bedeutet, wenn F-Secure oder der Malware-Autor das jemals auf irgendeinem Mac mal durchprobiert hätten, dann wüßten sie, das es nicht geht. Jedenfalls nicht mehr seit dem "Security-Update 2007-04" im April 2007 für Mac OS X 10.3 und 10.4, das unter anderem dafür sorgte, daß der Library-Path für Setuid-Programme nicht mehr in der environment.plist geändert werden können soll. Und für Nicht-Setuid-Programme braucht es noch einen weiteren Eintrag, damit es funktioniert, der von dieser Malware jedoch nicht gemacht wird; Hintergrund ist, daß Mac OS X Two-Level Namespaces verwendet.

Anscheinend schreibt F-Secure Security-Hinweise über Malware, deren Funktion sie überhaupt nicht ausprobiert haben. Wenn F-Secure schon keine Ahnung von solchen Mac-Features hat, dann wäre es doch das Mindeste, daß sie ihre Aussagen mal testen und die Malware auf einem Labor-Gerät laufen lassen.

OSX.FlashBack.B

F-Secure berichtet ein paar Tage später, daß es eine Variante OSX.FlashBack.B der Schad-Software gibt. Diese ergänzt nach ihren Angaben die Dateien /Applications/Safari.app/Contents/Info.plist und /Applications/Firefox.app/Contents/Info.plist um den Eintrag <key>LSEnvironment</key><dict><key>DYLD_INSERT_LIBRARIES</key> <string>%path_of_detected_file_from_step_1%</string></dict>

Variante A wollte noch allen Programmen eine Library unterjubeln, bei Variante B wird versucht, gezielt Safari und Firefox zu manipulieren, so daß sie die angegebene Library benutzen.

Nach meinen Tests, in denen ich die Info.plist in Safari entsprechend änderte und eine eigene Library zum Laden angab, wurde diese Library jedoch auf diese Weise nicht geladen. Wenn ich sie per Kommandozeile wie oben bei Variante A übergab, dann schon. Offensichtlich funktioniert auch diese Malware nicht richtig und F-Secure ist das wieder nicht aufgefallen oder sie ignorieren dies.

Da geht noch was

Die beiden Trojanischen Pferde haben wie es aussieht Umsetzungsfehler, die sie an ihrer bösen Aufgabe hindern. Die Fehler sind auch F-Secure nicht aufgefallen. Damit die beiden Schadprogramme funktionieren können, müßte beispielsweise Variante A noch einen weiteren Eintrag in der ~/.MacOSX/environment.plist benutzen, den F-Secure jedoch nicht als zu löschenden Eintrag erwähnt in der Beschreibung, wie man die Malware beseitigt. Daraus ist zu schließen, daß er von der Malware nicht gemacht wird. Bei Variante B sieht es für mich so aus, als ob diese Art der nachträglichen Programm-Manipulation gar nicht hinzubekommen ist, da ich auf diese Weise meine Test-Library nicht in Safari laden konnte.

OSX.FlashBack.C

Variante C unterscheidet sich von B hauptsächlich darin, daß sie den XProtect-Mechanismus ausschaltet, indem sie einige seiner Dateien löscht. Die dazu erforderlichen Root-Rechte gibt ihr der Benutzer bei der manuellen Installation.

---