Back
Log4j: Is My Organization Impacted?
Talk to any security professional and they’ll tell you that a vulnerability that allows for unauthenticated remote code execution is as about as critical as it gets. That’s exactly what CVE-2021-44228 allows.
On December 9, 2021, the severe Apache Log4j zero-day vulnerability was disclosed, along with its known exploits, creating a panic across the security community. The mere fact that a fix was put into place in a matter of hours of discovery is an indicator of how severe the vulnerability truly is. Given its severity, users are encouraged to take action immediately.
As teams scrambled to address CVE-2021-44228, a new vulnerability came about: CVE 2021-45046, as the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was deemed “incomplete in certain non-default configurations.” It causes Log4j2 Thread Context Message Pattern and Context Lookup Pattern to be vulnerable to a Denial of Service (DoS) attack.
…And then yet another surfaced overnight, CVE-2021-45105. The third Log4j vulnerability is very similar to the initial Log4Shell zero-day. Previous patches did not protect against uncontrolled recursion from self-referential lookups which could also result in a DoS attack.
Continue reading for details on the impact of these critical vulnerabilities, guidance to determine whether your organization is at risk of Log4j exploit, and mitigation recommendations.
What is the impact of the Log4Shell zero-day vulnerability?
The ubiquity of Log4j is the greatest concern. In just 24 hours, it has been reported that Apple iCloud, Twitter, Cloudflare, Minecraft, and Steam, identified the vulnerability in their systems.
Its impact is expected to spread even further given Log4j is widely used across enterprise applications, including mobile applications, thick client applications, web applications, desktop GUI applications, and other Java-based applications to record/log activities within an application.
If exploited, cybercriminals can take control of an affected system remotely.
Is my organization vulnerable?
The first step to threat mitigation is to understand Log4j’s presence in your organization. To answer the question “Which of my applications use Log4j?” NetSPI recommends:
- Searching code repositories for the following and setting them to the correct parameter value based on the CVE remediation
recommendation.- “log4j2.formatMsgNoLookups”
- “com.sun.jndi.rmi.object.trustURLCodebase”
- “com.sun.jndi.cosnaming.object.trustURLCodebase”
- Check your asset management database to see if you are running Apache Log4j2 versions ranging from 2.0 to 2.16 in your environment. If so, you are likely vulnerable and require an update, though there are some exceptions.
- Check for affected versions of log4j jar files on file systems to prioritize systems that require further analysis.
- If a software composition analysis (SCA) tool is being used, request the tool to develop a check for the vulnerability or create a custom check for the incorrect setting.
What can I do to protect my organization?
Review the Apache Log4j security vulnerability announcement and update to the appropriate version of Log4j 2. It is important to follow the mitigation steps outlined by Apache and continuously check in for additional vulnerable instances.
NetSPI also recommends organizations ensure their detection tools (Qualys, Nessus, Nexpose, etc.) produce checks for the vulnerability as this is likely to have lasting impacts.
If you have questions about the Log4j vulnerabilities or would like NetSPI to perform a targeted test for the vulnerability in your environment, please visit https://www.netspi.com/security-testing/apache-log4j-assessment.
