Just like the many supported startup locations and run keys within Windows, OS X offers a few which are deprecated but still functional. Closing the application will always kill the agent. Important Note: In some cases, killing the agent will also close the application. When we start the Xcode application, we receive a new EmPyre agent running in that application’s process! In Figure 6, we see that once the module is completed, an EmPyre dylib is configured and copied to the vulnerable rpath we specified. Once we have all of our options set, we can execute the module. The “vulnerableRPATH” refers to the rpath value returned from the HijackScanner module.
The “LegitimateDylibPath” option will define the full path to the legitimate dylib loaded into the application. Be sure that the architecture of the dylib matches the architecture of the vulnerable application. The Listener, UserAgent, and Arch options are all used to generate the hijacker dylib. This is yet another slightly modified script written by This module does all the heavy lifting for configuring the EmPyre dylib and patching in the path to the legitimate dylib. The CreateHijacker module in persistence/osx/ configures an EmPyre dylib to be used in a Dylib Hijack. Instructions are provided after the scan output to gather the information necessary for the next module. Here we see that the Xcode application is vulnerable to a dylib hijack with the DVTFoundation library. You will also need to locate the legitimate dylib for the next module in this attack. Once the scan is finished, your output will provide you with the path to the vulnerable binary and the full path to where an EmPyre dylib should be planted. To speed up the scan, set a path or only scan loaded process executables. With the default options for the module, every Mach-O binary on the file system will be examined, which can take quite some time. This is simply an adaption to python script to scan the system for Mach-O binaries, load each and examine the load commands to determine if the application is vulnerable. To carry out this attack in EmPyre, you will need to first run the HijackScanner module in situational_awareness/host/osx/. When the application starts, it will load the attacking dylib first and then load the legitimate dylib. To remedy this, the hijacking dylib will need to have a LC_REEXPORT_DYLIB load command that provides the path to the legitimate dylib. If those functions are not found, the application will crash. When an application normally loads a library, the os loader will try to resolve symbols for functions required by the application.
We can abuse dyld’s load order to obtain consistent code execution and/or persistence in OS X.īefore we can weaponize Dylib Hijacks, there is a small problem to address. For more information on Dylib Hijacks for weak dylibs, please read the white paper on Dylib Hijacks by The load commands slightly differ but still offer the same way to conduct this attack. If the specified library is not present on the system, we can plant the dylib in the specified path and it will be loaded by the application at runtime. This indicates that the specified dylib is not required but will be loaded if found. A slight variation to this attack, which we won’t cover in this post, involves the LC_LOAD_WEAK_DYLIB load command. The issue is that any library planted in an LC_RPATH that is found before the legitimate dylib, will be loaded first. Once the library is found it is loaded into the application at runtime. Each path is searched in succession by dyld to locate the required library. Notice that the path is prepended with This signals to the OS loader to examine the LC_RPATH (Figure 2) load commands in order to expand the variable. The “Name” field in the LC_LOAD_DYLIB load command identifies the file path to the DVTFoundation library. Load commands provide the OS loader with instructions on where to find the application’s entry point, offsets for the text and data sections, and all of the libraries needed by the application at runtime. Let’s briefly examine the Mach-O header to understand why this vulnerability exists.įigure 1 depicts the load commands for Xcode. Dylib Hijacking exists because of how “dyld”, the system dynamic linker, searches and loads these libraries. Dylibs are comparable to DLLs in that they contain code executed by applications at runtime. One of the most effective methods is Dylib Hijacking.
Mac OS X offers several methods to abuse system functionality and obtain persistence through reboots.
This post is number 3 of the EmPyre series and cross post with a fellow friend and ATD co-worker Thanks to the entire ATD family and dev team of - can be found here: