daily.out
2012-06-02 CSI: MacMark – Flashback Crashlog
Der Flashback-Payload, der mir vorliegt, bringt Safari sofort zum Absturz. So sagte ich im Interview mit GIGA\\Mac (macnews.de). In diesem Artikel möchte ich das näher beschreiben.
Dreifach-Impfung
Ich habe drei Wege durchgespielt, die dynamische Library, also den eigentlichen Payload von Flashback, in Programme zu injizieren.
- Start per Shell mit DYLD_INSERT_LIBRARIES=/Users/Shared/Flashback.dylib /Applications/Safari.app/Contents/MacOS/Safari
- Direkte Manipulation von /Applications/Safari.app/Contents/Info.plist mit Root-Rechten. Darin wird LSEnvironment so gesetzt, daß DYLD_INSERT_LIBRARIES auf die Flashback.dylib verweist. Safari sollte damit, egal wer ihn startet, die Flashback.dylib laden. Hier ist auch noch ein sudo touch /Applications/Safari.app nötig, damit die Änderung bemerkt wird. Diesen Weg nahm Flashback, wenn man ihm ein Admin-Paßwort gab.
- Manipulation von ~/.MacOSX/environment.plist mit User-Rechten, so daß DYLD_INSERT_LIBRARIES auf die Flashback.dylib verweist. Damit sollte jedes (GUI-)Programm, das dieser User startet, die Flashback.dylib laden. Hier ist ein Neustart sinnvoll, um die Änderungen wirksam zu machen. Diesen Weg nahm Flashback, wenn man ihm kein Admin-Paßwort gab.
Mac OS X Lion 10.7.4 verhält sich bei der dritten Variante anders als Mac OS X Lion 10.7.0: Die ursprüngliche Version von Lion versucht Einträge zu laden, die mit DYLD_* beginnen. 10.7.4 macht das bei meinen Tests nicht. Anscheinend hat Apple hier etwas geändert.
Apple härtet Mac OS X
Ein Blick in das Security-Update, das Teil von 10.7.4 war zeigt, daß es tatsächlich so ist:
Wenn OS X Lion 10.7.4 (oder das Sicherheitsupdate 2012-002 für Snow Leopard) installiert ist, werden die DYLD-Startvariablen in der Datei "~/.MacOSX/environment.plist" nicht mehr geladen.
Und hier schreibt Apple:
Zusätzlich werden mit diesem Update Umgebungsvariablen für den dynamischen Linker aus einer angepassten Umgebungseigenschaftenliste im Benutzerverzeichnis des Benutzers gefiltert, sofern vorhanden.
Sehr schön, denn das war der Weg, den Flashback nutzen mußte, wenn man ihm kein Admin-Paßwort gab. Damit ist das Verhalten synchron mit dem env-Befehl, der auch zuvor schon die DYLD-Variablen ausfilterte. Die DYLD-Variablen werden über ~/.MacOSX/environment.plist nur noch geladen, wenn man mit Root-Rechten die Datei /var/db/.launchd_allow_global_dyld_envvars anlegt. Ansonsten berücksichtigen Programme ab jetzt nur noch DYLD-Variablen in ihrere eigenen Info.plist innerhalb des Programms. Die zu ändern, erfordert bei aus dem App Store installierten und vorinstallierten Programmen typischerweise Root-Rechte.
Crash! Boom! Bang!
Aber zurück zu meinem Flashback-Test. In allen Fällen, in denen die Flashback.dylib tatsächlich in Safari geladen wurde, stürzte Safari ab. Das zeigt sich erst so:
Und im Detail so:
Hier sind ein paar komplette Crashlogs:
- 10.7.0 und älterer Firefox, Flashback über ~/.MacOSX/environment.plist: Crashlog
- 10.7.0 und iTunes mit Netzverkehr, Flashback über ~/.MacOSX/environment.plist: Crashlog
- 10.7.0 und Safari, Flashback über ~/.MacOSX/environment.plist: Crashlog
- 10.7.4 und Safari mit Flashback über Shell gestartet: Crashlog
- 10.7.4 und Safari mit Flashback über Safaris Info.plist: Crashlog
- 10.7.4 und Twitter mit Flashback per Shell gestartet: Crashlog
Programme, die keine Internet-Aufrufe machen, beispielsweise TextEdit, blieben von Abstürzen verschont, auch wenn ich ihnen den Flashback-Payload direkt per Shell verpaßte. Anscheinend pfuscht Flashback nicht an jedem Programm herum, in dem sein Payload verwendet wird.
In einem früheren Beitrag hatte ich beschrieben, welche Schwierigkeiten Flashback hatte, überhaupt seinen Payload zu injizieren. Der Weg über die ~/.MacOSX/environment.plist ist, wie oben beschrieben, jetzt auch noch dicht. Und selbst wenn der Payload geladen wird, dann killt er umgehend das Programm, dessen Internetverkehr er eigentlich mißbrauchen will. Zumindest mit dem mir vorliegendem Payload. Es gibt natürlich möglicherweise noch beliebig andere Payloads, aber an diesem, der aus freier Wildbahn stammt, kann man sehen, daß die Malware-Entwickler es einfach nicht drauf hatten.
In diesem Zusammenhang möchte ich nochmal daran erinnern, daß Uli Ries behauptet, Flashback würde immer funktionieren und seinen Payload, die Library, immer laden können. Ihm sei nämlich von F-Secure, Intego, Kaspersky und Symantec bestätigt worden, daß "der Schädling schon seit September 2011 vollkommen funktionstüchtig ist". Also, ich sehe hier in erster Linie voll funktionstüchtige Application-Crashs. Die AV-Hersteller haben kein Interesse daran, diesen Teil der Wahrheit zu erzählen.
CSI: MacMark
Noch ein Blick auf die Stelle, an der man ganz offensichtlich erkennen kann, daß die Flashback.dylib Funktionen abfängt: otool /Users/Shared/FlashBack.dylib -vl | grep __interpose -C4
attributes (none)
reserved1 0
reserved2 0
Section
sectname __interpose
segname __DATA
addr 0x000000000002db80
size 0x0000000000000020
offset 187264
Eine __interpose Section im __DATA-Segment. Offensichtlicher geht es ja nicht. Dann können wir noch mit einem Disassembler, dem IDA für Mac OS X, mal einen Blick in die Flashback.dylib werfen:
Da ist das Interposing wieder.
Und interposed werden CFReadStreamRead und CFWriteStreamWrite. CF steht für Core Foundation, was die komfortablen Mac OS X- und iOS-Frameworks auf niedrigerer Ebene kennzeichnet.
Flashback ersetzt also Funktionen zum Lesen und Schreiben von Datenströmen. Und wie man an den Crashlogs sieht, fummelt Flashback an Code herum, der mit URLs und HTTP zu tun hat.