On December 9, 2021, previously undisclosed zero-day vulnerability in Log4j CVE-2021-44228 was reported. It is categorized as critical. Up to 2.14.1, all current versions of log4j2 are vulnerable. This vulnerability can be fixed by upgrading to version 2.15.0 or later.
This logging mechanism is used by default in many Java application frameworks. Apache Struts 2, Apache Solr, and Apache Druid, for example, are all affected. Apart from them, Apache Log4j is utilized in a lot of Spring and Spring Boot apps, so make sure you check yours and upgrade them to the newest version.
Explaining the Log4Shell vulnerability
It's rated 10.0 CVSSv3 by the NVD (National Vulnerability Database), which is almost as severe as it gets. If successfully exploited on your infrastructure, attackers will be able to compromise the targeted server via an RCE (Remote Code Execution) attack. Because of the vulnerability's simplicity, your incident response team is likely to be involved with dealing with an attack.
The vulnerability is being actively abused in the wild, according to various reports, and it needs to be patched as soon as possible. For further information, see the Apache Log4j security advisory.
Is this something I'm Affected?
Log4j 2.x=2.14.1 is affected in all versions. The mitigation recommendations can be found in the remedial section below.
If you're using Log4j 1.x, this vulnerability only affects you if you're utilizing JMS Appenders. Double-check your log4j configuration files for the presence of the org.apache.log4j.net.JMSAppender class to see if you're utilizing this appender. However, as of August 2015, Log4j 1.x is no longer supported, and fixes are no longer accessible. It should be updated because it has its own set of remote code execution problems.
Even if your application does not directly utilize log4j, its surrounding infrastructure, such as the application server, message queue server, database server, and network devices, may employ the Java and log4j version that exposes you to this vulnerability.
Remediation
Download the most recent Log4j mitigated version 2.15.0 from the official website.
If you are unable to upgrade, please follow the instructions below:
This behavior can be prevented by setting the system property log4j2.formatMsgNoLookups or the environment variable LOG4J FORMAT MSG NO LOOKUPS to true if using log4j2.x version >=2.10 and 2.14.1.
If you're running versions >=2.0-beta9 and >=2.10.0, you can mitigate the problem by removing log4j's JndiLookup class from the JVM's classpath as follows:
zip -q -d log4j-core-*.jar vorg/apache/logging/log4j/core/lookup/JndiLookup.class
How CIGNEX can help you to address this Problem
CIGNEX is working with enterprises to help them understand, detect, assess, and reduce dangers to their applications. CIGNEX has been assisting clients in resolving and neutralizing threats and will continue to do so during this crisis.
CIGNEX can help information security team of any organization and do blocking of IOCs (Indicator of Compromise - MD5, SHA256, Domains, Email addresses) in their security tools.
CIGNEX is assisting a major telecom software company's Information Security team in this type of use case where we collect IOCs for any threats from different sources like then we validate it on VirusTotal after validation we block in client's different security tools.
Any firm that fears a security breach or wishes to upgrade their Log4j version can contact them for assistance. Contact us at info@cignex.com for vulnerability evaluation and remediation services.
