oscp/Necronomicon/Mac OS/Dylib Hijack.md

• 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.