Skip to content

Latest commit

 

History

History
101 lines (79 loc) · 9.39 KB

mitigations.md

File metadata and controls

101 lines (79 loc) · 9.39 KB

Mitigation Strategies Analysis for nst/ios-runtime-headers

Mitigation Strategy: Abstraction and Indirection (Header-Specific)

Mitigation Strategy: Isolate and encapsulate all interactions derived from ios-runtime-headers within a dedicated abstraction layer.

Description:

  1. Dedicated Module: Create a separate Swift module or Objective-C class (e.g., PrivateAPIBridge.swift or PrivateAPIBridge.m/.h) that exclusively handles all interactions originating from the ios-runtime-headers. This is your single point of contact with the "private" world.
  2. Header Import Isolation: The ios-runtime-headers should only be imported within this dedicated module. No other part of your application should directly include these headers. This is crucial for containment.
  3. Type Safety (Swift): If using Swift, define strong types (structs, enums, classes) that mirror the structures and data types exposed by the private APIs you're using. This avoids using Any or id and provides compile-time safety. These types should be internal to the PrivateAPIBridge module.
  4. Selector Handling (Objective-C): If using Objective-C, use @selector() to obtain selectors for private methods. Store these selectors as properties within the PrivateAPIBridge class, rather than constructing them repeatedly.
  5. Public API Facade: The PrivateAPIBridge should expose a public API that does not reveal any details about the underlying private APIs. Use descriptive method names and parameter types that reflect the functionality being provided, not the implementation details.
  6. Conditional Compilation: Use #if DEBUG ... #endif (or similar preprocessor directives) to conditionally include or exclude the entire PrivateAPIBridge module, or specific parts of it, based on the build configuration. This allows you to easily create builds that completely avoid using private APIs.

Threats Mitigated: * Reliance on Undocumented APIs (High Severity): Centralizes all private API access, making it much easier to update or replace calls if the underlying APIs change. * Increased Attack Surface (Medium Severity): Limits the exposure of private API interactions to a single, well-defined, and auditable location. * Dynamic Analysis Facilitation (Medium Severity): Makes it slightly harder for attackers to understand the full scope of private API usage, as the direct calls are hidden behind the abstraction. * App Store Rejection (High Severity): Facilitates easier removal or conditional compilation of private API usage for App Store submissions.

Impact: * Reliance on Undocumented APIs: Risk significantly reduced (e.g., 70%). * Increased Attack Surface: Risk moderately reduced (e.g., 40%). * Dynamic Analysis Facilitation: Risk slightly reduced (e.g., 20%). * App Store Rejection: Risk moderately reduced (e.g., 50%).

Currently Implemented: Partially. A wrapper class exists for some private API calls, but not all. Header imports are not strictly isolated. Conditional compilation is used sporadically.

Missing Implementation: * Strict isolation of ios-runtime-headers imports to the dedicated module. * Consistent use of the wrapper for all private API interactions. * Definition of strong types (in Swift) to represent private API data structures. * More comprehensive and consistent use of conditional compilation.

Mitigation Strategy: Obfuscation of Private API Identifiers (Header-Specific)

Mitigation Strategy: Obfuscate the strings representing class names, method names (selectors), and protocol names obtained from ios-runtime-headers.

Description:

  1. Inventory: Create a comprehensive list of all class names, method names (selectors), and protocol names that your application uses and that are derived from the ios-runtime-headers. This is your target list for obfuscation.
  2. String Encryption: Encrypt these strings at compile time using a strong encryption algorithm (e.g., AES-256). Generate a unique, random key for each build.
  3. Secure Key Storage: Store the decryption key securely. Do not hardcode the key directly in the source code. Consider using:
    • A build script that generates the key and injects it into the code during compilation.
    • A separate, obfuscated configuration file that is loaded at runtime.
    • (Advanced) A hardware-backed secure enclave (if available and appropriate for your security needs).
  4. Runtime Decryption: Decrypt the strings only when they are needed, immediately before being used to interact with the private API (e.g., before calling NSClassFromString() or sel_registerName()).
  5. Memory Management: After using the decrypted string, immediately overwrite the memory containing the decrypted string with zeros or random data to prevent it from lingering in memory. Use memset or similar functions for this.
  6. Avoid Caching: Do not cache the decrypted strings. Decrypt them fresh each time they are needed.

Threats Mitigated: * Dynamic Analysis Facilitation (Medium Severity): Makes it significantly harder for attackers to identify the specific private APIs being used by analyzing the application binary or memory dumps. * Increased Attack Surface (Medium Severity): Reduces the likelihood of attackers crafting exploits based on readily available information about private API usage gleaned from the headers.

Impact: * Dynamic Analysis Facilitation: Risk significantly reduced (e.g., 70%). * Increased Attack Surface: Risk moderately reduced (e.g., 40%).

Currently Implemented: Not implemented. Private API identifiers are used directly as string literals.

Missing Implementation: * Implementation of string encryption for all private API identifiers (class names, selectors, protocol names). * Secure key generation and storage mechanism. * Runtime decryption logic within the PrivateAPIBridge. * Strict memory management to prevent decrypted strings from lingering in memory.

Mitigation Strategy: Runtime Validation of Private API Interactions (Header-Specific)

Mitigation Strategy: Rigorously validate all input and output associated with calls to private APIs discovered through ios-runtime-headers.

Description:

  1. Input Validation (Pre-Call): Before calling any private API (identified through the headers), meticulously validate all input parameters. This includes:
    • Type Checking: Ensure that all parameters are of the expected data types (using isKindOfClass: in Objective-C or type checks in Swift).
    • Range Checking: If parameters have expected ranges (e.g., numerical values, array indices), verify that they fall within those ranges.
    • Null/Nil Checks: Check for NULL (Objective-C) or nil (Swift) pointers where appropriate.
    • Content Validation: If parameters are strings or data buffers, validate their contents to prevent injection attacks or buffer overflows. This might involve checking for specific patterns, lengths, or allowed characters.
  2. Output Validation (Post-Call): After calling a private API, validate the return value and any output parameters (passed by reference). This includes:
    • Type Checking: Verify that the return value and output parameters are of the expected data types.
    • Error Checking: Check for error codes or status indicators that might indicate failure. Private APIs may have undocumented error conditions.
    • Range/Content Validation: Similar to input validation, check the ranges and contents of output parameters to ensure they are valid and safe.
  3. Defensive Programming: Assume that private APIs may behave unexpectedly or have undocumented vulnerabilities. Write your code defensively to handle potential errors or unexpected results.
  4. Error Handling: Implement robust error handling within the PrivateAPIBridge. If any validation check fails, or if the private API call returns an error, handle the error gracefully. This might involve:
    • Logging the error.
    • Returning a default value.
    • Switching to a fallback mechanism (if available).
    • Notifying the user (if appropriate).

Threats Mitigated: * Increased Attack Surface (Medium Severity): Helps prevent attackers from exploiting vulnerabilities in private APIs by providing invalid input or manipulating the output. * Reliance on Undocumented APIs (High Severity): Mitigates the impact of unexpected behavior or undocumented error conditions in private APIs.

Impact: * Increased Attack Surface: Risk moderately reduced (e.g., 50%). * Reliance on Undocumented APIs: Risk moderately reduced (e.g., 40%).

Currently Implemented: Basic input validation is performed for some private API calls, but output validation is largely absent. Error handling is inconsistent.

Missing Implementation: * Comprehensive input and output validation for all private API calls. * Consistent and robust error handling within the PrivateAPIBridge. * Defensive programming practices to handle unexpected API behavior.