High Sierra's 'Secure Kernel Extension Loading' is Broken
› a new 'security' feature in macOS 10.13, is trivial to bypass
Hintergrund
Mit jeder neuen Version von macOS führt Apple neue "integrierte" Sicherheitserweiterungen ein ... und macOS High Sierra (10.13) ist da keine Ausnahme.
Auf dieser Seite werfen wir einen kurzen Blick auf die umstrittene "Secure Kernel Extension Loading" (SKEL) Funktion von High Sierra. Unglücklicherweise behindert SKEL, obwohl es in guten Absichten steckt, lediglich die Bemühungen der "Guten" (d. H. Von Drittanbietern von macOS-Entwicklern wie diejenigen, die Sicherheitsprodukte entwerfen). Aufgrund von Implementierungsfehlern bleiben die "Bösewichte" (Hacker / Malware) wahrscheinlich unberührt.
Während viele angesehene Sicherheitsforscher, Systemadministratoren und macOS-Entwickler diese Sorge geäußert haben, werden wir dies hier beweisen, indem wir eine Zero - Day - Schwachstelle in der SKEL-Implementierung demonstrieren, die sie entscheidend umgeht:
$ kextstat
Index Refs Size Wired Name
1 90 0x9e30 0x9e30 com.apple.kpi.bsd
2 8 0x3960 0x3960 com.apple.kpi.dsep
...
130 0 0x4b00 0x4b000 com.un.approved.kext
In der Technical Note Technical Note TN2459 von Apple, Secure Kernel Extension Loading, heißt es "eine neue Funktion, die vor dem Laden neuer Kernel-Erweiterungen von Drittanbietern eine Benutzergenehmigung erfordert". Andere gute Übersichten von SKEL umfassen:
Während wir zunächst annehmen könnten, dass der Hauptangriffsvektor, den SKEL zu vereiteln versucht, das (direkte) Laden von bösartigen Kernel-Erweiterungen (d. H. Rootkits) ist, glauben wir, dass dies nicht der Fall ist. Beachten Sie zunächst, dass (AFAIK) noch keine signierte MacOS-Malware im Kernel-Modus zu sehen ist!
Seit OS X Yosemite müssen alle Kexte mit einem Kernel-Code-Signing-Zertifikat signiert werden. Und anders als Entwickler-IDs im Benutzermodus ist Apple unglaublich "schützend" für solche Kernel-Codesignaturzertifikate - und gibt nur eine Handvoll an legitime Drittanbieter-Unternehmen aus, die berechtigte Gründe haben, einen Kernel-Code zu erstellen.
Da Sicherheitsfunktionen häufig kostspielig zu implementieren sind, werden sie allgemein eingeführt, um weit verbreitete Probleme reaktiv anzugehen. (Es sei denn, sie werden als Kontrollmechanismus unter dem Deckmantel eines "Sicherheitsmerkmals" (* cough cough *) eingeführt).
Stattdessen besteht das Hauptziel (Sicherheitsziel) von SKEL darin, das Laden legitimer, aber (bekannter) anfälliger Schlüssel zu blockieren. Bis Apple diese Schlüssel über das OSKextExcludeList-Wörterbuch (in AppleKextExcludeList.kext / Contents / Info.plist) schwarz listet, können Angreifer solche Kexte einfach laden und dann ausnutzen, um eine beliebige Code-Ausführung im Kontext des Kernels zu erzielen. Beachten Sie, dass solche schwarzen Listen oft verzögert werden, da sie die legitime Funktionalität beschädigen können, bis der Benutzer auf eine nicht auf der Blacklist basierende Version des Schlüssels aktualisiert hat.
Vor etwa einem Jahr diskutierten wir diesen Angriffsvektor im DefCon-Talk: "Wir haben 99 Probleme, aber Little Snitch ist nicht einer!" (Hinweis: Dies ist ein bekannter Angriffsvektor, um Kernel-Code-Signing-Anforderungen sowohl unter Windows als auch unter macOS zu umgehen):
Auf unserer Seite haben wir einen nutzbaren Kernel-Heap-Overflow in LittleSnitch's Kerneltreiber LittleSnitch.kext diskutiert. Während dieser Fehler missbraucht werden kann, um Privilegien auf Macs, auf denen LittleSnitch installiert war, zu eskalieren, ging der Fehler nicht mehr verloren, nachdem die Schwachstelle gepatcht wurde. Stattdessen können lokale privilegierte Angreifer den anfälligen Treiber weiterhin verwenden, um die Kernel-Codesignaturanforderungen von macOS zu umgehen. Die Schritte für diesen Angriff sind wie folgt:
Laden Sie mit Root-Berechtigungen eine anfällige Kopie von LittleSnitch.kext (Versionen <3.61)
Dies wäre erlaubt, da der verwundbare Treiber noch gültig signiert wurde.
Nutzen Sie den Heap-Overflow, um eine beliebige Code-Ausführung innerhalb des Kernels zu erhalten.
Hier im Kernel kann man SIP umgehen, unsignierte Kexte laden und vieles mehr!
Obwohl ja, "Secure Kernel Extension Loading" auch das direkte Laden von in böser Absicht signierten Kexts blockieren kann, scheint es das Hauptziel zu sein, das Laden von bekannten anfälligen Treibern für böswillige Zwecke zu verhindern.
Sichere Kernel Extension Loading
Was passiert also, wenn ein Benutzer (oder ein Installer oder Malware) versucht, eine signierte 3rd-Party-Kernel-Erweiterung zum ersten Mal auf High Sierra zu laden? Nun, es wird von SKEL blockiert und der Benutzer wird benachrichtigt, es sei denn:
-
wurde "bereits zum Zeitpunkt des Upgrades auf macOS High Sierra installiert."
-
ist mit der gleichen Team-ID wie eine zuvor genehmigte Erweiterung signiert.
-
"ersetzt eine zuvor genehmigte Erweiterung." (Wir schätzen auf kryptographisch überprüfbaren Informationen wie der Team-ID).
-
wird auf einen Mac geladen, der mit einer MDM-Lösung registriert ist.
Zum Beispiel versuchen wir hier, die neueste Version von LittleSnitch.kext manuell auf eine makellose VM-Instanz von High Sierra zu laden. Obwohl der Kext mit einem legitimen (nicht widerrufenen) Kernelmodus-Signaturzertifikat signiert wurde und nicht auf der schwarzen Liste steht, wird SKEL ihn blockieren:
# kextload LittleSnitch.kext
LittleSnitch.kext failed to load - (libkern/kext) system policy prevents loading; check the system/kernel logs for errors or try kextutil(8).
Sobald das System das Laden des Schlüssels blockiert hat, generiert es auch eine Warnung an den Benutzer:
Wenn wir die Dateisystem-E / A während dieses Vorgangs überwachen, können wir sowohl den Kext (LittleSnitch.kext) als auch die scheinbare Kernel-Policy-Datenbank sehen, auf die der Systemrichtliniendaemon (Systemhintergrundprogramm) Syspolicyd zugreift:
# fs_usage -w -f filesystem
...
lstat64 /Users/user/Desktop/LittleSnitch.kext syspolicyd.11844
stat64 /private/var/db/SystemPolicyConfiguration/KextPolicy syspolicyd.11844
Wenn wir die 'kext policy'-Datenbank (/ private / var / db / SystemPolicyConfiguration / KextPolicy) laden, können wir sehen, dass der LittleSnitch-Kext zur' kext_policy'-Tabelle hinzugefügt wurde, aber momentan ist er nicht erlaubt (erlaubt ist auf 0 zu setzen):
# sqlite3 /private/var/db/SystemPolicyConfiguration/KextPolicy '.dump kext_policy'
CREATE TABLE kext_policy ( team_id TEXT, bundle_id TEXT, allowed BOOLEAN, developer_name TEXT, ...);
INSERT INTO kext_policy VALUES('MLZF7K7B5R','at.obdev.nke.LittleSnitch',0,'Objective Development Software GmbH',4);
Wie in der Warnung, die dem Benutzer angezeigt wurde, angegeben wurde, müssen sie, wenn sie die (signierte) Kernel-Erweiterung laden wollen, diese nun manuell genehmigen. Dazu rufen Sie die Systemvoreinstellungen-Anwendung (/ Applications / System Preferences.app) auf, navigieren zum Bereich "Security & Privacy" und klicken auf der Registerkarte "General tab" auf "Allow":
Nachdem der Benutzer das Laden des Schlüssels zugelassen hat, aktualisiert das System den Eintrag in der Datenbank 'Kext-Richtlinie' ('Zulässig' ist auf 1 gesetzt) und ermöglicht das Laden des Schlüssels:
# sqlite3 /private/var/db/SystemPolicyConfiguration/KextPolicy '.dump kext_policy'
CREATE TABLE kext_policy ( team_id TEXT, bundle_id TEXT, allowed BOOLEAN, developer_name TEXT, ...);
INSERT INTO kext_policy VALUES('MLZF7K7B5R','at.obdev.nke.LittleSnitch',1,'Objective Development Software GmbH',4);
Verwertung
Jetzt lassen Sie uns Secure Kernel Extension laden. - Warum? Nicht weil wir Apple nicht mögen, sondern um zu verdeutlichen, dass die 'bösen' Kerle / Hacker in der jetzigen Implementierung kein Problem damit haben werden, es zu umgehen. IOHO (In unserer bescheidenen Meinung), das ist wichtig für Apple zu verstehen !:
Unser Ziel hier ist es, programmgesteuert einen signierten Kext zu laden, der niemals auf dem High Sierra-System installiert oder geladen wurde. Dieser Kext könnte entweder ein bösartiger oder eher ein verwundbarer sein, der einem Angreifer einen ungehinderten Kernelzugriff über Nutzbarmachung ermöglicht. Natürlich sollten beide Angriffe von SKEL blockiert werden. ...Ach, werden sie nicht.
Es ist wichtig anzumerken, dass, obwohl es eine einfache Möglichkeit ist, SKEL zu umgehen, Apple sich zumindest ein wenig Mühe gegeben hat, offensichtliche Umgehungen zu vereiteln.
Wenn ein Angreifer zum Beispiel die Datenbank für die "Kext-Richtlinie" direkt modifizieren könnte, könnte er die Kexts einfach "vorab genehmigen". Um dies zu verhindern, schützt Apple die Datenbank mit Systemintegritätsschutz (SIP):
# ls -aOl /private/var/db/SystemPolicyConfiguration/KextPolicy
-rw-r--r-- 1 root wheel restricted /private/var/db/SystemPolicyConfiguration/KextPolicy
As this database falls under SIP, this means even if an attacker has root privileges they cannot subvert it:
Da diese Datenbank unter SIP fällt, bedeutet dies, selbst wenn ein Angreifer root-Rechte besitzt, können Sie es nicht unterdrücken.
# echo "some data" >> /private/var/db/SystemPolicyConfiguration/KextPolicy
sh: /private/var/db/SystemPolicyConfiguration/KextPolicy: Operation not permitted
Ein weiterer offensichtlicher Angriffsvektor wäre die Interaktion mit der Benutzeroberfläche, indem vielleicht programmgesteuert ein Mausklickereignis an die Schaltfläche "Zulassen" im Fenster "Systemeinstellungen" im Bereich "Sicherheit und Datenschutz" gesendet wird. Dieser Bereich (und andere empfindliche Benutzerschnittstellenkomponenten wie Sicherheitswarnungen) sollen jedoch solche (simulierte / programmatische) Interaktionen in aktuellen Versionen von macOS vereiteln. Im Folgenden sehen wir beispielsweise, wie das Betriebssystem ein Apple-Skript blockiert, das versucht, mit dem Bereich "Sicherheit und Datenschutz" zu interagieren:
# osascript ~/Desktop/iteractWithUI.scpt>br> iteractWithUI.scpt:467:472: execution error: System Events got an error: osascript is not allowed assistive access. (-1719)
Überraschenderweise (für uns), selbst wenn man versucht, eine Bildschirmaufnahme des Fensters "Security & Privacy" (über Grab.app, Capture-> Window) zu machen, schlägt dies fehl:
Also gute Nachrichten (für Apple), offensichtliche Angriffe gegen SKEL scheitern.
Natürlich haben Angreifer die einfachere Aufgabe - ein einziger Implementierungsfehler in SKEL kann uns erlauben, sie vollständig zu umgehen.
Apple hingegen muss sich gegen alles schützen. Also, werden Hacker immer gewinnen ! ... manchmal nach nur 20 Minuten Stoßen: P
Während wir zu diesem Zeitpunkt keine technischen Details der Sicherheitsanfälligkeit veröffentlichen können, ist hier eine Demo einer vollständigen SKEL-Umgehung. Wie unten im iTerm-Fenster unten zu sehen ist, nach dem Dumping der Version des Systems (High Sierra, Beta 9) und zeigt, dass SIP aktiviert ist und dass die Kernel-Erweiterung, die wir laden wollen (LittleSnitch.kext) nicht geladen ist, noch In der 'Kext Policy'-Datenbank passiert etwas "Magisches".
Kurz gesagt, nutzen wir eine Implementierungsschwachstelle in SKEL aus, die es uns erlaubt, einen neuen nicht genehmigten Kext vollständig programmgesteuert ohne jegliche Benutzerinteraktion zu laden:
Fazit
Auf dieser Seite haben wir kurz das "Secure Kernel Extension Loading" (SKEL) von High Sierra besprochen und eine neue ZERO-DAY-Sicherheitslücke demonstriert, die ausgenutzt werden kann, um diese neue "Sicherheitsfunktion" vollständig zu umgehen.
Wenn solche "Sicherheits" -Funktionen eingeführt werden - selbst wenn dies mit den edelsten Absichten geschieht - erschweren sie oft das Leben von Drittentwicklern und -benutzern, ohne die "Bösen" Hacker zu beeinträchtigen (die nicht "nach den Regeln" spielen müssen). '). Die fehlerhafte Implementierung von SKL der SKF ist ein perfektes Beispiel dafür.
Natürlich, wenn es das ultimative Ziel von Apple ist, weiterhin die Kontrolle über das System von den Benutzern abzulenken, unter dem Deckmantel der "Sicherheit", sind wir uns nicht sicher, ob das überhaupt intendiert sein darf und von Relevanz ist. :(