CEH Vulnerability Analysis and System Hacking Practice Question

Answer analysis

Option-by-option breakdown

For each option: why learners choose it and why it is or isn't the right answer here.

• ✓

  Update Log4j to version 2.17.1 or later

  Why this is correct

  Updating Log4j to version 2.17.1 or later directly addresses the Log4Shell vulnerabilities (CVE-2021-44228, CVE-2021-45046, CVE-2021-45105) by completely disabling JNDI lookups by default. This version ensures that untrusted input can no longer trigger remote code execution (RCE) via LDAP, RMI, or other JNDI-enabled services. Applying this patch is the most comprehensive and recommended solution, as it eliminates the underlying flaw rather than merely mitigating symptoms. It ensures the application's logging functionality remains secure and fully operational.

• ✗

  Remove the JndiLookup class from the Log4j jar

  Why it's wrong here

  Removing the JndiLookup class from the Log4j JAR file (e.g., log4j-core-*.jar) is a manual workaround that directly eliminates the vulnerable component responsible for JNDI lookups. While effective in preventing exploitation of CVE-2021-44228, it is considered a mitigation rather than a proper patch. This approach requires careful execution to avoid corrupting the library and might not be easily reversible or maintainable across multiple deployments, making a full version update the superior long-term solution.

• ✗

  Disable JDBC appender in Log4j configuration

  Why it's wrong here

  Disabling the JDBC appender in Log4j configuration only prevents potential exploitation scenarios where malicious input could interact with database connections via JNDI. However, the Log4Shell vulnerability (CVE-2021-44228) is far broader, primarily leveraging LDAP and other JNDI-enabled services for remote code execution. This action leaves numerous other attack vectors open, such as those involving RMI, DNS, or other custom JNDI resource lookups, rendering it an incomplete and ineffective mitigation strategy for the core vulnerability.

• ✗

  Block outbound traffic from the server to the internet

  Why it's wrong here

  Blocking outbound traffic from the server to the internet is a temporary network-level mitigation that can prevent the vulnerable Log4j instance from fetching malicious payloads from external LDAP or RMI servers. While this can disrupt the final stage of a Log4Shell attack, it does not address the underlying vulnerability within the Log4j library itself. The server remains exploitable internally or if an attacker can establish an internal malicious server, making it an insufficient long-term solution that merely contains, rather than resolves, the risk.

Go deeper

Related to this question