macOS Library Injection
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
The code of dyld is open source and can be found in https://opensource.apple.com/source/dyld/ and cab be downloaded a tar using a URL such as https://opensource.apple.com/tarballs/dyld/dyld-852.2.tar.gz
Take a look on how Dyld loads libraries inside binaries in:
macOS Dyld ProcessThis is like the LD_PRELOAD on Linux. It allows to indicate a process that is going to be run to load a specific library from a path (if the env var is enabled)
This technique may be also used as an ASEP technique as every application installed has a plist called "Info.plist" that allows for the assigning of environmental variables using a key called LSEnvironmental.
Since 2012 Apple has drastically reduced the power of the DYLD_INSERT_LIBRARIES.
Go to the code and check src/dyld.cpp. In the function pruneEnvironmentVariables you can see that DYLD_* variables are removed.
In the function processRestricted the reason of the restriction is set. Checking that code you can see that the reasons are:
The binary is setuid/setgid
Existence of __RESTRICT/__restrict section in the macho binary.
The software has entitlements (hardened runtime) without com.apple.security.cs.allow-dyld-environment-variables entitlement
Check entitlements of a binary with: codesign -dv --entitlements :- </path/to/bin>
In more updated versions you can find this logic at the second part of the function configureProcessRestrictions. However, what is executed in newer versions is the beginning checks of the function (you can remove the ifs related to iOS or simulation as those won't be used in macOS.
Even if the binary allows to use the DYLD_INSERT_LIBRARIES env variable, if the binary checks the signature of the library to load it won't load a custom what.
In order to load a custom library, the binary needs to have one of the following entitlements:
or the binary shouldn't have the hardened runtime flag or the library validation flag.
You can check if a binary has hardened runtime with codesign --display --verbose <bin> checking the flag runtime in CodeDirectory like: CodeDirectory v=20500 size=767 flags=0x10000(runtime) hashes=13+7 location=embedded
You can also load a library if it's signed with the same certificate as the binary.
Find a example on how to (ab)use this and check the restrictions in:
macOS Dyld Hijacking & DYLD_INSERT_LIBRARIESRemember that previous Library Validation restrictions also apply to perform Dylib hijacking attacks.
As in Windows, in MacOS you can also hijack dylibs to make applications execute arbitrary code (well, actually froma regular user this coul not be possible as you might need a TCC permission towrite inside an .app bundle and hijack a library).
However, the way MacOS applications load libraries is more restricted than in Windows. This implies that malware developers can still use this technique for stealth, but the probably to be able to abuse this to escalate privileges is much lower.
First of all, is more common to find that MacOS binaries indicates the full path to the libraries to load. And second, MacOS never search in the folders of the $PATH for libraries.
The main part of the code related to this functionality is in ImageLoader::recursiveLoadLibraries in ImageLoader.cpp.
There are 4 different header Commands a macho binary can use to load libraries:
LC_LOAD_DYLIB command is the common command to load a dylib.
LC_LOAD_WEAK_DYLIB command works like the previous one, but if the dylib is not found, execution continues without any error.
LC_REEXPORT_DYLIB command it proxies (or re-exports) the symbols from a different library.
LC_LOAD_UPWARD_DYLIB command is used when two libraries depend on each other (this is called an upward dependency).
However, there are 2 types of dylib hijacking:
Missing weak linked libraries: This means that the application will try to load a library that doesn't exist configured with LC_LOAD_WEAK_DYLIB. Then, if an attacker places a dylib where it's expected it will be loaded.
The fact that the link is "weak" means that the application will continue running even if the library isn't found.
The code related to this is in the function ImageLoaderMachO::doGetDependentLibraries of ImageLoaderMachO.cpp where lib->required is only false when LC_LOAD_WEAK_DYLIB is true.
Find weak linked libraries in binaries with (you have later an example on how to create hijacking libraries):
Configured with @rpath: Mach-O binaries can have the commands LC_RPATH and LC_LOAD_DYLIB. Base on the values of those commands, libraries are going to be loaded from different directories.
LC_RPATH contains the paths of some folders used to load libraries by the binary.
LC_LOAD_DYLIB contains the path to specific libraries to load. These paths can contain @rpath, which will be replaced by the values in LC_RPATH. If there are several paths in LC_RPATH everyone will be used to search the library to load. Example:
If LC_LOAD_DYLIB contains @rpath/library.dylib and LC_RPATH contains /application/app.app/Contents/Framework/v1/ and /application/app.app/Contents/Framework/v2/. Both folders are going to be used to load library.dylib. If the library doesn't exist in [...]/v1/ and attacker could place it there to hijack the load of the library in [...]/v2/ as the order of paths in LC_LOAD_DYLIB is followed.
Find rpath paths and libraries in binaries with: otool -l </path/to/binary> | grep -E "LC_RPATH|LC_LOAD_DYLIB" -A 5
@executable_path: Is the path to the directory containing the main executable file.
@loader_path: Is the path to the directory containing the Mach-O binary which contains the load command.
When used in an executable, @loader_path is effectively the same as @executable_path.
When used in a dylib, @loader_path gives the path to the dylib.
The way to escalate privileges abusing this functionality would be in the rare case that an application being executed by root is looking for some library in some folder where the attacker has write permissions.
A nice scanner to find missing libraries in applications is Dylib Hijack Scanner or a CLI version. A nice report with technical details about this technique can be found here.
Example
macOS Dyld Hijacking & DYLD_INSERT_LIBRARIESRemember that previous Library Validation restrictions also apply to perform Dlopen hijacking attacks.
From man dlopen:
When path does not contain a slash character (i.e. it is just a leaf name), dlopen() will do searching. If $DYLD_LIBRARY_PATH was set at launch, dyld will first look in that directory. Next, if the calling mach-o file or the main executable specify an LC_RPATH, then dyld will look in those directories. Next, if the process is unrestricted, dyld will search in the current working directory. Lastly, for old binaries, dyld will try some fallbacks. If $DYLD_FALLBACK_LIBRARY_PATH was set at launch, dyld will search in those directories, otherwise, dyld will look in /usr/local/lib/ (if the process is unrestricted), and then in /usr/lib/ (this info was taken from man dlopen).
$DYLD_LIBRARY_PATH
LC_RPATH
CWD(if unrestricted)
$DYLD_FALLBACK_LIBRARY_PATH
/usr/local/lib/ (if unrestricted)
/usr/lib/
If no slashes in the name, there would be 2 ways to do an hijacking:
If any LC_RPATH is writable (but signature is checked, so for this you also need the binary to be unrestricted)
If the binary is unrestricted and then it's possible to load something from the CWD (or abusing one of the mentioned env variables)
When path looks like a framework path (e.g. /stuff/foo.framework/foo), if $DYLD_FRAMEWORK_PATH was set at launch, dyld will first look in that directory for the framework partial path (e.g. foo.framework/foo). Next, dyld will try the supplied path as-is (using current working directory for relative paths). Lastly, for old binaries, dyld will try some fallbacks. If $DYLD_FALLBACK_FRAMEWORK_PATH was set at launch, dyld will search those directories. Otherwise, it will search /Library/Frameworks (on macOS if process is unrestricted), then /System/Library/Frameworks.
$DYLD_FRAMEWORK_PATH
supplied path (using current working directory for relative paths if unrestricted)
$DYLD_FALLBACK_FRAMEWORK_PATH
/Library/Frameworks (if unrestricted)
/System/Library/Frameworks
If a framework path, the way to hijack it would be:
If the process is unrestricted, abusing the relative path from CWD the mentioned env variables (even if it's not said in the docs if the process is restricted DYLD_* env vars are removed)
When path contains a slash but is not a framework path (i.e. a full path or a partial path to a dylib), dlopen() first looks in (if set) in $DYLD_LIBRARY_PATH (with leaf part from path ). Next, dyld tries the supplied path (using current working directory for relative paths (but only for unrestricted processes)). Lastly, for older binaries, dyld will try fallbacks. If $DYLD_FALLBACK_LIBRARY_PATH was set at launch, dyld will search in those directories, otherwise, dyld will look in /usr/local/lib/ (if the process is unrestricted), and then in /usr/lib/.
$DYLD_LIBRARY_PATH
supplied path (using current working directory for relative paths if unrestricted)
$DYLD_FALLBACK_LIBRARY_PATH
/usr/local/lib/ (if unrestricted)
/usr/lib/
If slashes in the name and not a framework, the way to hijack it would be:
If the binary is unrestricted and then it's possible to load something from the CWD or /usr/local/lib (or abusing one of the mentioned env variables)
Note: There are no configuration files to control dlopen searching.
Note: If the main executable is a set[ug]id binary or codesigned with entitlements, then all environment variables are ignored, and only a full path can be used (check DYLD_INSERT_LIBRARIES restrictions for more detailed info)
Note: Apple platforms use "universal" files to combine 32-bit and 64-bit libraries. This means there are no separate 32-bit and 64-bit search paths.
Note: On Apple platforms most OS dylibs are combined into the dyld cache and do not exist on disk. Therefore, calling stat() to preflight if an OS dylib exists won't work. However, dlopen_preflight() uses the same steps as dlopen() to find a compatible mach-o file.
Check paths
Lets check all the options with the following code:
If you compile and execute it you can see where each library was unsuccessfully searched for. Also, you could filter the FS logs:
If a privileged binary/app (like a SUID or some binary with powerful entitlements) is loading a relative path library (for example using @executable_path or @loader_path) and has Library Validation disabled, it could be possible to move the binary to a location where the attacker could modify the relative path loaded library, and abuse it to inject code on the process.
DYLD_* and LD_LIBRARY_PATH env variablesIn the file dyld-dyld-832.7.1/src/dyld2.cpp it's possible to fund the function pruneEnvironmentVariables, which will remove any env variable that starts with DYLD_ and LD_LIBRARY_PATH=.
It'll also set to null specifically the env variables DYLD_FALLBACK_FRAMEWORK_PATH and DYLD_FALLBACK_LIBRARY_PATH for suid and sgid binaries.
This function is called from the _main function of the same file if targeting OSX like this:
and those boolean flags are set in the same file in the code:
Which basically means that if the binary is suid or sgid, or has a RESTRICT segment in the headers or it was signed with the CS_RESTRICT flag, then !gLinkContext.allowEnvVarsPrint && !gLinkContext.allowEnvVarsPath && !gLinkContext.allowEnvVarsSharedCache is true and the env variables are pruned.
Note that if CS_REQUIRE_LV is true, then the variables won't be pruned but the library validation will check they are using the same certificate as the original binary.
__RESTRICT with segment __restrictCreate a new certificate in the Keychain and use it to sign the binary:
Note that even if there are binaries signed with flags 0x0(none), they can get the CS_RESTRICT flag dynamically when executed and therefore this technique won't work in them.
You can check if a proc has this flag with (get csops here):
and then check if the flag 0x800 is enabled.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
