Blog | G5 Cyber Security

iOS Dylib Hijacking: Is Your App at Risk?

G5 Cyber Security

TL;DR

Yes, dylib hijacking can happen on iOS apps, though it’s more difficult than on macOS. It relies on exploiting how your app loads shared libraries (dylibs). Modern iOS security features make it harder, but vulnerabilities in code signing, dynamic linking, or application sandboxing can still be exploited. Protecting against this requires careful attention to library dependencies and using strong security practices.

What is Dylib Hijacking?

Dylib hijacking (also known as shared library injection) occurs when a malicious dylib (dynamic library) is loaded instead of the legitimate one your app expects. This allows an attacker to modify the behaviour of your application, potentially gaining control or stealing sensitive data.

How Can It Happen on iOS?

  1. DYLD_LIBRARY_PATH: Historically, setting the DYLD_LIBRARY_PATH environment variable could force an app to load libraries from unexpected locations. However, modern iOS versions heavily restrict this.
    • On non-jailbroken devices, DYLD_LIBRARY_PATH is usually empty and cannot be easily modified by apps.
    • Jailbroken devices are more vulnerable as users can manipulate environment variables.
  2. Code Signing Issues: If your app incorrectly validates code signatures or relies on weak signing practices, an attacker could potentially replace legitimate dylibs with malicious ones.
  3. Dynamic Linking Vulnerabilities: Bugs in how your app dynamically links libraries can create opportunities for hijacking. This is less common but more dangerous when it occurs.
  4. Application Sandboxing Exploits: While iOS sandboxing isolates apps, vulnerabilities within the sandbox itself or in system services could allow an attacker to inject dylibs into another app’s process space.
  5. Pre-installed malicious libraries: In rare cases, compromised pre-installed libraries on a device (e.g., through malware) could be exploited.

Steps to Protect Your iOS App

  1. Code Signing Best Practices:
    • Always use strong code signing identities and properly sign all your app’s binaries and dylibs.
    • Enable entitlements that restrict the loading of libraries from untrusted sources.
    • Regularly review and update your code signing configuration.
  2. Library Dependency Management:
    • Minimize external library dependencies. The fewer libraries you use, the smaller the attack surface.
    • Carefully vet all third-party libraries before including them in your project. Check for known vulnerabilities and security issues.
    • Use static linking whenever possible to embed libraries directly into your app binary. This eliminates runtime dependency loading risks.
  3. Runtime Library Validation:
    • Implement checks at runtime to verify the integrity of loaded dylibs. You can compare hashes or signatures against known good values. 
      // Example (simplified) - not production ready!
#include <mach-o/loader.h>
#include <stdio.h>

int validate_dylib(const char *path) {
  Dl_info info;
  if (dlopen(path, RTLD_NOW) == NULL) {
    perror("dlopen failed");
    return 0;
  }

  if (dlinfo(dlopen(path, RTLD_NOW), RTLD_DI_LOADED_LIBRARY, &info) != 0) {
      perror("dlinfo failed");
      return 0;
  }

  // Add hash/signature verification here.
  printf("Library loaded from: %sn", info.dli_fname);
  dlclose(dlopen(path, RTLD_NOW));
  return 1;
}
  4. Address Space Layout Randomization (ASLR): iOS uses ASLR to randomize the memory addresses of libraries and other components. This makes it harder for attackers to predict where dylibs are loaded.
  5. Sandboxing: Ensure your app’s sandbox is properly configured and that you aren’t granting unnecessary permissions.
  6. Regular Security Audits: Conduct regular security audits of your code, dependencies, and configuration to identify potential vulnerabilities.

Tools for Detection

Exit mobile version