Na imagem anterior, é possível observar como o sandbox será carregado quando um aplicativo com a permissão com.apple.security.app-sandbox é executado.
O compilador irá vincular /usr/lib/libSystem.B.dylib ao binário.
Em seguida, libSystem.B irá chamar outras várias funções até que o xpc_pipe_routine envie as permissões do aplicativo para o securityd. O Securityd verifica se o processo deve ser colocado em quarentena dentro do Sandbox e, se sim, ele será colocado em quarentena.
Por fim, o sandbox será ativado com uma chamada para __sandbox_ms, que chamará __mac_syscall.
Possíveis Bypasses
Bypass do atributo de quarentena
Arquivos criados por processos em sandbox recebem o atributo de quarentena para evitar a fuga do sandbox. No entanto, se você conseguir criar uma pasta .app sem o atributo de quarentena dentro de um aplicativo em sandbox, poderá fazer com que o binário do pacote do aplicativo aponte para /bin/bash e adicione algumas variáveis de ambiente no plist para abusar do open e iniciar o novo aplicativo sem sandbox.
Portanto, no momento, se você for capaz de criar uma pasta com um nome terminando em .app sem um atributo de quarentena, você pode escapar do sandbox porque o macOS só verifica o atributo de quarentena na pasta .app e no executável principal (e vamos apontar o executável principal para /bin/bash).
Observe que se um pacote .app já foi autorizado a ser executado (tem um xttr de quarentena com a flag autorizada para executar), você também poderia abusar dele... exceto que agora você não pode escrever dentro de pacotes .app a menos que tenha algumas permissões TCC privilegiadas (o que você não terá dentro de um sandbox alto).
Mesmo que um aplicativo seja destinado a estar em sandbox (com.apple.security.app-sandbox), é possível contornar o sandbox se ele for executado a partir de um LaunchAgent (~/Library/LaunchAgents) por exemplo.
Como explicado neste post, se você deseja obter persistência com um aplicativo que está em sandbox, você pode fazê-lo ser executado automaticamente como um LaunchAgent e talvez injetar código malicioso via variáveis de ambiente DyLib.
Abusando de Locais de Inicialização Automática
Se um processo em sandbox pode escrever em um local onde mais tarde um aplicativo sem sandbox vai executar o binário, ele será capaz de escapar apenas colocando o binário lá. Um bom exemplo desses locais são ~/Library/LaunchAgents ou /System/Library/LaunchDaemons.
Para isso, você pode precisar de 2 etapas: fazer um processo com um sandbox mais permissivo (file-read*, file-write*) executar seu código que realmente escreverá em um local onde ele será executado sem sandbox.
Confira esta página sobre Locais de Inicialização Automática:
Se a partir do processo em sandbox você conseguir comprometer outros processos em sandboxes menos restritivos (ou nenhum), você será capaz de escapar para seus sandboxes:
Esta pesquisa descobriu 2 maneiras de contornar o Sandbox. Como o sandbox é aplicado do espaço do usuário quando a biblioteca libSystem é carregada. Se um binário pudesse evitar carregá-lo, ele nunca seria colocado em sandbox:
Se o binário fosse completamente compilado estaticamente, ele poderia evitar carregar essa biblioteca.
Se o binário não precisasse carregar nenhuma biblioteca (porque o linker também está em libSystem), ele não precisaria carregar libSystem.
Shellcodes
Observe que mesmo shellcodes em ARM64 precisam ser vinculados em libSystem.dylib:
Este arquivo contém as informações de privilégios necessárias para o aplicativo ser executado no macOS. Você pode modificar este arquivo para adicionar ou remover privilégios específicos do aplicativo. Certifique-se de entender o impacto das alterações nos privilégios antes de fazer qualquer modificação.
Para mais informações sobre como configurar os privilégios do aplicativo no macOS, consulte a documentação oficial da Apple.
<!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/></dict></plist>
Info.plist
O arquivo Info.plist contém informações sobre o aplicativo, incluindo as permissões que ele requer. Certifique-se de revisar e entender essas permissões para garantir que o aplicativo esteja limitado apenas ao que é necessário para sua funcionalidade. Isso ajuda a reduzir possíveis vetores de ataque e a manter a segurança do sistema.
Além disso, verifique se o arquivo Info.plist não contém configurações suspeitas ou maliciosas que possam ser exploradas para contornar as proteções de segurança do macOS.
# 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
O aplicativo tentará ler o arquivo ~/Desktop/del.txt, o qual a Sandbox não permitirá.
Crie um arquivo lá, pois uma vez que a Sandbox for burlada, o aplicativo poderá lê-lo:
echo"Sandbox Bypassed">~/Desktop/del.txt
Vamos depurar a aplicação para ver quando o Sandbox é carregado:
# Load app in debugginglldb./sand# Set breakpoint in xpc_pipe_routine(lldb) b xpc_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) settings set target.max-string-summary-length 10000# 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) register read x2x2=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) memory read -f p 0x000000016fdfd660 -c 10x16fdfd660: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) breakpoint set --name __mac_syscall --condition '($x1 == 0)'(lldb) c# The 1 arg is the name of the policy, in this case "Sandbox"(lldb) memory read -f s $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) breakpoint delete 1 # Remove bp(lldb) register write $pc 0x187659928 #b.lo address(lldb) register write $x0 0x00(lldb) register write $x1 0x00(lldb) register write $x16 0x17d(lldb) cProcess2517resumingSandboxBypassed!Process2517exitedwithstatus=0 (0x00000000)
Mesmo com o Sandbox contornado, o TCC perguntará ao usuário se ele deseja permitir que o processo leia arquivos da área de trabalho.