Untersuchung der Programme in Mac OS X

Noch vor einem Jahr waren hauptsächlich Spezialisten auf dem Gebiet des Designs oder Layouts sowie Fotografen und Musiker die Nutzer von Apple-Computern. Doch das vergangene Jahr wurde in vielerlei Hinsicht zu einem Wendepunkt: nachdem die Firma Apple verkündet hatte, dass ihre Computer jetzt auf der Basis von Intel-Prozessoren herausgegeben werden, lenkten viele ihre Aufmerksamkeit auf Computer von Apple und begannen über deren Nutzung als Heimcomputer nachzudenken. Auch die Software-Hersteller beachteten die wachsende Popularität von Mac OS X und gaben Versionen ihrer Produkte für Mac OS X heraus.

Ungeachtet dessen bleibt Mac OS X irgendwie unverständlich und geheimnisvoll nicht nur für viele Nutzer, sondern auch für Spezialisten auf dem Gebiet der Computersicherheit. Dieser Aufsatz versucht diesen Spezialisten Anhaltspunkte zu geben, welche Besonderheiten von Mac OS X für Untersuchung schädlicher Programme für dieses Betriebssystem kritisch sind.

Mac OS X ist ein Unix-ähnliches Betriebssystem, das viele Charakterzüge besitzt, die auch anderen Unix-Systemen eigen sind. Deshalb wird das weitere Material den Lesern verständlicher sein, die Erfahrung im Umgang mit Systemen wie Linux, Solaris oder FreeBSD besitzen. Auch Erfahrung bei der Programmuntersuchung in beliebigen Betriebssystemen wird den Lesern nützlich sein.

Wesentliche Besonderheiten von Mac OS X

Das Wissen über die Besonderheiten eines Betriebssystems hilft bei der Analyse von Programmen, auch von schädlichen. Viele Besonderheiten von Ìàñ OS X sind mit dessen Herkunft verbunden: Mac OS X wurde auf der Grundlage von Unix-Systemen geschaffen, was sich im Design und den Prinzipien des Systems im Ganzen widerspiegelt, von Mach erbte es die Wechselwirkung zwischen den Prozessoren, von BSD den Netzstack.

Unterstützung von Systemaufrufen von Mach- und BSD-Systemen

Der Kernel von Mac OS X – xnu – basiert auf den Kernels der Betriebssysteme Mach und FreeBSD, beinhaltet aber auch Teile von MkLinux, NetBSD, OpenBSD und einige Ausarbeitungen von Mach. Mac OS X unterstützt Systemaufrufe von Mach- und BSD-Systemen. Da der OS X-Kernel gleichwertig auf Mach und FreeBSD beruht, enthält der Kernel von Mac OS X – xnu – zwei Tabellen von Systemaufrufen von Mach und BSD und unterstützt API für BSD- und Mach-Systeme.

Laufzeitumgebung

Um zumindest einen Teil des Erbes vorangegangener Betriebssystem zu unterstützen, besitzt Mac OS X eine aus 3 Komponenten bestehende Laufzeit-umgebung:

  1. Dyld Runtime Environment. Eine Laufzeitumgebung, die auf dem dynamischen Loader „dyld” basiert.
  2. CFM Runtime Environment. Dieses Erbe von OS 9 dient der Unterstützung von Anwendungen, die von dyld nicht gestartet werden können, aber die Möglichkeiten von Mac OS X ausnutzen. Dieser Teil wird in der Programmbibliothek Carbon realisiert.
  3. Classic Runtime Environment. Dient dem Start alter Anwendungen von OS 9 in OS X.

Somit existiert in Mac OS X die Möglichkeit, verschiedene Anwendungsarten zu starten, darunter auch die von alten Versionen des Betriebssystems Mac OS.

Mach-o-Format ausführender Dateien

In Mac OS X sind fast alle Dateien, die einen ausführenden Code besitzen, so wie z.B. Anwendungen, Bibliotheken, Kernel-Module, als Dateien mit mach-o-Format realisiert.

Das Format mach-o stellt keine originale Ausarbeitung von Apple dar. Es wurde von Open Source Foundation für ihr Betriebssystem OSF/1 entwickelt, das auf mach beruht, und von Apple für die x86-Architektur im Rahmen des OpenStep-Projektes adaptiert.

Das Dateiformat mach-o und die Spezifik ABI (Application Binary Interface) beschreiben, wie eine ausführende Datei vom Kernel zu laden und zu starten ist. Sie teilen dem Betriebssystem unter anderem mit:

  • wie der dynamische Loader arbeitet,
  • wie die geteilten Bibliotheken zu laden sind,
  • wie der Adressraum des Prozesses zu organisieren ist,
  • wo der Einsprungpunkt zu finden ist.

Da mach-o das Hauptformat ausführender Dateien in Mac OS X ist, betrachten wir seine Organisation etwas genauer.

Wie ist mach-o aufgebaut

Mach-o kann man grob in drei Teile gliedern: Kopf, Lade-Kommandos und Segmente, die aus einigen Sektoren bestehen können. Kopf und Lade-Kommandos beschreiben wesentliche Charakteristiken der Datei, während das Datensegment eine Auswahl von Bytes enthält, auf die sich die Lade-Kommandos beziehen.

Kopf. Die ersten 4 Byte im Kopf bestimmen die so genannte magic number, die die Datei als 32-er oder 64-er identifiziert. Außerdem gestatten sie, die Ordnung der Bytes für die CPU zu bestimmen. Der Kopf definiert die Architektur, für die die Datei kompiliert wurde. Das ermöglicht dem Kernel den Start der Dateien nur auf der Plattform zu garantieren, für die die Datei kompiliert wurde. Manchmal kann eine binäre Datei einen Code für mehr als eine Architektur enthalten. Dieses Format ist bekannt als Universal Binaries. In diesem Fall beginnt die Datei mit einem fat-Kopf.

Lade-Kommandos. Der Bereich der Lade-Kommandos enthält eine Liste von Kommandos, die dem Kernel mitteilen, wie verschiedene Dateisegmente zu laden sind. Diese Kommandos beschreiben, wie jedes Segment im Speicher ausgerichtet ist, welche Zugangsrechte es besitzt und wo es im Speicher liegt.

Segmente und Sektionen. Eine ausführende mach-o-Datei hat gewöhnlich 5 Segmente:

  • __PAGEZERO. Auf einer virtuellen Null-Adresse gelegen, hat keinerlei Schutz. Dieses Segment belegt keinen Plattenplatz in der Datei.
  • __TEXT. Enthält Daten mit Zugriff nur zum Lesen und Ausführen.
  • __DATA. Enthält Daten, auf die zum Schreiben zugegriffen werden kann. Diese Sektion ist als copy-on-write gekennzeichnet.
  • __OBJC. Enthält Daten, die für Objective-C Laufzeitumgebung verwendbar sind.
  • __LINKEDIT. Enthält Daten, die für die Einrichtung dynamischer Verbindungen genutzt werden.

Die Segmente __TEXT und __DATA enthalten null oder mehr Sektionen. Jede Sektion enthält einen besonderen Datentyp, z.B. ausführenden Code, Konstante, Zeilen u.a. Somit werden der ausführende und der nicht ausführende Code in einem Segment einzeln gespeichert.

Werkzeuge zur Programmanalyse

Zur Analyse von Programmen existieren zwei grundsätzliche Herangehensweisen: die dynamische und die statische. Die dynamische Analyse sieht den Start des Programmcodes unter einem Debugger vor oder in einer virtuellen Umgebung sowie die Analyse seines Verhaltens. Die statische Analyse des Programms ist eine Untersuchung des Programmcodes mithilfe eines Disassemblers ohne Start des Codes.

Welche Methode in jedem konkreten Fall am besten anzuwenden ist, hängt von der Situation ab. Beide Methoden schließen einander nicht aus, sondern ergänzen sich zum Teil.

Werkzeuge zur dynamischen Programmanalyse

Wie die Mehrzahl der Unix-Systeme so stellt auch Mac OS X viele nützliche Werkzeuge zur Verfügung, die bei der dynamischen Analyse der Anwendungen und bei der Systemdiagnostik helfen. Viele von ihnen kamen aus Unix zu Mac, es gibt aber auch Programme, die ausschließlich für Mac OS X existieren. Nachfolgend betrachten wir einige Werkzeuge, die bei Mac OS X mitgeliefert werden.

Alle Werkzeuge können in zwei Kategorien eingeteilt werden.

  1. Werkzeuge, die sich auf die Untersuchung von Prozessen beziehen:

  • fs_usage — stellt eine Information über Systemaufrufe bzgl. Aktivität im Filesystem zur Verfügung;
  • heap — listet alle Speicherblöcke auf, die im dynamischen Speicher durch einen einzelnen Prozess reserviert wurden;

  • lsof — stellt Dateien dar, die in verschiedenen Prozessen geöffnet sind;

  • top — stellt eine Statistik zur Ausnutzung verschiedener Ressourcen im System dar;
  • vm_stat — stellt eine Statistik zur Ausnutzung des virtuellen Speichers durch das System dar;
  • gdb — Debugger, gestattet es, ein Programm remote zu debuggen;
  • ddb — Debugger des Kernel, erfordert einen Anschluss über einen fortlaufenden Port;
  • ktrace — dient der Verfolgung von Informationen über Systemereignisse im Kernel zu einem angegebenen Prozess;
  • kdump — spiegelt Informationen wider, die vom Programm ktrace generiert wurden;
  • sc_usage — stellt eine Statistik zu einem vorgeschriebenen Prozess dar, wie z.B. Nutzung der Prozessorzeit, Nutzung von Systemaufrufen usw.

  • Netzwerkzeuge.
  • Nachfolgend aufgeführte Netzwerkzeuge sind in der Welt von Unix gut bekannt.

    • netstat — stellt verschiedene Daten zur Verfügung, die sich auf ein Subnetz beziehen;

    • tcpdump — spiegelt den Netztraffic wider.

    Für Ìàñ OS X sind auch viele andere, den Unix-Nutzern bekannte Netzinstrumente wie nmap und WireShark zugänglich.

    Es muss darauf hingewiesen werden, dass die Mehrzahl der Programme mit offenen Quelltexten, die unter Unix existieren, unter Mac OS X leicht gesammelt werden können. Ein erfahrener Unix-Nutzer kann sich eine Arbeitsumgebung schaffen, die sich von der ihm gewohnten Unix-Umgebung wenig unterscheidet.

    Werkzeuge zur statischen Analyse

    Bei der Analyse schädlicher Programme fehlt sehr oft die Möglichkeit, das zu untersuchende Programm zu starten, oder der Start des Programmcodes ist aus Gründen der Sicherheit unerwünscht. Deshalb muss man für die Analyse des zu untersuchenden Programms auf disassemblierte Dateien zurückgreifen.

    Da Mac OS X als ausführende Dateien Files in mach-o-Format nutzt, weist die statische Analyse bei Mac OS X eine Spezifik auf.

    Hauptwerkzeug für die Analyse von Dateien im mach-o-Format ist das Programm otool. Mit seiner Hilfe kann man Informationen wie Kopf der Datei, Lade-Kommandos, Einsprungpunkt und sogar enthaltene Sektionen disassemblieren, die ausführenden Code enthalten, auslesen.

    • file — bestimmt den Dateityp;

    • otool — dient der Analyse von mach-o-Dateien;

    • xxd — gestattet es, die Umwandlung eines binären files in 16-er Darstellung und umgekehrt durchzuführen;
    • IDAPro — Disassembler.

    Mit zunehmender Popularität von Mac OS X auf Intel gaben viele Software-Hersteller Programmversionen für diese Plattformen heraus. In der neuen Version 5.1 unterstützt beispielsweise auch IDA Pro Mac OS X.

    Nutzern, die von Windows “übergelaufen” sind, erleichtert es das Leben wesentlich; darüber hinaus gestattet es die Nutzung von IDAPro manchmal, einige Aufgaben schneller und leichter auszuführen, als mithilfe der Standardmittel von Mac OS X.

    Beispiele der Analyse von Schadprogrammen

    Als Beispiel versuchen wir IM-Worm.OSX.Leap und Virus.OSX.Macarena zu analysieren, indem wir teilweise einige der aufgeführten Werkzeuge anwenden. Es muss angemerkt werden, dass die nachfolgend untersuchten Schadprogramme Proof-of-Concept-Entwicklungen sind, die weder einen destruktiven Effekt erzielen, noch eine ernsthafte Gefahr für die Nutzer darstellen. Ihre Hauptbedeutung ist die Demonstration der Möglichkeit, Programme ähnlicher Art zu schaffen.

    Analyse von IM-Worm.OSX.Leap

    Leap kann sich nicht über das Internet verbreiten – dazu nutzt er iChat. Während der ersten Phase verbreitet sich Leap durch die Anwendung iChat als Link auf eine Datei in der Ressource RapidShare. Dabei suggeriert er, dass es sich hier um screenshots der neuen Version Mac OS X Leopard handeln würde. Der Nutzer muss auf den Link klicken, den Download der Datei bestätigen, diese entpacken und anschließend öffnen. Danach verschickt der infizierte Computer des Nutzers die Datei (ohne irgendeine Modifizierung) über Bonjour an die gesamte Kontaktliste.

    Leap verbreitet sich als Datei mit Namen latestpics.tgz und beim Auspacken in finder erscheint er wie ein jpeg-file.

    Da Leap spotlight nutzt, arbeitet er nur in Tiger (Version von Mac OS X 10.4.x). Für den Start braucht Leap InputManager, InputManager funktioniert jedoch nicht im System für x86. Darüber hinaus enthält eine binäre Datei den Code nur für PowerPC. Folglich arbeitet Leap nur in den Computern mit PowerPC-Architektur.

    Zu Beginn der Analyse klären wir das Format der Datei latestpics. Wir starten das Werkzeug file mit dem Argument latestpics #file latestpics. Die erhaltenen Ergebnisse zeugen davon, dass wir es hier mit einer Datei in mach-o-Format zu tun haben.

    Weiterhin betrachten wir mithilfe von otool den Kopf der binären Datei: #otool -h latespics.

    Danach kann man den Einsprungpunkt von Leap analysieren. Der Einsprungpunkt in mach-o wird mithilfe des Kommandos #:otool -l latestpics definiert, das die Lade-Kommandos aufzeigt. Im vorliegenden Fall interessiert uns das Kommando LC_UNIXTHREAD, in dem der Inhalt der Register des Prozessors beim Start widergespiegelt wird. Auf PowerPC wird uns der Inhalt des Registers srr0 interessieren– das ist auch der Einsprungpunkt.

    Mithilfe des allen Unix-Nutzern bekannten Werkzeuges nm kann man die Liste aller Symbole in der binären Datei ansehen, darunter auch folgende Funktionen, deren Namen schon für sich sprechen und davon zeugen, dass die betreffende Datei potenziell gefährlich ist:

    • _copySelf
    • _infect
    • _infectApps

    Nun kann man den Code aufmerksamer betrachten. Dabei hilft uns erneut das Werkzeug otool -vt. Mit diesem Werkzeug kann man den Inhalt der Sektion im Segment __TEXT anschauen, in dem auch der ausführende Code der Datei latestpics liegt:

    Den Systemfunktionen werden Zeilen übertragen, aber sie sind durch die Funktion _xor verschlüsselt:

    Als Ergebnis des Dechiffrierens erhalten wir folgende Zeilen:

    /usr/bin/tar -zxf /tmp/hook -C /tmp
    /Library/InputManagers

    /bin/rm -rf /Library/InputManagers/apphook

    /bin/mv -f /tmp/apphook /Library/InputManagers
    ~/Library/InputManagers
    /bin/rm -rf ~/Library/InputManagers/apphook
    /bin/mv -f /tmp/apphook ~/Library/InputManagers
    %s/Contents/MacOS/%s /bin/cp ‚%s‘ ‚%s/..namedfork/rsrc‘
    /bin/cp -f ‚%s‘ ‚%s‘
    (kMDItemKind == ‚Application‘) (kMDItemLastUsedDate >= $time.this_month)  /usr/bin/ditto %s /tmp/latestpics
    /usr/bin/gzip -f -q /tmp/latestpics

    Analysiert man die erhaltenen Zeilen, wird verständlich, womit sich IM-Worm.OSX.Leap beschäftigt:

    • er kopiert sich selbst in /tmp als latestpics;
    • danach schafft er tgz;
    • er holt einen Input Manager namens „apphook.bundle“ heraus und kopiert ihn in /tmp;
    • wenn uid 0 ist, dann wird ein Verzeichnis /Library/InputManagers/ geschaffen, beliebige existierende apphook entfernt, ein neuer apphook aus /tmp kopiert;
    • wenn uid nicht 0 ist, dann wird ~/Library/InputManagers/ geschaffen;
    • jetzt wird beim Start einer beliebigen Anwendung von Mac OS X ein neuer apphook in seinen Adressraum geladen;
    • danach erfolgt der Versuch, beim Start einer Anwendung latestpics.tgz über iChat zu versenden.

    Analyse von Virus.OSX.Macarena

    Die Analyse der Datei beginnen wir mit der Klärung ihres Formats. Dazu nutzen wir wie zuvor das Werkzeug file.

    Das Ergebnis von file sagt uns, dass die Datei mach-o-Format hat.

    Danach kann man mithilfe von otool den Kopf der Datei betrachten und den Einsprungpunkt bestimmen:

    Beim genauen Betrachten weckt der seltsame Einsprungpunkt über die Null-Adresse Aufmerksamkeit. Als nächstes muss die Analyse des Codes erfolgen, beginnend mit dem Einsprungpunkt. Doch hier entsteht ein Problem. Diesen Teil der mach-o-Datei mithilfe von otool zu disassemblieren, ist nicht möglich, weil otool es nur gestattet, den Code in der Sektion text des Segments __TEXT zu analysieren.

    In dieser Situation kann IDAPro helfen. Doch dazu muss die Datei als binary in IDA geladen werden. Danach kann man die Datei disassemblieren:

    Macarena ist der erste Virus, der wirklich Dateien mit mach-o-Format im aktuellen Verzeichnis infiziert.

    Bei der Analyse der infizierten Datei kann man folgendes feststellen.

    Der Virus verändert den Einsprungpunkt an der Null-Adresse. An die Null-Adresse in mach-o wird das Segment __PAGEZERO geladen. Wie bereits vorher bei der Betrachtung der mach-o-Struktur festgestellt wurde, hat __PAGEZERO keinen Plattenplatz in der Datei. Deshalb schreibt sich der Code selbst an das Ende der Datei. Eine solche Technik hat einen unerwarteten Effekt: solche Anwendungen wie gdb, IDA oder otool weisen keinen Viruscode auf.

    Macarena ist ein ziemlich einfacher Virus. Wird er ausgeführt, durchforstet er die Dateien im aktuellen Ordner und infiziert Dateien mit mach-o-Format mit x86-Architektur. Es existieren neuere Virusversionen, die auch ppc-Dateien infizieren, ansonsten sind sie analog den Vorgängerversionen.

    Der Virus erzielt keinerlei anderen Effekt.

    Schlussbemerkung

    Mac OS X gewinnt mit jedem Tag mehr an Popularität. Obwohl gegenwärtig nur Proof-of-Concept-Programme für dieses Betriebssystem existieren, wird mit zunehmender Anzahl von Mac OS X-Nutzern auch das Interesse der Übeltäter daran wachsen. Damit verbunden entsteht immer öfter die Notwendigkeit einer Analyse von Programmen für Mac OS X.

    Glücklicherweise gehört eine große Zahl nützlicher Instrumentarien zum Bestand von Mac OS X, sowohl für die Analyse einzelner Programme, als auch zur Diagnose des Systems im Ganzen. Außerdem erscheinen Programme anderer Hersteller, die den Spezialisten ebenso helfen wie denen, die es einfach lieben, sich mit der Untersuchung von Programmen zu beschäftigen.

    Ähnliche Beiträge

    Schreibe einen Kommentar

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