daily.out

2012-04-06 Dr.Web und das Botnet

Dr.Bott, äh Web, also Dr.Web, Ihr freundlicher russischer Anti-Virus-As-a-Service Anbieter von nebenan warnt uns Mac-User vor einem Botnetz, das von Flashback-Trojanern errichtet worden sei und über eine halbe Million Macs (Tendenz ganz dolle schnell steigend!) knechte – angeblich.

Der geneigte Leser, der vielleicht besorgt über diese News hier Hilfe sucht, wird sich möglicherweise über meinen ungewohnt sarkastischen und grenzdebil amüsierten Tonfall ärgern. Gebt mir ein paar Zeilen Zeit, um die Situation zu erklären. Die Geschichte von dem bösen Flashback, der ja auf Windows eine große Nummer sein mag, ist auf Mac OS X eine Geschichte voller Mißverständnisse, ich korrigiere: Unkenntnis auf vielen Seiten. Ich hatte mich schon vor einem halben Jahr, damals noch ernsthaft, mit dem Thema beschäftigt, wobei herauskam, daß diese Malware schlicht nicht funktioniert. Es ist ein Trojaner, der bestimmte Einstellungen vornimmt, die aber dummerweise schon immer und seit April 2007 im Besonderen in dieser Form recht wirkungslos sind: AV-Firma noch ahnungsloser als Mac-Trojaner-Autor.

[Update:] Der Artikel von Oktober 2011 ging aufgrund der Schwierigkeiten, die Flashback zu der Zeit hatte, sich zu verbreiten und Schaden anzurichten, von der typischerweise für Angriffe verwendeten Interposing-Variante aus. Ob diese oder die deklarative Variante für Flashback im Oktober 2011 verwendet wurde, weiß ich bis heute nicht. Meine Annahme würde jedoch seine Erfolglosigkeit in 2011 perfekt erklären. Zudem schadet ihm möglicherweise auch, daß seit April 2007 die von ihm genutzten DYLD_* Umgebungsvariablen aus Setuid-Programmen und ihren Kindern ausgefiltert werden.[/Update]

Von daher war ich schon genervt, als dieser Schwachsinns-Trojaner in den letzten Tagen erneut durch die Presse geisterte. Ich hatte einen Flashback, ein Déjà vu.

ars humorica

Kleiner Spaß am Rande: ars technica, seines Zeichens renommierte IT-Webseite, arbeitet gerade daran, mit Flashback ihren Ruf zu ruinieren, siehe Such-und-Rate-Bild. Was ist hier falsch?

Die Schlagzeile verspricht, daß kein Paßwort nötig ist. Was zeigt der Screenshot? Liebes ars technica, ich bin enttäuscht. Aber zurück zum Kernthema.

Inkompetente Spitzbuben: Flashback Nummer 23 (oder so)

Die aktuellen Versionen von Flashback versuchen noch immer (nur auf anderem Weg) die Umgebungsvariable DYLD_INSERT_LIBRARIES zu setzen, um damit anzugeben, welche böse dynamische Library nachgeladen werden soll, um Programmfunktionen zu überschreiben, beispielsweise in Safari. Wie der interessierte Leser bei mir vor einem halben Jahr erfuhr, nutzt Mac OS X jedoch einen zweistufigen Namensraum für dynamic libs. Das bedeutet, daß die Programme die Umgebungsvariable DYLD_INSERT_LIBRARIES ignorieren und die dort genannten bösen eventuell heruntergeladenen Bibliotheken eben nicht laden. Beim Two-Level-Namespace werden die Symbole direkt aufgelöst, weil die Library, in der sie enthalten sind, mit gemerkt wird. Andere Betriebssysteme suchen die Symbole in einem flachen (flat) Namespace, also in allen dynamischen Libraries in Lade-Reihenfolge und merken sich nicht, in welcher Lib das Symbol aufgelöst wurde. Und das hätten die Spitzbuben auch gerne hier, aber so läuft es halt nicht unter Mac OS X. Und aus irgendeinem mir unerfindlichem Grund kapieren sie es nicht und laufen nach 25 gefühlten Flashback-Versionen immer noch gegen dieselbe Wand. Die OS X-Programme interessieren sich typischerweise nicht für Eure "inserted" Libs. Ich weiß, Malware-Jungs haben es nicht leicht am Mac, aber da müßt Ihr Spitzbuben jetzt einfach mal durch.

Noch ein Schmankerl: Dr.Bot sagt, daß der böse Trojaner nachschaut, ob bestimmte Antivirus-Software auf dem Rechner installiert ist und wenn er eine findet, dann beendet er sich. Eine AV-Software, nach der der Trojaner angeblich schaut, ist "/ Developer / Applications / Xcode.app / Contents / MacOS / Xcode". Das ist gleich doppelt witzig, weil Xcode keine AV-Software ist, sondern die Entwicklungs-Umgebung, und weil Xcode in aktueller Version gar nicht mehr unter /Developer liegt, sondern unter /Applications. Daran sieht man nochmal genau, was das für Mega-Malware-Machos sind.

Typisches Interposing

Hier ist ein typisches Beispiel, wie man Library-Funktionen in einem Programm überschreiben kann. Ein C-Programm, das einen String in eine Datei schreibt, und eine Library, die die Funktion fopen zum Öffnen einer Datei mit einer eigenen Implementation ersetzt:

clang -Wall -o lib_overrides.dylib -dynamiclib lib_overrides.c
clang -Wall -o overrides_test overrides_test.c

Beide Binaries nutzen einen Two-Level-Namespace:

otool -hV overrides_test lib_overrides.dylib
overrides_test:
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64 ALL LIB64 EXECUTE 13 1648 NOUNDEFS DYLDLINK TWOLEVEL PIE
lib_overrides.dylib:
Mach header
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC_64 X86_64 ALL 0x00 DYLIB 11 1248 NOUNDEFS DYLDLINK TWOLEVEL NO_REEXPORTED_DYLIBS

Versucht man nun, mit Hilfe der dynamischen Library die Funktion fopen im Programm zu ersetzen mit Hilfe von DYLD_INSERT_LIBRARIES allein, dann funktioniert das nicht, weil aufgrund des zweistufigen Namespaces das Programm weiterhin das original fopen bekommt.

DYLD_INSERT_LIBRARIES=lib_overrides.dylib ./overrides_test
Keine weiteren Ausgaben hier.

Macht man es richtig und schaltet den zweistufigen Namespace aus und um auf einen flachen Namespace, dann funktioniert es: Die neue fopen-Implementierung wird verwendet und macht ihre Ausgabe:

DYLD_FORCE_FLAT_NAMESPACE=1 DYLD_INSERT_LIBRARIES=lib_overrides.dylib ./overrides_test
You're lucky, we just print a comment and not executing nasty commands == fopen: {hello.txt,w} ==

Ob man die Umgebungsvariablen direkt setzt, wie hier, oder beispielsweise in ~/.MacOSX/environment.plist, beeinflußt das Verhalten nicht. Dieses Verhalten deckt sich mit der Dokumentation in den Manual-Pages für ld und dyld. Wer mag, kann die dylib auch in /Users/Shared/ ablegen, wie Flashback das tut, und dann in ~/.MacOSX/environment.plist die eine oder beide Umgebungsvariablen setzen. Zum sauberen Testen jeweils nach Änderungen einen Neustart machen.

Bei den Beschreibungen, wie Flashback beseitigt werden soll, habe ich immer das Umschalten auf den flat namespace vermißt, denn es wurde immer nur DYLD_INSERT_LIBRARIES erwähnt.

Reinladen ungleich Interposing

Im Forum bei heise bin ich gefragt worden:

Ich bin froh, daß Du fragst. Ich habe mich etwas mißverständlich ausgdrückt, wenn ich sagte, die Library würde ignoriert. Sie wird zwar in jedem Fall geladen, was man auch mit dem Debugger gdb per "info sharedLibrary" überprüfen kann, wenn man an den Prozeß "attached". Aber: Eventuelle Funktions-Symbole, die in der "inserted" Library namensgleich sind mit originalen Library-Funktionen, werden "ignoriert", ein Interposing/Überschreiben findet also nicht statt. Das passiert auch bei dem Highlight-Beispiel nur, wenn man zusätzlich den flat namespace aktiviert.

Oder nochmal anders ausgedrückt: Diese Highlighting-Erweiterung für Xcode macht kein Interposing, sie ändert keine bestehenden Funktionen. Sie fügt einen Menüeintrag hinzu mit Hilfe von vorhandenen Standardfunktionen. Das ist aber nichts, was eine Malware tun möchte.

Eine Malware möchte mit so einer zusätzlichen Library automatisch zusätzlichen Code ausführen oder bestehenden ersetzen. Sie will also typischerweise Interposing machen: Die geladene böse Lib ersetzt eine originale Funktion durch Schadcode und damit das nicht auffällt, ruft sie anschließend auch noch die originale Funktion auf. Das funktioniert aber (auch bei Nicht-Setuid-Binaries) nicht, wenn man sich allein auf DYLD_INSERT_LIBRARIES verläßt, denn aufgrund des two-level namespace wird die originale Funktion genommen und nicht die andere mit gleichem Namen.

Für Setuid-Binaries filtert der dynamische linker/loader von Mac OS X übrigens grundsätzlich alle DYLD_* Umgebungsvariablen raus und sorgt auch dafür, daß sie nicht vererbt werden an deren Kindprozesse. Das wurde eingebaut, nachdem in dem "Month of Apple Bugs" im Januar 2007 auf diese Weise Privilegien eskaliert werden konnten.

Ich habe diese Xcode-Highlighting-Sache auch bei mir ausprobiert; sie funktioniert halbwegs zuverlässig, wenn man die Umgebungsvariable auf der Kommmandozeile setzt. Setzt man sie aber in der plist, dann werden diverse andere Programme erheblich gestört. Um zu zeigen, daß keine Funktionen überschrieben werden, wenn man nur DYLD_INSERT_LIBRARIES einsetzt, habe ich zusätzlich den Code aus meinem Beispiel oben, der fopen-Aufrufe "kommentiert", in das Xcode-"Plugin" übernommen. Die Kommentare erscheinen nur dann, wenn zusätzlich auch DYLD_FORCE_FLAT_NAMESPACE gesetzt wird.

Offizielles Interposing

Oben hatte ich das typische Interposing vorgestellt, das eine Malware benutzen würde – die etwas auf sich hält – um Library-Funktionen durch Malware-Versionen zu ersetzen. Das Interposing ist dort direkt codiert und nicht sofort erkennbar.

Dann gibt es noch ein seit Mac OS X 10.4 Tiger von dyld angebotenes, offizielles Interposing, bei dem man die zu ersetzenden Funktionen und die neuen Funktionen offiziell deklariert. Außerdem muß in solch einer Interposing-Library zwingend eine __interpose Section in ihrem __DATA Segment enthalten sein. Dieses Interposing kann man leicht mit otool in der Library aufspüren:

otool -l libinterposers.dylib | grep -B1 -A4 __interpose
Section
  sectname __interpose
   segname __DATA
      addr 0x0000000000001040
      size 0x0000000000000020
    offset 4160

Hier ist ein Beispiel von Amit Singh aus seinem Buch Mac OS X Internals, Kapitel 2.6.3.4 dyld Interposing, Seite 73f, das open- und close-Funktion mit Kommentaren verziert:

gcc -Wall -dynamiclib -o libinterposers.dylib libinterposers.c
DYLD_INSERT_LIBRARIES=libinterposers.dylib cat /dev/null
--> 3 = open(/dev/null, 0, 0)
--> 0 = close(3)

Da diese Interposing-Variante offiziell im Code deklariert und von dyld aktiv unterstützt wird, hat man ein paar Vorteile: Man kann die überschriebene Funktion weiterhin per Name aufrufen und muß sich ihre Adresse nicht erst besorgen und man muß nicht auf einen flat namespace umschalten, weil hier ja das Interposing selbst höchst-amtlich deklariert und gelinkt wird.

Apple definiert dafür sogar extra ein Makro: #define DYLD_INTERPOSE(_replacment,_replacee), das einem bei der offiziellen Deklaration von Original und Fälschung unterstützen kann.

Für einen Malware-Autoren sind solche offiziellen Interposing-Libs nicht sonderlich geeignet, da es viel zu auffälliges Interposing ist. Die Viren-Scanner könnten sich auf den oben genannten grep-Befehl beschränken, um verdächtige Libraries zu untersuchen. Daher glaube ich nicht, daß die Flashback-Jungs diese Variante benutzen. Sollten sie es doch tun, wäre meine Enttäuschung über die Qualität dieser Wonnabe-Malware noch größer. Aber möglich ist das natürlich, wenn man bedenkt, daß sie sich zwar Admin-Credentials vom User geben lassen, damit jedoch kein Rootkit installieren, sondern ihren Krempel im Klartext im User-Verzeichnis ablegen. So unauffällig wie ein Elephant im Porzellanladen und nicht ein bißchen smart oder clever.

[Update:]Später bekam ich indirekt die Info von einem AV-Hersteller, mutmaßlich russisch und von Kaspersky, daß die aktuelle Flashback-Version tatsächlich dieses deklarative Interposing verwendet, wodurch dann erklärt wäre, warum er die Library in vielen Fällen laden kann. Siehe auch meinen aktuelleren Artikel bei heise.[/Update]

Verschiedene Wege und Versionen

Der Weg, auf dem das trojanische Flashback-Pferdchen auf den Rechner gelangt, ist je nach Version unterschiedlich. Das kann über einen gefälschten Flash-Installer passieren oder über einen Bug in der Java-Sandbox für Browser-Applets oder wie auch immer. Das ist ziemlich egal. Nicht egal ist der eigentliche Infektionsversuch, der den Payload in Form von dynamischen Libraries in Programme injizieren möchte. Auch hierbei versuchen sie sich in verschiedenen Varianten, wie und wo sie die gewünschte Umgebungsvariable DYLD_INSERT_LIBRARIES setzen, die auf die Payload-Libs verweist. Ihr Pech ist, daß diese Variable in keinem der Fälle wirksam ist, weil die Programme sie ignorieren – wie oben beschrieben.

[Update:]Wie oben begründet, war ich von einer für Angreifer naheliegenderen Interposing-Variante ausgegangen. Siehe auch meinen aktuelleren Artikel bei heise.[/Update]

Ob der Trojaner überhaupt auf den Rechner gelangt, hängt also je nach Version von der Gutgläubigkeit des Users oder vom Stand der Java-Version ab oder was auch immer noch kommen mag. Der Payload des Trojaners funktioniert bei allen Flashback-Versionen jedoch prinzipiell nicht. Und das ist es, was zählt. Selbst wenn er auf den Rechner gelangt, kriegen die Spitzbuben die eigentliche Schad-Software nicht ans Laufen.

Inkompetente Doktoren

Nun noch zu Dr.Web, unserem russischem Freund und Helfer bei allen Schädlings-Themen rund um den Mac: Sie nennen ein paar Webseiten, auf denen der Schädling zu finden sein soll. Jetzt kommt der Brüller: Die werden alle nach localhost aufgelöst. Wollen die uns veralbern? Okay, das können wir noch toppen. Folgt man ihrem Link zur Beschreibung zu "BackDoor.Flashback.39", dann bekommt man Infos zu Windows. Das ist wahre Mac-Kompetenz, wenn man Mac-Schädlinge beschreiben will, dabei aber von Windows-Interna redet. Dr.Web ist also ein Über-Hacker-Security-Firmen-Weltrettungs Ihr wisst, was ich meine. Die sind einfach unglaublich gut. Dr.Web empfiehlt uns Mac-Usern (kein Witz!):

1. Windows neustarten im Safe Mode
2. Dann mit dem Dr.Web Scanner des kostenlosen Heilmittels "Dr.Web® CureIT!" die lokalen Platten scannen.
3. Die Registry vom Backup wiederherstellen

Das "Dr.Web® CureIT!" (Schleichwerbung auf MacMark.de – Möööööp!) ist ein Exe-Programm, denn das heruntergeladene File "6b3ncdk5.exe" entpuppt sich als:

GoldCoast:Downloads macmark$ file 6b3ncdk5.exe
6b3ncdk5.exe: PE32 executable for MS Windows (GUI) Intel 80386 32-bit

Dr.Web kann also auch zaubern und mit Windows-Mitteln den Mac retten. Respekt! Kein Wunder, denn Dr.Web gibt es bereits seit "20 Jahren", sagt ihre Webseite. 20 Jahre, an die wir uns alle erinnern, weil Dr.Web jedes Jahr fünfmal die Welt gerettet hat mit "Dr.Web® CureIT! für Windows". Und wenn man ein Kind auf der Straße fragt oder einen Hacker nachts aus dem Bett holt und dann fragt: Hey, was ist das Erste, an das Du denkst, wenn es um Antivirus und IT-Security geht? Dann werden sie ohne Nachdenken antworten: "Dr.Web! Der gute Dr.Web. Und nur so Lutscher und Loser wie MacMark.de, die haben noch nie von Dr.Web gehört, denn MacMark lebt in einem Schuhkarton!!!!11"

Dr.Web ist dermaßen gut, daß sie sogar mit "sinkhole technology" den Botnetz-Verkehr auf ihre eigenen Server umgleitet haben und darum die infizierten Rechner zählen konnten. Sagen sie. Da haben sie einen tollen Fachbegriff aufgeschnappt, der mit der Aushebung des ZeuS-Botnetzes bekannter wurde, und der so richtig nach dicker Hose klingt. Klingt, denn 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. Aber das behaupten sie und da frage ich mich, wie und was die denn nun gezählt haben wollen, wenn sie gar nichts umleiten können und vor allem, was wollen sie umleiten, wenn die Bots doch gar nicht arbeiten, weil sie die bösen Libraries (siehe oben) gar nicht verwenden. Fragen über Fragen, gelle?

Schlechte Aussichten für Trojaner

Aber was wurde diese Geschichte nicht überall ungeprüft gebracht. Das Ende der Welt wurde wieder einmal für die Macs erkannt. Und selbst wenn dieser Trojaner korrekt funktionieren würde: Trojaner nutzen den User aus. Wenn der User darauf besteht, das Ding auszuführen, dann kann das System dies nicht endgültig verhindern. Bei Mountain Lion wird es allerdings etwas mehr Hilfe für den User geben: Man kann einstellen, daß nur Programme von bekannten, bei Apple registrierten Entwicklern ausgeführt werden sollen. Auf Lion ist das jetzt auch schon testbar, indem man die System-Policy-Control nutzt mit: sudo spctl --enable (und --disable). Dann wird so gewarnt:

Weiter offen bleibt die Frage, wer es zuerst schnallen wird, daß die Nummer so nicht funktioniert: Die News-Seiten (äh, ja okay war ein Versuch), die Spitzbuben (mit Version 42, der Antwort auf alle Fragen, mmh irgendwie auch unwahrscheinlich) oder die Analysten von den Security-Anti-Viren-Firmen (sie hatten ihre Chance). Letztendlich ruht meine Hoffnung nur auf Euch, den mündigen Usern. Glaubt nicht jede Schlagzeile, die Ihr lest. Außer sie sind von mir. Okay, blöder Witz :-)

---