Optimizing your resilience against Log4Shell
Collection of actionable measures — across Prevention, Mitigation, Detection and assessment — for coping with the Log4Shell chaos
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.
- 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:
- 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
