Gatekeeper Bypass – unter Umständen

Kurzfassung: Wenn man aus unsicheren Quellen Software herunterlädt, dann kann eine korrekt signierte saubere App trotzdem Malware beinhalten, die Gatekeeper nicht bemerkt, weil sie als innere optionale Library der App daherkommt. Bislang ist jedoch keine Malware bekannt, die diesen Weg geht.

Patrick Wardle hatte sich 2015 Mac Malware angesehen und kam zu dem Schluß, daß das alles Amateur-Software ist. Die meiste benötigt User-Interaktion und ist leicht zu entdecken und unternimmt auch nicht viel zu ihrer Verteidigung. Darum hat er überlegt, wie man bessere Malware für OX X erstellen könnte. Dies sind die zugehörigen Folien Writing Bad @$$ Malware for OS X.

Ein Ansatzpunkt ist die Übertragung der Software. Wenn man Apps nicht aus dem App Store bezieht, dann erfolgt der Transfer in der Regel über unverschlüsseltes HTTP. Sogar sämtliche Antivirus-Sicherheitsfirmen, die für gewöhnlich auf dicke Hose machen, verteilen ihre Produkte nur über HTTP. Ein Angreifer kann sich dazwischenhängen, Man in the Middle sein, und die Sendung manipulieren. Da speziell AV-Software Roote-Rechte bei der Installation haben möchte, ist der Rechner anschließend erledigt.

Im Gegensatz zu iOS, das keine unsignierten Binaries laufen läßt, erlaubt OS X den Start von Binaries ohne Signatur. Ist ein Programm jedoch signiert, dann prüft OS X dessen Unversehrtheit. Wurde das signierte Programm verändert, dann läßt der Loader die Ausführung nicht zu und crasht es. Zur Infektion eines Binaries sollte also erstmal die Signatur entfernt werden. Da OS X in der aktuellen Grundeinstellung jedoch nur Apps aus dem App Store und von registrierten Entwicklern startet, kommt dieser Infektionsweg nicht so recht zum Tragen. Man müßte erst die Einstellung ändern oder Hinwweise ignorieren und dergleichen.

Es gibt diverse Applikationen, auch von Apple, die beim Start nach bestimmten optionalen dynamischen Libraries im Verzeichnis innerhalb der App selbst suchen lassen (jede .app ist ein Verzeichnis). Wenn sie dort nichts finden, dann suchen sie ggf. noch in Systemverzeichnissen. Ein Angreifer könnte die App also mit einer eigenen Dylib im App-Verzeichnis versorgen. Allerdings muß der Angreifer in der Regel Root-Rechte haben, um diese Apps zu verändern. Dieselbe Idee und Beschränkung gilt für Plugins. Aus Angreifer-Sicht ist die automatische Ausführung, zum Beispiel als Spotlight-Plugin, attraktiv sowie die dadurch ermöglichte unauffällige Nutzung vorhandener Prozesse.

Bessere Malware könnte verschlüsselte Binaries verwenden, die mit demselben Key verschlüsselt sind wie Apples Finder. Das würde selbst gut bekannte Malware vor 50% aller AV-Software schützen.

Was er über Process-Injection erzählt unterliegt starken Grenzen. Vergleiche Einordnung von mach_override und mach_inject. Warum ein Angreifer davon nichts hat.

Die Infektion von Xcode, um damit erstellte Programme zu kompromittieren, hatten wir inzwischen schon in der Praxis: iOS/OS X: XcodeGhost fischt iCloud-Logins ab?.

Gatekeeper Grenzen

Patrick hat in dem Vortrag auch mögliche Gatekeeper Umgehungen behandelt und noch einen weiteren Vortrag gehalten, der sich speziell mit Gatekeeper Bypass befaßt. Letztendlich basiert das jedoch auf Dylib hijacking on OS X und Gatekeeper Bypass ist nur eine Folge davon.

Patrick sagt, Gatekeeper macht einen guten Job. Es verhindert Man-in-the-Middle Attacks, weil nur signierte Apps und Apps aus dem App Store per Default laufen dürfen. Gatekeeper setzt allerdings auf der Quarantäne-Funktion auf und ist darum bei Apps, die man zum Beispiel per USB-Stick auf den Rechner lädt oder über Sicherheitslücken wie Flashback, nicht wirksam.

Gatekeeper wird außerdem von den LaunchServices ausgelöst, also wenn ein User ein Programm doppelklickt zum Starten oder es von einem anderen Programm per LaunchServices aufgerufen wird. Wenn man das Binary innerhalb der App direkt per Terminal startet, geht das an den LaunchServices und damit an Gatekeeper vorbei. Aber auch da ist für den normalen User untypisches Verhalten.

Gatekeeper weitere Grenzen

Den Hinweis, den Patrick bringt, ist, daß Gatekeeper nur die App untersucht, die gestartet wird, aber keinen externen Code, den die App eventuell noch aufruft. Damit kann man Code an Gatekeeper vorbeischleusen, indem man einer legitimen App, die versucht, eine optionale externe Dylib mit dem Loader Command LC_LOAD_WEAK_DYLIB zu laden, eine passende Library, vom Angreifer erstellt, unterschiebt.

Dazu packt man eine App, die eine schwache Referenz auf eine externe lokale Library verwendet, zusammen mit einer passenden Library in ein Zip-File oder ein Diskimage oder hijacked eine unverschlüsselte HTTP-Verbindung, um einen App-Download ebenso zu manipulieren. Schwache Referenz bedeutet, daß die App nicht darauf angewiesen ist, um zu laufen. Also optional. Einschränkung für diesen Angriff ist, daß natürlich nur manche Apps so etwas tun, aber im Grunde genügt ja eine.

Eine weitere Variante geht über den Loader Comand LC_RPATH, der für "Runpath Search Paths" erzeugt wird. Mit Runpath Search Paths kann eine Anwendung angeben, in welchen Verzeichnissen nach den benötigten Dylibs gesucht werden soll. Alle Libs, deren Pfad die App mit einem @rpath Prefix angibt, werden in den ebenfalls von der App definierten Runpath Search Paths gesucht, indem jeweils das @rpath durch einen der Runpath Search Paths ersetzt wird.

In diesem Fall müßte man eine App finden, die solche Suchpfade definiert und im konkreten Fall eine gesuchte Dylib erst im zweiten oder noch späteren angegeben Runpath Search Paths vorfindet. Der Angreifer könnte dann eine eigene Dylib im Verzeichnis, das dem ersten Runpath Search Path entspricht, ablegen und somit Code in die App schleusen.

So könnte man beispielsweise Instruments, das Teil von Xcode ist, so mißbrauchen. Es gibt jedoch noch diverse andere verwundbare Programme. Instruments lädt Dylibs, die es relativ zu seiner Position sucht innerhalb von Xcode.app, was ja ein Verzeichnis ist. Instruments geht vier Verzeichnisse hoch und dann in ein Verzeichnis, das SharedFrameworks heißt. Was Instruments dort findet, lädt es.

otool -l /Applications/Xcode.app/Contents/Applications/Instruments.app/Contents/MacOS/Instruments | grep -B3 SharedFrameworks
Load command 33
          cmd LC_RPATH
      cmdsize 64
         path @executable_path/../../../../SharedFrameworks (offset 12)

Bietet man nun Instruments als Download an und bettet es in entsprechend strukturierte Verzeichnisse per Zip oder Diskimage ein, dann wird Instruments die bösen Dylibs relativ zu seiner Position laden. Und da Instruments signierter Apple-Code ist, meckert Gatekeeper auch nicht.

spctl -vat execute /Applications/Xcode.app/Contents/Applications/Instruments.app
/Applications/Xcode.app/Contents/Applications/Instruments.app: accepted
source=Apple System

Man könnte ein so in ein Diskimage verpacktes verwundbares Programm auch tarnen, zum Beispiel als Flash-Installer. Darin bestimmte Verzeichnisse unsichtbar machen, Icons ändern, Hintergrund anpassen et cetera.

Gatekeeper sieht das korrekt signierte Instruments.app und erlaubt den Start. Instruments lädt aber dann noch eine bösartige lokale Library.

Eine Manipulation von vorhandenem Xcode und Instruments, die vom App Store installiert wurden, direkt auf der Platte, würde Root-Rechte erfordern. Zielgruppe für diese Art von Gatekeeper-Umgehung sind also nur User, die ihre Apps aus unsicheren Quellen beziehen.

Falls ein Angreifer schon Root-Rechte hat, kann er seine Malware so installieren, daß verwundbare Apps geändert werden zur Laufzeit ohne die Apps selbst zu manipulieren.

Statische und dynamische Variante

Den Bypass, wie er bei Instruments ausgenutzt werden konnte, hat Apple 2015 noch beseitigt:

Es gibt jedoch eine weitere Variante, die noch nicht unschädlich gemacht worden ist. Die funktioniert genauso bis auf den Unterschied, daß man eine App als Angriffspunkt benutzen muß, die ein relatives externes Binary, das keine dylib ist, zur Laufzeit lädt.

Als Beispiel führt er "Adobe Photoshop CC 2015" auf. Photoshop lädt zur Laufzeit Dylib, die es neben der App in "Plug-ins" findet. Das Laden dieser möglicherweise bösartigen 3rd-Party-Plugins wird zur Zeit noch nicht von Gatekeeper untersucht. Hier kann also manipulierter unsignierter Code oder Code aus ungeprüfter Quelle geladen werden.

Ein nicht namentlich genanntes Apple Binary ist ebenso betroffen.

Diese Art Angriff abzufangen, erfordert eine Erweiterung von Gatekeeper, so daß nicht nur statisch die gestartete App geprüft wird, sondern auch, was dynamisch geladen wird. Auf jeden Fall ist es auch ein Kompatibilitätsproblem, weil nach so einer Verschärfung von Gatekeeper damit auch bestehende legitime Apps am Laufen gehindert würden, die beim Laden optionaler lokaler externer Plugins ohne gültige Signatur auf die Nase fallen würden. Apple soll laut Patrick an einer Lösung arbeiten. Zwischenzeitlich hat Apple jedoch nur die Demos dieses Problems per XProtect abgefangen, was ja das eigentliche Problem nicht löst.

Netterweise hat er auch die verfügbaren Security-Produkte getestet gegen seinen Beispiel-Angriff. Von AV-Software bis LitteSnitch in seinem Vortrag und Folien zu Writing Bad @$$ Malware for OS X. Infektion, Persistierung, Kommunikation, nichts wurde erkannt von diesen Security-Produkten.

Tools

Patrick stellt darum auf seiner Seite namens Objective-See einige Tools zur Verfügung, mit denen man seinen Rechner beobachten kann und Angriffe dieser Art entdecken können soll. Er ist selbst Mac-User.

Ich weise in diesem Zusammenhang auf meine FAQs hin, die auch die Frage beantworten: Brauche ich ein Antiviren-Programm für meinen Mac? Allerdings sind Patricks Tools keine AV-Software in diesem Sinne, sondern eher Analyse-Werkzeuge.

Bewertung

Wie ist dieses Problem zu bewerten im Vergleich mit anderen Systemen?

Auf iOS ist im Gegensatz zu OS X signierter Code zwingend: Grundsätzlich wird kein unsignierter Code ausgeführt bis auf eine Ausnahme, die mir nicht schmeckt: Codesign-Ausnahme in iOS 4.3 und 5. iOS läßt nur von Apple signierten Code laufen (per App Store) oder Code, dessen zugehöriges (Enterprise-) Zertifikat installiert wurde. Das Zertifikat stellt ebenfalls Apple aus. Außerdem läuft natürlich auch Code, der nur auf den registrierten Geräten des jeweiligen Entwicklers funktioniert. Die strenge Anforderung in iOS funktioniert, weil es sie in iOS von Anfang an für 3rd-Party-Entwickler gab. Bei OS X wurde schrittweise nachgerüstet, weil sonst ja keine alten Programme mehr laufen würden.

Bei Windows beschränkte sich die Anforderung Code-Signing bisher weitgehend auf Treiber. Mit Windows 10 Enterprise gibt es die Konfigurations-Möglichkeit namens Device Guard, die für große Firmen gedacht ist. Es erinnert etwas an Windows RT und Windows Phone, die auch signierten Code erfordern. Damit wird der normale User zuhause erstmal nicht in den Genuß dieses Features kommen bei Windows.

Android erfordert zwar auch signierten Code, aber hier werden selbstsignierte Zertifikate akzeptiert. In Android ist damit standardmäßig die Vertrauenskette (chain of trust), die signierten Code erst sinnvoll macht, nicht vorhanden. Wem selbstsignierte Zertifikate ausreichen, kann sich das Feature gleich ganz schenken, denn man kann dabei die Identität des Entwickelers nicht verläßlich prüfen. Wenn Code ausgeführt wird, bei dem egal ist, von wem er signiert wurde, dann läuft Code aus jeder Quelle.

Die Suchpfade erinnern an DLL-Hijacking von Windows. Allerdings gibt es wichtige Unterschiede: Windows kann für eine Anwendung nach DLLs suchen ohne Pfadangabe, also nur mit dem Namen. Dadurch wird auf Windows zuerst im Current Working Directory gesucht und im Verzeichnis der Anwendung. Bei OS X nur in Systemverzeichnissen und vorher optional in von der App definierten Pfaden.

---