Skip to content
KitploitKITPLOIT
ToolsBlog
Einreichen
ToolsBlog
Einreichen

Hacking-, PenTest- und Cybersicherheits-Tools für Ihr Sicherheitsarsenal!

Kitploit ist ein Verzeichnis von Hacking-, Cybersicherheits- und Pentesting-Tools. Entdecken Sie die neuesten Projekt-Updates, um Schwachstellen zu finden, Systeme zu analysieren, Tests zu automatisieren und Ihre Sicherheit zu stärken.

··Feeds·Kontakt·Datenschutz·© 2026 Kitploit

Tool-Verzeichnis

Kategorien

Alle Kategorien anzeigen
Loading categories
SnatchBox — SnatchBox (CVE-2020-27935) ist eine Sandbox-Escape-Schwachstelle und ein Exploit, der macOS bis Version 10.15.x betrifft. | Kitploit
Tools/GitHubGitHub/liji32/snatchbox
SchwachstellenanalyseExploitationReverse EngineeringPayload-EntwicklungBinary-Exploitation
GitHubliji32/snatchbox

SnatchBox

SnatchBox (CVE-2020-27935) ist eine Sandbox-Escape-Schwachstelle und ein Exploit, der macOS bis Version 10.15.x betrifft.

Repository anzeigen
3251vor 5 JahrenVon Kitploit geprüft

Beliebteste

Alle anzeigen →

Entdecken Sie die meistgenutzten Tools unserer Community.

Alle Tools erkunden

Durchsuchen Sie unsere Tool-Sammlung

Alle Tools anzeigen →
Teilen

SnatchBox

SnatchBox (CVE-2020-27935) ist eine Sandbox-Escape-Sicherheitslücke, die macOS bis Version 10.15 sowie frühe Beta-Versionen von macOS 11.0 betrifft. Die bedeutendste Auswirkung von SnatchBox besteht darin, dass es einem böswilligen Publisher ermöglicht, aus der nicht optionalen macOS-App-Store-Sandbox auszubrechen und vollständigen Zugriff auf alle Dateien des Benutzers zu erlangen, wodurch das Sicherheitsmodell des App Store unter macOS gebrochen wird.

Die Sicherheitslücke

Die Tatsache, dass sich in macOS – anders als beispielsweise in iOS – eine Userspace-Task freiwillig selbst in eine Sandbox begibt, ist konstruktionsbedingt anfällig. Da ein potenziell bösartiger Autor bei einer solchen Task nahezu vollständige Kontrolle über deren Speicherzuordnungen und -inhalte hat und Code, der vor der Sandbox-Initialisierung ausgeführt wird (z. B. dyld selbst oder die Objective-C-Laufzeitumgebung), die Inhalte dieser potenziell bösartigen Binärdatei analysiert, können sorgfältig präparierte Daten dazu genutzt werden, vor der Sandbox-Initialisierung Codeausführung zu erlangen. Wenn der Prozess, bevor er in eine Sandbox gezwungen wird, niemals Code ausführen würde, einschließlich dyld-Code, wäre dies kein Problem gewesen, da eine frühe Codeausführung dem Angriff in diesem Fall nichts bringen würde. Es ist konzeptionell ähnlich zu Saagar Jhas Sandbox-Bypass, außer dass es die neu eingeführten Mitigationen und App-Store-Validierungen umgeht.

Ausnutzung vor 10.15

Vor macOS 10.15 ist die Ausnutzung dieses Fehlers relativ einfach. Man erstellt eine Binärdatei, die eine Objective-C-Kategorie für eine Klasse enthält, die vor der Sandbox-Initialisierung verwendet wird (wie z. B. OS_xpc_object), und überschreibt eine Methode (vorzugsweise eine geerbte, um Laufzeitwarnungen zu vermeiden), die vor der Sandbox-Initialisierung verwendet wird (wie z. B. , das beim ersten Zugriff auf eine Klasse implizit aufgerufen wird). Da Kategorien vor der Sandbox-Initialisierung geladen werden und der erste Zugriff auf (oder andere geeignete Opferklassen) nach dem Laden der Kategorien und vor der Sandbox-Initialisierung erfolgt, wird die vom Angreifer bereitgestellte -Methode (oder eine andere geeignete Opfermethode) vor der Sandbox-Initialisierung aufgerufen, was es beispielsweise ermöglicht, auf Daten außerhalb des Containers zuzugreifen. Alternativ kann der Angreifer den Verweis auf (der die Sandbox initialisiert) durch eine nop-ähnliche Funktion ersetzen, um die Sandbox (möglicherweise bedingt) auch nach der Wiederaufnahme der Ausführung zu deaktivieren.

+initialize
OS_xpc_object
+initialize
_libsecinit_initializer

Ausnutzung in 10.15 und 11.0 Beta

Die in macOS 10.15 verwendete Objective-C-Laufzeitumgebung ist gegenüber der zuvor beschriebenen Ausnutzungstechnik nicht anfällig, da Kategorien nicht geladen werden, bevor didCallDyldNotifyRegister gesetzt ist, wodurch unsere +initialize-Methode erst nach der Sandbox-Initialisierung aufgerufen wird. map_images wird jedoch weiterhin für unsere Binärdatei aufgerufen, was es ermöglicht, Laufzeitdaten auf unbeabsichtigte Weise zu verändern, sodass wir vor der Sandbox-Initialisierung Code ausführen können. Die vollständige, kommentierte Ausnutzung befindet sich in main.c, aber ich werde hier die grundlegenden Details durchgehen. Wir konstruieren eine Objective-C-Klassenstruktur, deren data-Zeiger auf eine Stelle in libxbc.dylib zeigt. Diese Stelle muss so gewählt werden, dass in flags Bit 31 (RW_REALIZED) gesetzt ist, damit die Laufzeitumgebung nicht versucht, diese ungültige Klasse zu realisieren und abzustürzen, und firstSubclass muss seine Adresse mit der isa einer Klasse teilen, die wir überschreiben möchten. Eine weitere (Meta-)Klasse wird von dieser ungültigen Klasse erben und eine eigene +initialize-Methode bereitstellen. Wir fügen die Unterklasse zu __objc_nlclslist hinzu, damit die Laufzeitumgebung diese Klasse realisiert. Wenn die Laufzeitumgebung unsere Unterklasse realisiert, was vor der Sandbox-Initialisierung geschieht, ruft sie addSubclass für unsere ungültige Oberklasse und Unterklasse auf, wodurch die isa des Opfers durch einen Zeiger auf unsere Unterklasse ersetzt wird und effektiv alle ihre Methoden durch unsere +initialize-Methode ersetzt werden. Wenn unsere +initialize-Methode aufgerufen wird – was vor der Sandbox-Initialisierung geschieht, sofern wir eine geeignete Opferklasse gewählt haben – können wir erneut _libsecinit_initializer-Verweise durch NOPs ersetzen (bedingt oder nicht) und die von uns vorgenommenen Laufzeitänderungen korrigieren, um die Ausführung später ohne Absturz fortzusetzen.

Mitgelieferte Demo

Die mitgelieferte Demo kann erstellt werden, indem man make ausführt, eine Datei unter ~/Documents/SecretDocument.txt anlegt und SnatchBox.app/Contents/MacOS/SnatchBox vom Terminal aus ausführt (Ein Bundle wird erstellt, da es von com.apple.security.app-sandbox verlangt wird, aber es handelt sich weiterhin um ein Befehlszeilenprogramm). Die erstellte Binärdatei ist mit com.apple.security.app-sandbox signiert, was normalerweise den Zugriff auf ~/Documents/SecretDocument.txt verhindern würde (Da sie sich nicht in unserem Container befindet), aber sie kann ihre Daten trotzdem lesen. Aufgrund von Änderungen an der Laufzeitstruktur funktioniert diese Demo unverändert nicht unter macOS 10.14 und früher, aber unter 10.15 und 11.0 (Getestet: 10.15.4, 10.15.7 und 11.0 Beta (20A5354i)). Die beiden Ausnutzungstechniken können kombiniert werden, um beide Laufzeitversionen anzugreifen, aber eine solche Demonstration wird nicht bereitgestellt.

Beispielausführung:

root@kitploit:~
CatalinaVM:SnatchBox lior$ make
mkdir -p SnatchBox.app/Contents/MacOS/
clang -O3 -Wall -framework Foundation main.m -o SnatchBox.app/Contents/MacOS/SnatchBox
cp Info.plist SnatchBox.app/Contents/
codesign --force --sign - SnatchBox.app --entitlements ent.xml
CatalinaVM:SnatchBox lior$ echo "Quack"> ~/Documents/SecretDocument.txt
CatalinaVM:SnatchBox lior$ codesign -d --entitlements :- SnatchBox.app/Contents/MacOS/SnatchBox 
Executable=/Volumes/SharedFolders/Home/Projects/SnatchBox/SnatchBox.app/Contents/MacOS/SnatchBox
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>com.apple.security.app-sandbox</key>
    <true/>
    <key>com.apple.security.files.user-selected.read-only</key>
    <true/>
</dict>
</plist>
CatalinaVM:SnatchBox lior$ SnatchBox.app/Contents/MacOS/SnatchBox 
Found libsecinit_initializer at 0x7fff72309124
Found libSystem.B.dylib at 0x7fff6f0de000
Found __DATA at 0x7fff984eeca0
Replacing libsecinit_initializer reference at 0x7fff984eed48 with a nop
2020-12-18 16:31:48.196 SnatchBox[804:8043] Attempting to read protected file: /Users/lior/Documents/SecretDocument.txt
2020-12-18 16:31:48.197 SnatchBox[804:8043] Escaped sandbox! The contents are: <51756163 6b0a>

Auswirkungen

Wie bereits erwähnt, ermöglicht dies die Erstellung einer macOS-App-Store-Anwendung, die nicht in einer Sandbox läuft, obwohl sie dazu von der App-Store-Richtlinie verpflichtet ist. Die Sicherheitslücke kann auch in einem Framework verwendet werden, das von ansonsten legitimen App-Store-Anwendungen genutzt werden kann. Schließlich kann sie sogar mit etwas Ähnlichem wie „Xcode Ghost" kombiniert werden, um bösartigen Code, der außerhalb der Sandbox läuft, massenhaft in App-Store-Anwendungen einzuschleusen.

Behebung

Apple behob die Sicherheitslücke während der Beta-Testphase von macOS 11.0, indem ein Aufruf von malloc_size in realizeClassWithoutSwift hinzugefügt wurde. Dies bestätigt, dass eine Klasse, die als realisiert markiert ist (RW_REALIZED, wie unsere gefälschte Klasse), tatsächlich einen gültigen, per malloc allokierten Datenzeiger mit der korrekten Größe (0x20 Bytes) besitzt. Ist dies nicht der Fall, bricht die Laufzeitumgebung mit einer Meldung ähnlich wie realized class 0x100002078 has corrupt data pointer 0x7fff88c00948 ab. Die Behebung wurde auch auf iOS, iPadOS, tvOS und watchOS angewendet; auch wenn diese nicht direkt betroffen waren.

Tool herunterladen