Introduction
Maybe Log4j vulnerabilities are like cockroaches. For every one that’s visible, multiple others exist beneath the surface. It’s too early to tell if that’s the case with Log4j. Just a day ago, on December 14, 2021, after a damaging vulnerability disclosure (Log4j / CVE-2021-44228) that was covered by Logstail in a previous post, another has come to light.
The new Log4j vulnerability is officially CVE-2021-45046 (CVE number is the unique number given to each vulnerability discovered) and is rated 3.7 out of 10 (3.7/10) on the CVSS rating system. It affects all versions of Log4j from 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0, which the project maintainers shipped last week to address a critical remote code execution vulnerability (CVE-2021-44228) that could be deflected or violated in order to transude and take over multiple systems.
Due to the wide usage of Log4j, the vulnerabilities may affect a wide range of software and services from many major and well-known vendors.
The fix to address CVE-2021-44228 in Apache Log4j 2.15.0 found out to be incomplete in certain non-default configurations.
“This could allow attackers to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack,” the CVE description comments.
According to cve.mitre.org announcement, the mitigations involving configuration of the System property log4j2.noFormatMsgLookup does not mitigate the specific vulnerability. This issue can be mitigated by removing the JNDI Lookup class from the classpath.
Mitigation Strategies for Opendistro’s Elasticsearch and Opensearch
It is strongly recommended to upgrade to the latest version if possible.
For those who can not upgrade to the latest version, the mitigation strategy tested by Logstail team and recommended for those interested, is the following:
1. Determine if using a vulnerable Log4j version, by running the following command in elasticsearch path:
find . -name “*log4j*core*.jar”
2. Run the following command to inspect the jar and locate the path of the JndiLookup class:
jar tf <path-to-log4j.jar> | grep -i jndi
(In the screenshot above, the highlighted class is suggested to be removed.)
3. Remove the class from the jar
zip -q -d <path-to-log4j.jar> <path-to-JndiLookup.class>
4. Validate that the class was removed by running again the command in step 2.
5. Restart Elasticsearch.
Conclusion
Two critical vulnerabilities came up to light only a few days apart, one following the other. It is very important to take all applicable measures and mitigation actions as soon as possible. This fact proves that it is now more critical than ever to secure systems and applications. Cyber attack incidents keep rising with the evolution of technology, and more attack techniques keep evolving and developed. All organizations with sensitive information, no matter the size need to re-evaluate their cybersecurity strategies.
Our cloud-hosted solution with advanced features brings the functionality of centralized monitoring to your hands. Convert your data into actionable insights and maximize the performance of your infrastructure. Get notified of potential problems and take the appropriate actions. Sign-up for a free demo in order to realize the power of Logstail!
Logstail will re-adjust the way you monitor your data and will help you get more meaningful insights of your technical or security logs, via prebuild dashboards and powerful graphs, and become always aware of all possible security issues.
In Logstail we are also offering the full range of services required to effectively mitigate cyber-attacks. Incident response and consulting, penetration testing, and red team operations, are altogether aiming to help our customers mitigate their cyber incidents. Contact us at sales@logstail.com. Get a tailored offer for your business or get a free consultation by our team of globally recognized security experts!
Contact Our Expertsor Sign Up for Free
