Önceki görüntüde, com.apple.security.app-sandbox yetkisine sahip bir uygulama çalıştırıldığında sandbox'ın nasıl yükleneceği gözlemlenebilir.
Derleyici, ikili dosyaya /usr/lib/libSystem.B.dylib bağlantısını yapacaktır.
Daha sonra, libSystem.B, xpc_pipe_routine uygulamanın yetkilerini securityd'ye gönderene kadar birkaç başka fonksiyonu çağıracaktır. Securityd, sürecin Sandbox içinde karantinaya alınması gerekip gerekmediğini kontrol eder ve eğer öyleyse, karantinaya alınacaktır.
Son olarak, sandbox, __sandbox_ms çağrısıyla etkinleştirilecek ve bu da __mac_syscall'ı çağıracaktır.
Olası Bypass'ler
Karantina niteliğini atlama
Sandbox'lı süreçler tarafından oluşturulan dosyalar, sandbox kaçışını önlemek için karantina niteliği eklenir. Ancak, eğer bir sandboxlı uygulama içinde karantina niteliği olmayan bir .app klasörü oluşturmayı başarırsanız, uygulama paketinin ikili dosyasını /bin/bash'e yönlendirebilir ve plist içinde bazı çevre değişkenleri ekleyerek open'i kötüye kullanarak yeni uygulamayı sandbox dışı başlatabilirsiniz.
Bu nedenle, şu anda, eğer sadece karantina niteliği olmayan bir isimle biten .app klasörü oluşturabiliyorsanız, sandbox'tan kaçabilirsiniz çünkü macOS sadece .app klasöründeki ve ana çalıştırılabilir dosyadakikarantina niteliğini kontrol eder (ve biz ana çalıştırılabilir dosyayı /bin/bash'e yönlendireceğiz).
Eğer bir .app paketi zaten çalıştırılmak üzere yetkilendirilmişse (çalıştırma yetkisi olan bir karantina xttr'ı varsa), bunu da kötüye kullanabilirsiniz... tek farkla, artık .app paketleri içinde yazamazsınız, eğer bazı ayrıcalıklı TCC izinleriniz yoksa (ki bunlar sandbox yüksek içinde olmayacaktır).
Bir uygulama sandbox'lı olacak şekilde tasarlanmışsa (com.apple.security.app-sandbox), örneğin bir LaunchAgent'tan çalıştırıldığında sandbox'ı atlamak mümkündür.
Bu yazıda açıklandığı gibi, sandbox'lı bir uygulama ile kalıcılık kazanmak istiyorsanız, otomatik olarak bir LaunchAgent olarak çalıştırılmasını sağlayabilir ve belki de DyLib çevre değişkenleri aracılığıyla kötü niyetli kod enjekte edebilirsiniz.
Otomatik Başlatma Konumlarını Kötüye Kullanma
Eğer bir sandbox'lı süreç, sonrasında bir sandbox dışı uygulamanın ikili dosyasını çalıştıracağı bir yere yazabiliyorsa, sadece oraya ikili dosyayı yerleştirerek kaçabilir. Bu tür konumların iyi bir örneği ~/Library/LaunchAgents veya /System/Library/LaunchDaemons'dır.
Bunun için belki de 2 adım gerekebilir: Daha izinli bir sandbox (file-read*, file-write*) ile bir sürecin kodunuzu çalıştırmasını sağlamak ve bu kodun aslında sandbox dışı çalıştırılacak bir yere yazmasını sağlamak.
Otomatik Başlatma konumları hakkında bu sayfayı kontrol edin:
Eğer o sandbox sürecinden, daha az kısıtlayıcı sandbox'larda (veya hiç) çalışan diğer süreçleri tehlikeye atabiliyorsanız, onların sandbox'larından kaçabilirsiniz:
Bu araştırma sandbox'ı atlamak için 2 yol keşfetti. Çünkü sandbox, libSystem kütüphanesi yüklendiğinde kullanıcı alanından uygulanır. Eğer bir ikili dosya bu kütüphaneyi yüklemekten kaçınabilirse, asla sandbox'a alınmaz:
Eğer ikili dosya tamamen statik olarak derlenmişse, o kütüphaneyi yüklemekten kaçınabilir.
Eğer ikili dosya herhangi bir kütüphane yüklemeye ihtiyaç duymuyorsa (çünkü bağlayıcı da libSystem'dadır), libSystem'i yüklemesine gerek kalmaz.
Shell kodları
Shell kodlarının ARM64'te bile libSystem.dylib'de bağlanması gerektiğini unutmayın:
# 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
Uygulama ~/Desktop/del.txt dosyasını okumaya çalışacak, ancak Sandbox buna izin vermeyecek.
Sandbox aşıldığında okuyabilmesi için orada bir dosya oluşturun:
echo"Sandbox Bypassed">~/Desktop/del.txt
Uygulamayı hata ayıklayalım ve Sandbox'ın ne zaman yüklendiğini görelim:
# 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)