Sudo mv libcrypto.1.0.0.dylib /Applications/.app/Contents/Frameworks/airhost.app/Contents/Frameworks/Īfter placing it in the proper location let's run some quick tests. This will create our newly re-exported libcrypto.1.0.0.dylib in the same directory as our libcrypto.1.0.1.dylib, all thats left is moving this newly created hijack dylib to the target hijack path: Python createHijacker.py libcrypto.1.0.1.dylib "/usr/local/Cellar/openssl/1.0.2r/lib/libcrypto.1.0.0.dylib"
#Dylib hijack scanner update
This will fix the versions in our hijacker dylib and uses install_name_tool to update the linker with our new library paths: Next we run Patrick Wardle's CreateHijacker.py script on our new hijacker dylib and the dylib we are proxying. Gcc -dynamiclib hijacker.c -o libcrypto.1.0.1.dylib -Wl,-reexplort_library,"/usr/local/Cellar/openssl/1.0.2r/lib/libcrypto.1.0.0.dylib" We can craft the template dylib like so, starting with compiling EvilBit's PoC code, and targeting openssl's libcrypto for the symbol re-exporting, which is what proxies our function calls for us: Granted, you need root permissions to write to this location, so there is no exploitation of privileges, just a sneaky way to persist for attackers. When it does this it references the openssl libcrypto dylib via an making it vulnerable to dylib hijacking. I found it in this helper app of zoom called Airhost which uses airplay to screenshare on the local network. I ended up finding a dylib hijack point in one of the macOS features of Zoom, but I don't really consider this a vulnerability of Zoom as it requires root permissions and it's a feature of dynamic linking. In my example below I'm largely going off of Csaba's writeup (theevilbit) because I found it really clear and concise. But I couldn't complete this post without finding a vulnerable example and practicing this persistence technique myself. This technique has also been incorporated as a post exploitation module in the empire framework for awhile now, if your looking for a fully fledged attacker framework with this capability. You will likely want a command line option if you plan to run this on a victim, although I recommend collecting their installed applications and searching for the vuln on a local research machine.
There are also some more python supporting tools here, and a version written in JXA.
There is the original python script Patrick Wardle wrote, which we will use later. But like I said at the beginning of this post, this is a pretty well explored technique at this point, so there is a lot of existing tooling if you don't want to use DHS for any reason. I mostly like DHS because of the GUI and it can be nice to save the output and diff them over time. Patrick releases a ton of great tools and one of my favorite tools to search for dylib hijacks is Wardle's DHS or Dylib Hijack Scanner, although we will use a few of his other scripts along the way as well. We can exploit both of these scenarios by placing our hijacked dylib in that target location and proxying the symbol calls to the legitimate dylib. These can also be detected based on the load commands as you will most likely see an LC_RPATH command, which tells it which dynamic paths to check.
The second is dylibs, or runpath dylibs, which use dynamic pathing so an application doesn't need to use absolute paths when specifying where a supporting framework may live, relative to an application. These are often used as a fault tolerant or dev friendly way of designing an application. The first is when an application loads a dylib using the LC_LOAD_WEAK_DYLIB load command, it will check a certain path and continue functioning even if the dylib is not found there.
#Dylib hijack scanner pdf
He later talked about it at DEFCON ( the pdf is very useful) and broke down the technique in excellent fashion, first laying out the dynamic linking process on macOS, then identifying two general hijacking points:Įssentially two things allow a dylib to be hijacked. Because this is an older technique there are a lot of writeups and tooling for it already, but the original technique for macOS dylib hijacking was first written about by Patrick Wardle in his white paper for Virus Bulletin. A basic feature of dynamic libraries and dynamic linking is the ability to load libraries from different locations, which is the core principal we will be abusing with this technique. Dylibs are a type of shared libraries on macOS used by the linker and mach-o binaries. I also like this as a persistence technique because I feel like it is less common and harder to detect than the standard launch agent or launch daemon persistence techniques. Like the last post, this is a very well explored technique so I'm going to point to a lot of existing research to make this a shorter guide. This time I'm looking at an awesome persistence technique for macOS, dylib hijacking.
0 kommentar(er)
