Overview

The Log4Shell vulnerability CVE-2021-44228 is critical in the Apache Log4j 2 library that allows remote code execution by logging a specially crafted request. Addressing this vulnerability requires a thorough approach. Here's a technical checklist to help you ensure that your systems are protected against the Log4Shell vulnerability:

Mitigation

Identify Vulnerable Systems

Use vulnerability scanners and software composition analysis tools to identify systems and applications that use Log4j 2.x.

# Manual approach
find / -name 'log4j-core*.jar'

Review application dependencies in build files (like pom.xml for Maven, build.gradle for Gradle) for Log4j 2.x references.

// For Maven: 
mvn dependency:tree

// For Gradle: 
gradle dependencies

Check for Log4j 2.x libraries in your application servers, web servers, and other environments where Java applications are deployed.

Update or Mitigate

Update Log4j: Upgrade to Log4j version 2.17.1 or newer, as these versions contain fixes for the Log4Shell vulnerability and other subsequent vulnerabilities discovered in Log4j. Tools like Renovate, Dependabot, or Snyk can help automatically create pull requests to update dependencies.

Temporary Mitigation: If an immediate update is not possible, remove the JndiLookup class from the classpath:

zip -q -d path/to/log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

For environments where updating is not immediately feasible, apply environment-specific mitigations as vendors recommend.

For Log4j versions 2.10 to 2.14.1, set the system property log4j2.formatMsgNoLookups to true or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.

In cases where updating Log4j is not immediately feasible, use JVM options to enforce the removal of the vulnerable class:

-Dlog4j2.formatMsgNoLookups=true
-Dlog4j.configurationFile=/path/to/custom/log4j2.xml

Environment Hardening

Limit outbound connections: Where possible, limit outbound connections from servers to prevent them from making LDAP/RMI requests to attacker-controlled servers.

Implement egress filtering: Use firewalls or other network filtering tools to block unauthorized outbound connections, especially to the LDAP, RMI, and other protocols often exploited by Log4Shell.

Use Web Application Firewalls (WAFs): Deploy rules to detect and block Log4Shell exploitation attempts.

Audit and Monitoring

Enable detailed logging: Ensure that detailed logging is enabled for web applications and network devices to help detect exploitation attempts.

Tools like Elasticsearch, Logstash, and Kibana (ELK) or Splunk can be configured to alert on patterns indicative of exploitation attempts, such as unexpected external LDAP/RMI requests or the presence of ${jndi:ldap:// strings in logs.

Monitor logs: Regularly review logs for indications of Log4Shell exploitation attempts, such as unusual outbound network traffic or unexpected application behavior.

Audit system configurations: Regularly audit your systems and applications to ensure they remain secure against this and other vulnerabilities.

Incident Preparedness

Develop a response plan: Ensure you have an incident response plan that includes steps for dealing with Log4Shell and other critical vulnerabilities.

Educate stakeholders: Make sure that developers, system administrators, and security teams know the vulnerability and its potential impact.

Additional Considerations

Check third-party services: Ensure that any third-party services, APIs, or libraries your applications interact with are not vulnerable or have been patched.

Vendor communication: Communicate with your vendors to ensure they know and have mitigated any potential exposure to Log4Shell.

Completing this checklist can significantly reduce the risk of exploitation via the Log4Shell vulnerability in your environment. Remember, the threat landscape continually evolves, so staying informed about new vulnerabilities and patches is crucial.

CVE-2021-44228: Log4Shell