daily.out

2012-04-26 Kronzeuge der Skeptiker

Was bisher geschah.

Malware aus der Herbst-2011 Kollektion

Letztes Jahr, 2011, hatten die ersten Versionen von Flashback keinen besonderen Erfolg. Sie erreichten keine signifikante Verbreitung und richteten keine pressetauglichen Schäden an. Da es auch davor schon öfters Malware-Rohrkrepierer für Mac OS X gab, die aufgrund der Unkenntnis ihrer Autoren frühzeitig auf der Strecke blieben, fragte ich mich auch diesmal, woran es wohl technisch liegen mag.

Die Beschreibungen der AV-Leute zeigten, daß Flashback eine dynamische Library in Programme laden möchte, um deren Verhalten zu ändern. Dazu enthält so eine bösartige Library einfach andere Implementationen von Standard-Funktionen aus Standard-Libraries. Das wäre der übliche Weg, dem man das Überschreiben auch nicht direkt ansieht. Es gibt seit 10.4 Tiger zwar noch eine deklarative Variante, die prinzipiell das gleiche tut, aber die hatte ich anfangs nicht in Erwägung gezogen, weil sie, würde man damit Malware schreiben, zu offensichtlich am Binary zu erkennen wäre. Und da die übliche Variante auf Mac OS X noch eine zweite Umgebungsvariable verwenden muß, die für andere Systeme nicht nötig wäre, um die Library erfolgreich zu laden, ging ich von einem typischen Portierungsfehler aus, denn diese Variable kam nicht vor. Es schien mir die perfekte Erklärung zu sein, warum Flashback in 2011 nicht aus dem Quark kam. Da ich keinen Flasback aus der Kollektion "Herbst-2011" hatte, konnte ich meine Vermutung leider nicht näher prüfen. Allerdings erschien sie mir ziemlich plausibel, da sie nicht nur seinen Mißerfolg erklären konnte, sondern auch den Umstand berücksichtigte, daß dieses Trojanische Pferd eine Kopie bereits jahrelang kursierender Windows-Trojaner war, die auf den Mac portiert wurde, und ein solcher Plattform-Fehler dabei gar nicht unerwartet passieren würde. Somit mußte ich gar nicht groß nach weiteren Fehlern von Flashback suchen, denn dieser wäre schon ein K.O.-Kriterium gewesen.

Außerdem wußte ich, daß ein mit Umgebungsvariablen und dynamischen Libraries zusammenhängendes Problem in Mac OS X im April 2007 behoben wurde, bei dem Benutzern eine Eskalation auf Root möglich war. Und nichts wünscht sich eine Malware mehr, als uneingeschränkt mit Root-Rechten agieren zu können. Sollten die Lümmel diesen Bugfix übersehen haben, wäre das eine weitere Erklärung, warum Flashback "Herbst-2011" keine große Nummer wurde.

Ich vermutete also 2011 technische Unzulänglichkeiten in Flashback, die in behinderten.

Malware aus der Frühjahr-2012 Kollektion

Im April 2012 gab es wieder Schlagzeilen zu aktualisierten Flashback-Versionen, deren Weg, Code einzuschleusen, weiterhin über dynamische Libraries ging. Die Beschreibungen waren in diesem Punkt praktisch unverändert. Nur der initiale Schritt, um auf die Platte zu kommen, war offenbar durch einen Java-Exploit ersetzt worden, aber der Rest schien gleich. Etwas genervt, daß diese Klamotte anscheinend nochmal aufgetischt wurde, schrieb ich einen entsprechenden Artikel, da mich ein Leser um meine Einschätzung zum aktuellen Rauschen im Blätterwald gebeten hatte. Ich hatte ursprünglich überhaupt nicht vor, mich noch einmal zu Flashback zu äußern, denn für mich war die Sache mit meinem Blog-Eintrag von 2011 abgeschlossen gewesen. Mein Blogeintrag von 2012 fiel dann auch entsprechend launisch aus.

The one and (l)only

Ich war anscheinend immer noch der Einzige, der sich Gedanken machte, woran es wohl technisch liegt, daß Flashback auch weiterhin keine bekannte böse Aktion ausgeführt hatte. Er infiziert den Rechner zwar mehr oder weniger erfolgreich, richtete aber keine Schäden für die Benutzer an. Darum ging ich weiter von meiner Einschätzung aus, es läge an einem Konfigurations-Fehler. Mein Artikel stieß für mich völlig unerwartet auf weltweites Interesse. Es gab Verlinkungen aus den USA, Übersetzungsversuche aus Rußland und haufenweise Verweise im deutschsprachigen Raum und sogar eine Erwähnung in einer Sendung von Mac-TV.

Da macht man sich spontan aus der Hüfte geschossen ein paar Gedanken, warum der Schädling des Monats sich nicht so richtig böse verhält, und schon steht man mittendrin im Geschehen. Das kann eigentlich nur daran liegen, daß die meisten Seiten nur noch vorgekaute Nachrichten in ihren Blogs abschreiben und die Pressemitteilungen der AV-Industrie ungeprüft kopieren. Wo sind die Leute hin, die sich selbst Gedanken machen, und das womöglich noch vor einem eigenen technischen Background?

Der Kopf ist rund, damit die Gedanken, ihre Richtung ändern können

Kurz drauf wurde mir die Einschätzung eines AV-Herstellers zugetragen, der meine Analyse prinzipiell als richtig beurteilte, aber leider auch als nicht ganz auf Flashback zutreffend, denn ich erfuhr dabei, daß die Spitzbuben tatsächlich die von mir zwar inzwischen erwähnte, jedoch verworfene Variante des Interposings einsetzen, zumindest in dem Trojaner aus der Edition "Frühjahr-2012".

Die neue Erkenntnis hob zwar das völlige und sofortige K.O. der Malware auf, aber eben nicht alle Schwierigkeiten, mit denen Flashback auch dann aufgrund seiner Funktionsweise noch zu kämpfen hat, denn Flashback hat konzeptionelle Probleme und Implementierungs-Schwächen. Aber dazu komme ich weiter unten.

Zu der Zeit habe ich mich weder groß in Foren noch auf meiner Homepage weiter geäußert, was mir einige dann als Rückzug auslegten. Tatsächlich arbeitete ich in dieser Zeit an einem Artikel für Mac & i und hatte einerseits keine Zeit, darauf zu reagieren, und andererseits wollte ich mir die Infos für den Artikel bei heise aufsparen, der mir übrigens sehr viel Spaß gemacht hat genauso wie die Zusammenarbeit.

Crashlogs, Abstürze und Paßwortdialog

Es gab diverse Crashlogs, dokumentierte Programmabstürze, die durch das Reinladen der Malware-Library direkt beim Programmstart in vielen Fällen passierten. Einerseits waren das ganz banale Inkompatibilitäten zwischen der injizierten Intel-Library und PPC-Programmen, andererseits waren es auch logische Code-Probleme, die die durch die Malware dann veränderten Programme zum Absturz brachten wie im Falle von Skype. Ein weiterer Punkt, der Flashback an der Injektion hindern konnte, ist, daß sie überhaupt Umgebungsvariablen verwenden. Das hat zur Folge, daß die Injektion nicht immer funktioniert. So setzt Flashback in einem Teil der Fälle seine Umgebungsvariable in der Datei ~/.MacOSX/environment.plist, die jedoch komplett ignoriert wird, wenn ein Leopard Programme über Spotlight (Lupe, oder intelligente Ordner) startet. Die zahlreichen Absturzprobleme zwangen die Spitzbuben dazu, Flashback um eine Liste von Programmen zu ergänzen, bei deren Vorhandensein die Infektion storniert wurde, weil Flashback in all diesen Fällen zu Abstürzen der Apps führte und ein kleines bißchen zuviel Aufmerksamkeit bekäme. Aber es war zu spät. Neben verdächtigen Verbindungen, die Little Snitch meldete, waren es hauptsächlich diese Abstürze und die resultierenden Crashlogs, die Flasback enttarnten. Microsoft, Skype, Apple und weitere Hersteller bekamen User-Berichte, in denen die seltsamen Abstürze dokumentiert wurden. Schnell war klar, was hier vorging, denn an den Crashlogs war zu erkennen, daß bis dato unbekannte komische Libraries von für Libraries ganz ungewöhnlichen Stellen der Platte nachgeladen und injiziert wurden und dabei die Crashes verursachten.

Im Nachhinein betrachtet, war meine ursprüngliche Analyse mit dem Material, was mir zur Verfügung stand, gar nicht übel und lag nur in Bezug auf die Art des Interposings mindestens bei der 2012er Version von Flashback etwas daneben. Ich hatte halt nicht damit gerechnet, daß sie den lauten und plumpen Weg wählten. Die grundlegende Einschätzung, daß sie handwerkliche Fehler machten, war jedoch korrekt und letztendlich auch der Grund, der die Malware auffliegen ließ. Meine Einschätzung, daß die Library aufgrund der Umgebungsvariable in keinem Fall geladen werden kann, muß ich mindestens für die "Frühjahr 2012 Edition" von Flashback darauf reduzieren, daß sie nur in manchen Fällen aufgrund der Nutzung von Umgebungsvariablen nicht geladen werden kann. Trotzdem gilt aber, daß allein die Idee, sich auf Umgebungsvariablen zu verlassen, den Schädling unzuverlässig macht. Meine ursprüngliche Vermutung, daß Flashback technische Probleme hat, blieb jedoch bestehen, wenn auch aus etwas anderen Gründen:

Konzeptions-Probleme in Troja

Der aktuelle Flashback versucht anscheinend in erster Linie speziell Safari zu manipulieren, um über eingeblendete Werbung oder umgeleitete Suchen oder manipulierte Treffer-Ergebnisse und dergleichen irgendwie Werbeeinnahmen zu kassieren. Wie dem auch sei, man kann auf jeden Fall erkennen, daß Flashback den Netzwerkverkehr des betroffenen Programmes mithören und manipulieren möchte, weil er die entsprechenden Funktionen mit seiner Library ersetzt.

Das funktioniert natürlich nur solange, wie die Malware unentdeckt bleibt. Und hier hat Flashback ein konzeptionelles Problem: Um halbwegs zuverlässig zu funktionieren, versucht er, sich am liebsten nur in Safari einzuschleusen, indem er Safari.app direkt verändert. Dazu benötigt er Root-Rechte. Die bekommt er nur über einen Paßwort-Dialog. Und der ist eigentlich schon zu auffällig für eine Undercover-Malware. Flashback braucht den Paßwort-Dialog, um sich zuverlässiger zu installieren und Abstürze von anderen betroffenen Programmen zu vermeiden.

Kommt Flashback nicht an Root, dann bleibt ihm nur übrig, sich mit User-Rechten in alle Programme des Users zu injizieren, weil er Safari.app nicht direkt auf der Platte manipulieren kann. Damit läuft Flashback jedoch Gefahr, inkompatibel mit irgendeinem der vielen Programme zu sein. Und das ist auch wieder zu auffällig.

Es gibt geschicktere Wege, die die beiden Probleme, die Flashbacks generelles Vorgehen provoziert, umgehen könnten. Beispielsweise eine bösartige Safari-Extension.

Pferdefüße in Troja

Uli Ries behauptet (Archiv), Flashback würde immer funktionieren und seinen Payload, die Library, immer laden können. Ihm ist nämlich von F-Secure, Intego, Kaspersky und Symantec bestätigt worden, daß "der Schädling schon seit September 2011 vollkommen funktionstüchtig ist". Tja, da haben sie Dich angelogen, Uli. Oder sie haben, wie ich schon im Herbst 2011 vermutete, selbst vom Mac nicht so die Ahnung. Warum? Wie ich in einem späteren Artikel nochmal erläutert habe, funktioniert Flashback nämlich ganz und gar nicht zuverlässig, weil Flashback neben dem konzeptionellem Problem, auch diverse Implementierungs-Probleme hat:

Sieht das nach "vollkommen funktionstüchtig aus"? Das glaube ich nicht, Tim, äh Uli.

Aber Uli ist trotz handfester Beweise "eher geneigt den AV-Herstellern zu glauben" als mir. Denn F-Secure, Intego, Kaspersky und Symantec sagen ja unisono, daß "der Schädling schon seit September 2011 vollkommen funktionstüchtig ist". Man muß bloß alle Fälle rausrechnen, bei denen der Payload nicht mal reingeladen wird in Programme, und alle Fälle, bei denen er nach dem Reinladen die betroffenen Programme umgehend abstürzen läßt. Aber mir als "Kronzeuge der Skeptiker" und mir als "Sprachrohr für die eisenharten Mac-Fans" (Originalwortlaut von Uli) sollte man so etwas nicht glauben, denn ich versuche selbständig zu denken.

Der Uli schreibt weiter: "Auch nachdem er mit dieser Erklärung konfrontiert wurde (Uli hatte mich per Email um eine Stellungnahme gebeten), bleibt Möller per E-Mail bei seiner Version: Flashback funktioniert nicht, der Schädling sei von zweifelhafter Code-Qualität." Du hast mich falsch zitiert, denn tatsächlich schrieb ich Dir: "Das Runterladen und Erstinstallation war nie in Frage gestellt. In Frage steht die Qualität der Malware insgesamt und daß sie Probleme hat, die nachgeladenen Payloads, also die dylibs, zum Laufen zu bringen. Wenn Du meine aktuelle Analyse (den zweiten Blogeintrag) liest, siehst Du, daß sie 3 verschiedene Teilthemen bezüglich Interposing behandelt, die auch von Deinem AV-Kontakt genannt werden." Und genau das stimmt exakt so wie ich es Dir gemailt habe.

In einem Update ergänzt Uli, in meinem Artikel für Mac & i sei "keine Rede mehr davon, dass Flashback nicht funktioniert". Da hat Uli anscheinend die zweite Seite nicht gelesen, auf der ich die Abstürze beschreibe.

Uli weiß auch, warum die Worte vom "Sprachrohr für die eisenharten Mac-Fans" falsch sind: "Denn Möllers Ausführungen sind an diversen Stellen (Sinkhole-Erklärung, Localhost-Phänomen, Trojaner-Hinweis am Ende) fehlerhaft beziehungsweise zeugen von grobem Unverständnis." So so, dann schauen wir mal:

Sinkholing Botnets

Uli hat das in ein paar Emails an mich etwas näher ausgeführt, in denen er mich um eine Stellungnahme gebeten hatte. Er meinte, daß die Verbindung zu den Sinkholes (bzw. den C&C Servern) erst stattfindet, nachdem der Payload runtergeladen und erfolgreich installiert wurde. Das stimmt nicht, denn es finden vorher Verbindungen statt und auch zum Runterladen der Payloads wird ja erstmal einer der C&C-Server kontaktiert, siehe meinen Artikel auf heise oder die Beschreibungen der AV-Leute.

In einem Update seines Artikels freut er sich, daß ich in meinem heise-Artikel "Sinkholing plötzlich als eine fundierte statistische Berechnung" bezeichne. Lieber Uli, Dir ist dabei der Nebensatz entgangen, der die Bedingung stellt, daß die Bots streng mathematisch zufällig aus den C&C Servern einen wählen. Der Nebensatz, der mit "unter der Bedingung" eingeleitet wird. Wie wir außerdem sehen, wird die Bedingung nicht immer erfüllt, weil anscheinend einige Bots in Standby verfallen sind.

Hier schreibt Uli: "Nachtrag: Damit auch Menschen wie Markus Möller verstehen, wie Sink Holing ohne einbeziehen von Strafverfolgern oder ISPs funktioniert: Kaspersky erklärt es hier ganz gut".

Du irrst Dich, Uli, denn ich bezog mich auf: "Doctor Web's analysts employed the sinkhole technology to redirect the botnet traffic to their own servers and thus were able to count infected hosts."

Ich schrieb dazu: "Dr.Web kann den Botnetz-Verkehr gar nicht alleine umleiten. Dazu (sink holing) benötigt man Hilfe von offiziellen Stellen, die die Internet-Domains für die Command & Control-Server registriert haben, damit die den entsprechenden Verkehr umleiten. Das können die Analysten von Dr.Web aber nicht selbst." Im Zweifelsfall auch gerne nachzulesen hier: Sinkholing Botnets.

Dr. Web behauptet aber, daß seine Analysten den Botnetzverkehr umgeleitet haben. Das können sie definitiv nicht, weil sie das Mapping der DNS-Provider von registrierten Domain-Namen auf IP-Adressen nicht selbst verändern können. Das können nur die DNS-Provider. Und die tun das nur, wenn eine Ermittlungsbehörde sie dazu drängt. Und so funktioniert Botnet-Sinkholing: Man bittet die DNS-Provider darum, die Adressen auf andere Server umzuleiten, auf die Sinkhole-Server der Ermittler.

Dr. Web hat nichts umgeleitet, nichts "redirected". Das ist ganz platt gelogen. Was Dr. Web gemacht hat ist: Sie haben zusätzliche Adressen rechtzeitig reserviert, die voraussichtlich auch für weitere Botnet-Control-Server verwendet werden sollten von den Spitzbuben. Den, auf diesen ganz neu registrierten Namen anfallenden Verkehr, hat Dr. Web dann beobachtet. Sie haben aber nicht den Botnet-Verkehr umgeleitet. Sie haben mit zusätzlichen neuen Servern einen Teil des späteren Verkehrs abgehört ohne irgendetwas umzuleiten. Die Bots wählen den Control-Server halbwegs zufällig und darum hat Dr. Web auch nicht den ganzen, sondern nur einen Teil des Verkehrs abgegriffen und dann statistisch hochgerechnet.

Crashlogs

Uli hat in seinen Emails an mich auch abgestritten, daß es überhaupt Crash Logs wegen Flashback gibt. Das wären alles normale Dumps. Er muß das auch bestreiten, denn sonst wäre Flashback ja nicht "vollkommen funktionstüchtig".

Localhost "Phänomen"

Dr. Web wollte zeigen, daß es Malware-Server gibt und nannte Beispiel-URLs. Solche Beispiele sind aber ganz besonders nutzlos, wenn sie auf Localhost zeigen. Warum die auf Locolhost zeigen, ist dabei völlig egal, denn URLs taugen in keinem Fall dann als Beispiel für Malware-Server, wenn es dort keine Malware gibt. Wenn man Beispiele bringt, sollten die nicht leer sein, okay? Ich weiß, die genannten Domains waren bis eben noch rappelvoll mit Malware, die nur Dr. Web gesehen hat. Und Dr. Web hat die dann sofort alle stillgelegt. Kann sein, ist aber kein Beweis.

Trojaner-Hinweis am Ende

Mein abschließender Hinweis, daß mit 10.8 Trojaner prinzipiell mehr Schwierigkeiten bekommen werden, war korrekt. Auch wenn Gatekeeper bei Malware, die sich selbst runterlädt, nicht greifen kann.

Unverständnis

Und zu meinem "Unverständnis" schreibst Du ja selber: "Ein Vertreter von F-Secure erklärt, dass Möllers Analyse prinzipiell richtig ist …" Und die Stelle, die ich anfangs mit guter technischer Begründung anders erwartet hatte, hatte ich bereits ergänzt, bevor Du mich "mit dieser Erklärung konfrontiert" hast.

Aktuelle Verbreitung

Dr. Web berichtet, daß die Zahl infizierter Macs angeblich gar nicht groß zurückgegangen ist. Und das obwohl nicht nur Apple, sonderen jeder AV-Hersteller, der was auf sich hält, Killer-Programme unters Volk gebracht hat. Speziell Apples automatisches Update sollte nach meinem Dafürhalten inzwischen 80% aller Infektionen beseitigt haben.

Wie kommt Dr. Web nun auf seine Einschätzung? Sie sagen, viele der Bots wären in einen Standby-Modus versetzt worden und diese würden keine C&C-Server mehr kontaktieren, also auch keine, die von den AV-Firmen besetzt sind. Aber seltsamerweise melden sich die Bots angeblich immer noch bei Dr. Web. Seltsamerweise. Nach den Zahlen von Dr. Web müßten die Killer von Apple und den AV-Herstellern völlig nutzlos gewesen sein. Ich bin gespannt, was Dr. Web noch so berichten wird über den weiteren Verlauf.

Valid XHTML 1.0!

Besucherzähler

Latest Update: 17. September 2017 at 18:39h (german time)
Link: osx.realmacmark.de/blog/osx_blog_2012-04-b.php