Brechen Sie alle Ebenen der macOS-Sicherheit mit einer einzigen Schwachstelle

12. August 2022

Wenn Sie eine neue macOS-App mit Xcode 13.2 erstellt haben, ist Ihnen möglicherweise diese neue Methode in der Vorlage aufgefallen:

- (BOOL)applicationSupportsSecureRestorableState:(NSApplication *)app { geben Sie JA zurück; }

Dies wurde der Xcode-Vorlage hinzugefügt, um eine von uns gemeldete Prozessinjektions-Schwachstelle zu beheben!

In macOS 12.0.1 Monterey hat Apple CVE-2021-30873 behoben. Hierbei handelte es sich um eine Process Injection-Schwachstelle, die (im Wesentlichen) alle macOS AppKit-basierten Anwendungen betraf. Wir haben diese Schwachstelle an Apple gemeldet, zusammen mit Methoden, um diese Schwachstelle zu nutzen, um die Sandbox zu umgehen, Berechtigungen auf Root zu erhöhen und die Dateisystembeschränkungen von SIP zu umgehen. In diesem Artikel beschreiben wir zuerst, was Process Injection ist, dann die Details dieser Schwachstelle und schließlich, wie wir sie missbraucht haben.

Process Injection ist die Fähigkeit eines Prozesses, Code in einem anderen Prozess auszuführen. Unter Windows wird dies unter anderem verwendet, um der Erkennung durch Antivirenscanner zu entgehen, beispielsweise durch eine Technik, die als DLL-Hijacking bekannt ist. Dadurch kann bösartiger Code vorgeben, Teil einer anderen ausführbaren Datei zu sein. Unter macOS kann diese Technik aufgrund der unterschiedlichen Berechtigungen, die zwei Apps haben können, viel mehr Auswirkungen haben.

Im klassischen Unix-Sicherheitsmodell läuft jeder Prozess als ein bestimmter Benutzer. Jede Datei hat einen Besitzer, eine Gruppe und Flags, die bestimmen, welche Benutzer diese Datei lesen, schreiben oder ausführen dürfen. Zwei Prozesse, die unter demselben Benutzer ausgeführt werden, haben dieselben Berechtigungen: Es wird angenommen, dass zwischen ihnen keine Sicherheitsgrenze besteht. Benutzer sind Sicherheitsgrenzen, Prozesse nicht. Wenn zwei Prozesse unter demselben Benutzer ausgeführt werden, kann sich ein Prozess als Debugger mit dem anderen verbinden und ihm ermöglichen, den Speicher und die Register des anderen Prozesses zu lesen oder zu schreiben. Eine Ausnahme bildet der Root-Benutzer, da er Zugriff auf alle Dateien und Prozesse hat. Somit kann root immer auf alle Daten auf dem Computer zugreifen, egal ob auf der Festplatte oder im RAM.

Bis zur Einführung von SIP, auch bekannt als „rootless“, war es im Wesentlichen dasselbe Sicherheitsmodell wie macOS. Dieser Name bedeutet nicht, dass es keinen Root-Benutzer mehr gibt, aber er ist jetzt alleine weniger mächtig. Beispielsweise können einige Dateien vom Root-Benutzer nicht mehr gelesen werden, es sei denn, der Prozess hat auch bestimmte Rechte. Rechte sind Metadaten, die beim Generieren der Codesignatur für eine ausführbare Datei enthalten sind. Die Überprüfung, ob ein Prozess ein bestimmtes Recht hat, ist ein wesentlicher Bestandteil vieler Sicherheitsmaßnahmen in macOS. Unix-Eigentumsregeln sind immer noch vorhanden, es ist eine zusätzliche Ebene der Berechtigungsprüfung darüber. Einige sensible Dateien (z. B. Mail.app-Datenbank) und einige Funktionen (z. B. Webcam) sind nicht mehr nur mit Root-Rechten möglich, sondern erfordern zusätzliche Rechte. Mit anderen Worten, die Rechteerweiterung reicht nicht aus, um vertrauliche Daten auf einem Mac vollständig zu kompromittieren.

Zum Beispiel können wir mit dem folgenden Befehl die Berechtigungen von Mail.app sehen:

$ codesign -dvvv --entitlements - /System/Applications/Mail.app

In der Ausgabe sehen wir rechts folgendes:

... [Schlüssel] com.apple.rootless.storage.Mail [Bewerten] [Bool] wahr ...

Dadurch erhält Mail.app die Berechtigung, die SIP-geschützte Maildatenbank zu lesen, während andere Malware sie nicht lesen kann.

Zusätzlich zu Rechten gibt es auch Berechtigungen, die von Trust, Transparency and Control (TCC) verwaltet werden. Dies ist der Mechanismus, mit dem Anwendungen beispielsweise Zugriff auf die Webcam, das Mikrofon und (in neueren Versionen von macOS) auch auf Dateien wie die in den Ordnern „Dokumente“ und „Downloads“ anfordern können. Das bedeutet, dass selbst Apps, die die Mac-App-Sandbox nicht verwenden, möglicherweise keinen Zugriff auf bestimmte Funktionen oder Dateien haben.

Natürlich wären TCC-Rechte und -Berechtigungen nutzlos, wenn irgendein Prozess sich einfach als Debugger an einen anderen Prozess desselben Benutzers anhängen könnte. Wenn eine Anwendung Zugriff auf die Webcam hat, die andere jedoch nicht, kann sich ein Prozess als Debugger mit dem anderen Prozess verbinden und Code einschleusen, um das Webcam-Video zu stehlen. Um dieses Problem zu beheben, wurde die Möglichkeit, andere Anwendungen zu debuggen, stark eingeschränkt.

Ein jahrzehntelang genutztes Sicherheitsmodell durch ein restriktiveres zu ersetzen, ist schwierig, insbesondere bei etwas so Kompliziertem wie macOS. Das Anfügen von Debuggern ist nur ein Beispiel, es gibt viele ähnliche Techniken, die verwendet werden könnten, um Code in einen anderen Prozess einzufügen. Apple hat viele dieser Techniken vernichtet, aber viele weitere sind wahrscheinlich noch unbekannt.

Neben Apples eigenem Code können diese Schwachstellen auch in Software von Drittanbietern auftreten. Es ist ziemlich üblich, eine Schwachstelle durch Prozessinjektion in einer bestimmten Anwendung zu finden, was bedeutet, dass die Berechtigungen (TCC-Berechtigungen und -Rechte) dieser Anwendung zum Greifen nah sind ...