Optimizing your resilience against Log4Shell

As more information continues to unravel about the nature and characteristics of the Log4Shell vulnerability, it is clear that coping with this vulnerability is a complex task, and upgrading Log4j across your entire ecosystem is far from trivial. Defenders are therefore required to implement measures across multiple verticals — Prevention, Mitigation, Assessment and Detection — in order to optimize their posture in relation to the Log4Shell scenario.

Below is a list of actionable measures we’ve compiled — spanning across all 4 verticals— that can assist you in optimizing your resilience against this vulnerability:

Prevent

Upgrade version of all log4j packages to 2.15.0 — https://logging.apache.org/log4j/2.x/security.html

Mitigate

While the different mitigations may not provide a full-proof solution for the vulnerability, they are easier to implement and significantly reduce the attack surface, and therefore recommended as temporary measures until all relevant log4j packages are upgraded.

1. Mitigations in Java configuration:

• In Log4j releases >=2.10, the vulnerability can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
• For releases >=2.7 and <=2.14.1, all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m.
• For releases >=2.0-beta9 and <=2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
• AWS have released a hotpatch that is to hotpatch a running JVM using any Log4j 2.0+.

2. Server hardening:

• Restrict egress access (LDAP/HTTP/HTTPS/DNS) from all relevant servers to prevent the malicious user-controlled payload from being able to communicate with the attacker’s servers and download malicious code.

3. WAF:

• General recommendation is to add a rule to your WAF searching and blocking “jndi:ldap://” for any input from the outside world.
• Many of the WAF vendors have updated their rulesets with specific detections for Log4Shell. Make sure to follow and implement the WAF-specific recommendations.

Detect

Your attack surface consists of a combination of your organic assets and assets which exist in 3rd parties you’ve implemented inside your environment, therefore detection efforts should focus on both:

Organic assets — Search for usage of Log4j within your codebase (log4j-api and log4j-core) by looking at the following artifacts –

• Pom.xml and other Java package manager files (ensure you inspect not only the root hierarchy — analysis should be done against the entire dependency tree)
• Search in your codebase for imports of log4j code by looking for the following string: “org.apache.logging.log4j” (for example, in Github — https://github.com/search?q=org:apache+org.apache.logging.log4j&type=code)

3rd parties — Assess the resilience of 3rd party products within your environment and follow vendor specific patching/mitigation recommendations. This resource contains many vendor specific bulletins around Log4Shell.

Assess/Investigate

Several measures exist to assess and validate whether your environment is vulnerable and/or if the mitigations implemented are effective:

1. IOCs / YARA signatures useful for detecting compromised assets –

• https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b
• https://github.com/Neo23x0/signature-base/blob/master/yara/expl_log4j_cve_2021_44228.yar

2. Nuclei Payload to detect whether your assets are exploitable:

Wget
https://raw.githubusercontent.com/numanturle/Log4jNuclei/main/log4j-detect.yaml
nuclei -c 200 -t log4j-detect.yaml -u $URL_YOU_WANT_TO_SCAN