Contents
- Affected Version
- Affected Software
- Use JVM Flags - for a handful of applications for mitigating
- How to Check and Fix log4j2 Vulnerability?
- Steps to Check for Vulnerable Path
CVE-2021-44228 is the name of the zero-day vulnerability, which can affect any program that logs user input. The effect may be seen in a variety of places, including Minecraft, which registers the names of users who log in to the server. Remote users can alter their username to an OGNL expression, which makes the code run on the systems of other participants.
We are bringing your kind attention that significant Zero-Day problems are populating and attacking most of the enterprise core applications, as Apache servers are may widely used in your enterprise systems and web apps. Several services, including Minecraft Java Edition, are affected by this attack. This vulnerability increases the risk of your machine is being compromised. An attacker just needs to deliver a malicious code string that is finally logged by Log4j version 2.0 or higher to exploit the flaw. An attacker can use the exploit to acquire control of a server by loading arbitrary Java code.
Affected Version
- Apache Log4j 2.x <= 2.15.0-rc1
- Any Log4J version prior to v2.15.0 is affected by this specific issue.
Affected Software
This exploit is vulnerable to a large number of Java-based applications that use log4j as their logging function. At least the following software, to the best of our knowledge, maybe affected: Please identify any vulnerable servers and begin rolling out the patches as soon as possible.
- Apache Struts
- Apache Solr
- Apache Druid
- Apache Flink
- ElasticSearch
- Flume
- Apache Dubbo
- Logstash
- Kafka
- Spring-Boot-starter-log4j2 etc
Use JVM Flags - for a handful of applications for mitigating
For fine-grained control, JVM flags can be used to regulate program behavior. They have the advantage of guiding the application (which must be restarted), but the disadvantage is that you must know where and when to apply each flag.
- Please continue to work on upgrading your library if you choose this option. Use temporary mitigation while you plan your upgrade (both require application restarts):
- Log4j2 2.10 and up has a system property -Dlog4j2.formatMsgNoLookups=true
- Remove the JNDI class entirely:
zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
- Set a JDK system property
- -Dcom.sun.jndi.rmiobject.trustURLCodebase=false
- -Dcom.sun.jndi.cosnaming.object.trustURLCodebase=false
- JDK 8u121 sets both these properties correctly. If you are under 8u121 you must set these properties yourself, and setting them to false no matter what will work and is fine.
How to Check and Fix log4j2 Vulnerability?
log4j2-scan is a single binary command-line tool for CVE-2021-44228 vulnerability scanning and mitigation patch. It also supports nested JAR file scanning and patch.
- Windows:
- Linux:
- Any OS
Steps to Check for Vulnerable Path:
Steps to Check:
1. Download the file and extract it
2. Just run log4j2-scan.exe or log4j2-scan with the target directory path.
Note: run the program without [--fix] argument to just scan whether the system or server is vulnerable.
- On Windows
- log4j2-scan [--fix] target_path (use C: , D: to check the entire server for the vulnerability)
- On Linux
- ./log4j2-scan [--fix] target_path (use / to check the entire server for the vulnerability)
- On UNIX (AIX, Solaris, and so on)
- java -jar logpresso-log4j2-scan-1.2.2.jar [--fix] [--trace] target_path
If you add the --fix option, this program will copy the vulnerable original JAR file to the .bak file, and create a new JAR file without org/apache/logging/log4j/core/lookup/JndiLookup.class entry. In most environments, the JNDI lookup feature will not be used.
However, you must use this option at your own risk. It is necessary to shut down any running JVM process before applying the patch. Start affected JVM process after the fix.