At the beginning of this month, a vulnerability description published on the official website of Log4j caused an uproar among various Internet companies. All major companies were upgrading and repairing overnight. After all, it was one of the few serious accidents that I have personally experienced since I entered the industry, so I will simply record it:
Vulnerability Description
On December 6, 2021, there is a remote command execution vulnerability in the Apache Log4j2 Java log module, which can directly control the target server, making it extremely difficult for attackers to attack.
Because some functions of Apache Log4j2 have recursive parsing capabilities, attackers can directly construct malicious requests to trigger remote code execution vulnerabilities. The vulnerability can be triggered by log levels such as critical, error, warning, notice, info, debug, etc. Only some log contents are controllable. This vulnerability affects a large number of open source components, including ELK, Apache, Struts2, Apache Solr, Apache Druid, Apache Flink are affected. At present, the details of the vulnerability have been made public, and attackers can use the vulnerability to perform remote command execution.
The details of the Apache Log4j2 remote code execution vulnerability have been disclosed, and after analysis, the Apache Log4j remote code execution vulnerability is due to the Java JNDI injection vulnerability in the component. When the program logs the data entered by the user, the attacker triggers the remote code execution vulnerability in Apache Log4j2 by constructing a special request, thereby exploiting this vulnerability to execute arbitrary code on the target server.
It is reported that the Apache Log4j2 remote code execution vulnerability risk has been rated as "high risk" by the industry, and the vulnerability is very harmful and the threshold for exploitation is extremely low. According to reports, many components and large-scale applications such as Apache Solr, Apache Struts2, Apache Druid, and Apache Flink have been affected, and defensive measures must be taken as soon as possible.
Vulnerability Brief
Log4j versions prior to 2.15.0 have a remote code execution vulnerability through the ldap JNDI parser. According to Apache's Log4j Security Guide: Apache Log4j2 <= 2.14.1 JNDI features used in configuration, log messages, and parameters do not prevent attacker-controlled LDAP and other JNDI-related endpoints. When message lookup and replacement is enabled, an attacker who can control the log message or log message parameters can execute arbitrary code loaded from the LDAP server. As of log4j 2.15.0, this behavior is disabled by default.
Affected version
Any Log4J version prior to 2.15.0 is affected by this specific issue.
The v1 branch of Log4J is considered end-of-life (EOL) and it is vulnerable to other RCE vectors, so it is still recommended to update to 2.15.0 if possible.
influence
Logging untrusted or user-controlled data with a vulnerable version of Log4J could result in Remote Code Execution (RCE) against our application. This includes untrusted data contained in logged errors, such as exception traces, authentication failures, and other unexpected vectors of user-controlled input.
solution
This problem has been fixed in Log4J v2.15.0, it is strongly recommended to upgrade to the latest official version.
At present, Apache Log4j has released a new version to fix the vulnerability. Affected users are requested to upgrade all related applications of Apache Log4j2 to the latest Log4j-2.15.0 version, and upgrade known affected applications and components, such as srping-boot-strater-log4j2, Apache Solr, Apache Flink, Apache Druid, etc.
The Apache Log Service team also offers the following mitigation recommendations as a temporary solution:
- In previous versions (>=2.10) this behavior could be mitigated by setting the system property "log4j2.formatMsgNoLookups" to "true" or removing the JndiLookup class from the classpath (eg: zip -q -d log4j-core- *.jar org/apache/logging/log4j/core/lookup/JndiLookup.class);
- Java 8u121 prevents RCE by defaulting "com.sun.jndi.rmi.object.trustURLCodebase" and "com.sun.jndi.cosnaming.object.trustURLCodebase" to "false";
-
If Log4J cannot be upgraded, make sure that both are set on both the client and server side components:
-Dlog4j2.formatMsgNoLookups=true system property.