macOS SIP
Grundinformationen
System Integrity Protection (SIP) in macOS ist ein Mechanismus, der verhindern soll, dass selbst die privilegiertesten Benutzer unbefugte Änderungen an wichtigen Systemordnern vornehmen. Diese Funktion spielt eine entscheidende Rolle bei der Aufrechterhaltung der Integrität des Systems, indem sie Aktionen wie das Hinzufügen, Ändern oder Löschen von Dateien in geschützten Bereichen einschränkt. Die wichtigsten Ordner, die durch SIP geschützt sind, umfassen:
/System
/bin
/sbin
/usr
Die Regeln, die das Verhalten von SIP steuern, sind in der Konfigurationsdatei unter /System/Library/Sandbox/rootless.conf
definiert. Innerhalb dieser Datei werden Pfade, die mit einem Sternchen (*) vorangestellt sind, als Ausnahmen von den ansonsten strengen SIP-Beschränkungen bezeichnet.
Betrachten Sie das folgende Beispiel:
Dieser Abschnitt impliziert, dass SIP im Allgemeinen das /usr
Verzeichnis sichert, es jedoch spezifische Unterverzeichnisse (/usr/libexec/cups
, /usr/local
und /usr/share/man
) gibt, in denen Änderungen zulässig sind, wie durch den Stern (*) vor ihren Pfaden angezeigt.
Um zu überprüfen, ob ein Verzeichnis oder eine Datei durch SIP geschützt ist, können Sie den Befehl ls -lOd
verwenden, um das Vorhandensein des restricted
oder sunlnk
Flags zu überprüfen. Zum Beispiel:
In diesem Fall bedeutet das sunlnk
-Flag, dass das Verzeichnis /usr/libexec/cups
selbst nicht gelöscht werden kann, obwohl Dateien darin erstellt, geändert oder gelöscht werden können.
Andererseits:
Hier zeigt das restricted
Flag an, dass das Verzeichnis /usr/libexec
durch SIP geschützt ist. In einem SIP-geschützten Verzeichnis können keine Dateien erstellt, geändert oder gelöscht werden.
Darüber hinaus wird eine Datei, die das Attribut com.apple.rootless
als erweitertes Attribut enthält, ebenfalls durch SIP geschützt.
SIP beschränkt auch andere Root-Aktionen wie:
Laden von nicht vertrauenswürdigen Kernel-Erweiterungen
Abrufen von Task-Ports für von Apple signierte Prozesse
Ändern von NVRAM-Variablen
Erlauben von Kernel-Debugging
Optionen werden in der NVRAM-Variablen als Bitflag gespeichert (csr-active-config
auf Intel und lp-sip0
wird aus dem gebooteten Device Tree für ARM gelesen). Sie können die Flags im XNU-Quellcode in csr.sh
finden:
SIP-Status
Sie können überprüfen, ob SIP auf Ihrem System aktiviert ist, mit dem folgenden Befehl:
Wenn Sie SIP deaktivieren müssen, müssen Sie Ihren Computer im Wiederherstellungsmodus neu starten (indem Sie während des Startvorgangs Command+R drücken), und dann den folgenden Befehl ausführen:
Wenn Sie SIP aktiviert lassen, aber die Debugging-Schutzmaßnahmen entfernen möchten, können Sie dies tun mit:
Andere Einschränkungen
Verhindert das Laden von nicht signierten Kernel-Erweiterungen (kexts), wodurch sichergestellt wird, dass nur verifizierte Erweiterungen mit dem Systemkernel interagieren.
Verhindert das Debugging von macOS-Systemprozessen und schützt so die Kernkomponenten des Systems vor unbefugtem Zugriff und Modifikation.
Hemmung von Tools wie dtrace, um Systemprozesse zu inspizieren, was die Integrität des Systembetriebs weiter schützt.
Erfahren Sie mehr über SIP-Informationen in diesem Vortrag.
SIP-Umgehungen
Die Umgehung von SIP ermöglicht es einem Angreifer:
Zugriff auf Benutzerdaten: Sensible Benutzerdaten wie E-Mails, Nachrichten und Safari-Verlauf aus allen Benutzerkonten zu lesen.
TCC-Umgehung: Direkte Manipulation der TCC (Transparenz, Zustimmung und Kontrolle)-Datenbank, um unbefugten Zugriff auf die Webcam, das Mikrofon und andere Ressourcen zu gewähren.
Persistenz herstellen: Malware an SIP-geschützten Orten platzieren, wodurch sie resistent gegen Entfernung wird, selbst durch Root-Rechte. Dies schließt auch die Möglichkeit ein, das Malware Removal Tool (MRT) zu manipulieren.
Kernel-Erweiterungen laden: Obwohl es zusätzliche Schutzmaßnahmen gibt, vereinfacht die Umgehung von SIP den Prozess des Ladens von nicht signierten Kernel-Erweiterungen.
Installationspakete
Installationspakete, die mit Apples Zertifikat signiert sind, können die Schutzmaßnahmen umgehen. Das bedeutet, dass selbst Pakete, die von Standardentwicklern signiert sind, blockiert werden, wenn sie versuchen, SIP-geschützte Verzeichnisse zu ändern.
Nicht vorhandene SIP-Datei
Ein potenzieller Schlupfloch besteht darin, dass, wenn eine Datei in rootless.conf
angegeben, aber derzeit nicht vorhanden ist, sie erstellt werden kann. Malware könnte dies ausnutzen, um Persistenz im System herzustellen. Zum Beispiel könnte ein bösartiges Programm eine .plist-Datei in /System/Library/LaunchDaemons
erstellen, wenn sie in rootless.conf
aufgeführt, aber nicht vorhanden ist.
com.apple.rootless.install.heritable
Die Berechtigung com.apple.rootless.install.heritable
ermöglicht es, SIP zu umgehen.
Es wurde entdeckt, dass es möglich war, das Installationspaket nach der Überprüfung der Codesignatur durch das System zu tauschen, sodass das System das bösartige Paket anstelle des Originals installieren würde. Da diese Aktionen von system_installd
durchgeführt wurden, würde dies die Umgehung von SIP ermöglichen.
Wenn ein Paket von einem gemounteten Image oder externen Laufwerk installiert wurde, würde der Installer die Binärdatei von diesem Dateisystem ausführen (anstatt von einem SIP-geschützten Ort), wodurch system_installd
eine beliebige Binärdatei ausführen könnte.
CVE-2021-30892 - Shrootless
Forscher aus diesem Blogbeitrag entdeckten eine Schwachstelle im Systemintegritätsschutz (SIP)-Mechanismus von macOS, die als 'Shrootless'-Schwachstelle bezeichnet wird. Diese Schwachstelle konzentriert sich auf den system_installd
-Daemon, der eine Berechtigung, com.apple.rootless.install.heritable
, hat, die es einem seiner Kindprozesse ermöglicht, die Dateisystembeschränkungen von SIP zu umgehen.
Der system_installd
-Daemon installiert Pakete, die von Apple signiert wurden.
Forscher fanden heraus, dass während der Installation eines von Apple signierten Pakets (.pkg-Datei) system_installd
alle Post-Installations-Skripte ausführt, die im Paket enthalten sind. Diese Skripte werden von der Standard-Shell, zsh
, ausgeführt, die automatisch Befehle aus der Datei /etc/zshenv
ausführt, wenn sie existiert, selbst im nicht-interaktiven Modus. Dieses Verhalten könnte von Angreifern ausgenutzt werden: indem sie eine bösartige /etc/zshenv
-Datei erstellen und auf system_installd
warten, um zsh
aufzurufen, könnten sie beliebige Operationen auf dem Gerät durchführen.
Darüber hinaus wurde entdeckt, dass /etc/zshenv
als allgemeine Angriffstechnik verwendet werden könnte, nicht nur für eine SIP-Umgehung. Jedes Benutzerprofil hat eine ~/.zshenv
-Datei, die sich genauso verhält wie /etc/zshenv
, aber keine Root-Rechte benötigt. Diese Datei könnte als Persistenzmechanismus verwendet werden, der jedes Mal ausgelöst wird, wenn zsh
gestartet wird, oder als Mechanismus zur Erhöhung der Berechtigungen. Wenn ein Admin-Benutzer mit sudo -s
oder sudo <Befehl>
zu Root aufsteigt, würde die ~/.zshenv
-Datei ausgelöst, was effektiv zu Root-Rechten führt.
In CVE-2022-22583 wurde entdeckt, dass der gleiche system_installd
-Prozess weiterhin missbraucht werden konnte, da er das Post-Installationsskript in einen zufällig benannten Ordner, der durch SIP in /tmp
geschützt ist, legte. Das Problem ist, dass /tmp
selbst nicht durch SIP geschützt ist, sodass es möglich war, ein virtuelles Image darauf zu mounten, dann würde der Installer das Post-Installationsskript dort ablegen, das virtuelle Image aushängen, alle Ordner neu erstellen und das Post-Installationsskript mit der Payload hinzufügen, um es auszuführen.
Eine Schwachstelle wurde identifiziert, bei der fsck_cs
in die Irre geführt wurde, um eine entscheidende Datei zu beschädigen, aufgrund seiner Fähigkeit, symbolische Links zu folgen. Angreifer erstellten speziell einen Link von /dev/diskX
zur Datei /System/Library/Extensions/AppleKextExcludeList.kext/Contents/Info.plist
. Das Ausführen von fsck_cs
auf /dev/diskX
führte zur Beschädigung von Info.plist
. Die Integrität dieser Datei ist entscheidend für den SIP (System Integrity Protection) des Betriebssystems, der das Laden von Kernel-Erweiterungen steuert. Sobald sie beschädigt ist, ist die Fähigkeit von SIP, Kernel-Ausschlüsse zu verwalten, beeinträchtigt.
Die Befehle zur Ausnutzung dieser Schwachstelle sind:
Die Ausnutzung dieser Schwachstelle hat schwerwiegende Folgen. Die Info.plist
-Datei, die normalerweise für die Verwaltung der Berechtigungen für Kernel-Erweiterungen verantwortlich ist, wird unwirksam. Dazu gehört die Unfähigkeit, bestimmte Erweiterungen wie AppleHWAccess.kext
auf die schwarze Liste zu setzen. Folglich kann diese Erweiterung, da der Kontrollmechanismus von SIP außer Betrieb ist, geladen werden, was unbefugten Lese- und Schreibzugriff auf den RAM des Systems gewährt.
Es war möglich, ein neues Dateisystem über SIP geschützte Ordner zu mounten, um den Schutz zu umgehen.
Das System ist so eingestellt, dass es von einem eingebetteten Installationsdisk-Image innerhalb von Install macOS Sierra.app
bootet, um das Betriebssystem zu aktualisieren, wobei das bless
-Dienstprogramm verwendet wird. Der verwendete Befehl lautet wie folgt:
Die Sicherheit dieses Prozesses kann gefährdet werden, wenn ein Angreifer das Upgrade-Image (InstallESD.dmg
) vor dem Booten verändert. Die Strategie besteht darin, einen dynamischen Loader (dyld) durch eine bösartige Version (libBaseIA.dylib
) zu ersetzen. Dieser Austausch führt dazu, dass der Code des Angreifers ausgeführt wird, wenn der Installer gestartet wird.
Der Code des Angreifers erlangt während des Upgrade-Prozesses die Kontrolle und nutzt das Vertrauen des Systems in den Installer aus. Der Angriff erfolgt durch die Veränderung des InstallESD.dmg
-Images mittels Method Swizzling, wobei insbesondere die Methode extractBootBits
ins Visier genommen wird. Dies ermöglicht die Einspeisung von bösartigem Code, bevor das Disk-Image verwendet wird.
Darüber hinaus gibt es im InstallESD.dmg
ein BaseSystem.dmg
, das als Wurzel-Dateisystem des Upgrade-Codes dient. Das Einspeisen einer dynamischen Bibliothek in dieses ermöglicht es dem bösartigen Code, innerhalb eines Prozesses zu arbeiten, der in der Lage ist, OS-Level-Dateien zu ändern, was das Potenzial für eine Systemkompromittierung erheblich erhöht.
In diesem Vortrag von DEF CON 31 wird gezeigt, wie systemmigrationd
(das SIP umgehen kann) ein bash- und ein perl-Skript ausführt, das über Umgebungsvariablen BASH_ENV
und PERL5OPT
missbraucht werden kann.
CVE-2023-42860
Wie in diesem Blogbeitrag detailliert beschrieben, erlaubten postinstall
-Skripte aus InstallAssistant.pkg
-Paketen die Ausführung:
und es war möglich, einen Symlink in ${SHARED_SUPPORT_PATH}/SharedSupport.dmg
zu erstellen, der es einem Benutzer ermöglichen würde, jede Datei zu entsperren und SIP-Schutz zu umgehen.
com.apple.rootless.install
Die Berechtigung com.apple.rootless.install
ermöglicht es, SIP zu umgehen
Die Berechtigung com.apple.rootless.install
ist bekannt dafür, den System Integrity Protection (SIP) auf macOS zu umgehen. Dies wurde insbesondere im Zusammenhang mit CVE-2022-26712 erwähnt.
In diesem speziellen Fall besitzt der System-XPC-Dienst, der sich unter /System/Library/PrivateFrameworks/ShoveService.framework/Versions/A/XPCServices/SystemShoveService.xpc
befindet, diese Berechtigung. Dies ermöglicht dem zugehörigen Prozess, SIP-Beschränkungen zu umgehen. Darüber hinaus bietet dieser Dienst bemerkenswerterweise eine Methode, die das Verschieben von Dateien ohne Durchsetzung von Sicherheitsmaßnahmen erlaubt.
Versiegelte System-Snapshots
Versiegelte System-Snapshots sind ein von Apple in macOS Big Sur (macOS 11) eingeführtes Feature, das Teil des System Integrity Protection (SIP)-Mechanismus ist, um eine zusätzliche Sicherheitsebene und Systemstabilität zu bieten. Sie sind im Wesentlichen schreibgeschützte Versionen des Systemvolumens.
Hier ist ein detaillierterer Blick:
Unveränderliches System: Versiegelte System-Snapshots machen das macOS-Systemvolumen "unveränderlich", was bedeutet, dass es nicht modifiziert werden kann. Dies verhindert unbefugte oder versehentliche Änderungen am System, die die Sicherheit oder Systemstabilität gefährden könnten.
Systemsoftware-Updates: Wenn Sie macOS-Updates oder -Upgrades installieren, erstellt macOS einen neuen System-Snapshot. Das macOS-Startvolumen verwendet dann APFS (Apple File System), um zu diesem neuen Snapshot zu wechseln. Der gesamte Prozess der Anwendung von Updates wird sicherer und zuverlässiger, da das System immer zum vorherigen Snapshot zurückkehren kann, wenn während des Updates etwas schiefgeht.
Daten-Trennung: In Verbindung mit dem Konzept der Trennung von Daten- und Systemvolumen, das in macOS Catalina eingeführt wurde, stellt die Funktion der versiegelten System-Snapshots sicher, dass alle Ihre Daten und Einstellungen auf einem separaten "Daten"-Volumen gespeichert werden. Diese Trennung macht Ihre Daten unabhängig vom System, was den Prozess der Systemupdates vereinfacht und die Systemsicherheit erhöht.
Denken Sie daran, dass diese Snapshots automatisch von macOS verwaltet werden und dank der Speicherfreigabefunktionen von APFS keinen zusätzlichen Speicherplatz auf Ihrer Festplatte beanspruchen. Es ist auch wichtig zu beachten, dass diese Snapshots sich von Time Machine-Snapshots unterscheiden, die benutzerzugängliche Backups des gesamten Systems sind.
Snapshots überprüfen
Der Befehl diskutil apfs list
listet die Details der APFS-Volumes und deren Layout auf:
Im vorherigen Output ist zu sehen, dass benutzerzugängliche Orte unter /System/Volumes/Data
gemountet sind.
Darüber hinaus ist der macOS-Systemvolumensnapshot unter /
gemountet und ist versiegelt (kryptografisch vom OS signiert). Wenn SIP umgangen und geändert wird, wird das OS nicht mehr booten.
Es ist auch möglich, zu überprüfen, ob das Siegel aktiviert ist, indem Sie Folgendes ausführen:
Darüber hinaus wird die Snapshot-Disk ebenfalls als schreibgeschützt gemountet:
Last updated