first commit
This commit is contained in:
@@ -0,0 +1,17 @@
|
||||
- Mach-O Library Load Commands
|
||||
- `LC_LOAD_DYLIB` specifies a dynamic library to be loaded at runtime and the dylib must be loaded when the binary or library is executed.
|
||||
- `LC_LOAD_WEAK_DYLIB` specifies a weakly linked dynamic library. If the dylib is not found, the binary or library will still be executed without interruption.
|
||||
- `LC_REEXPORT_DYLIB` specifies a dynamic library to be reexported by the binary or library.
|
||||
- Install names specify the path to the dylib at runtime
|
||||
- `@executable_path` **–** This variable is replaced with the path to the directory containing the main executable for the process, for example, _/Applications/Dummy.app/Contents/MacOS._
|
||||
- `@loader_path` **–** This variable is replaced with the path to the directory containing the mach-o binary, which contains the load command.
|
||||
- `@rpath` – is a variable that will be replaced with one or more paths specified by the LC_RPATH command at runtime.
|
||||
- Requirements for dylib hijacking:
|
||||
- The app is not restricted with a hardened runtime or having the com.apple.security.cs.disable-library-validation entitlement.
|
||||
- One of the files in the application path `app/Contents` is not properly signed (Figure 3). We can run the `codesign –verify –verbose <app_name>` command. If we see an error message in the output, it indicates that the signature is invalid.
|
||||
- Identify weak dylibs:
|
||||
- `otool -l <app_name> | grep LC_LOAD_WEAK_DYLIB -A5`
|
||||
- Look for a weak library from a writeable directory
|
||||
- Check if any dylibs are loaded from `@rpath`:
|
||||
- ` otool -l <app_name> | grep LC_LOAD_DYLIB -A5`
|
||||
- If any libs have `@rpath`, see if directory is writeable. If multiple `LC_RPATH` load commands are present and the library is not found in primary run-path, a malicious dylib can be placed in the primary path.
|
||||
Reference in New Issue
Block a user