Atlassian uses cookies to improve your browsing experience, perform analytics and research, and conduct advertising. Accept all cookies to indicate that you agree to our use of cookies on your device. Atlassian cookies and tracking notice, (opens new window)
A high severity vulnerability (CVE-2021-44228) impacting multiple versions of the Apache Log4j 2 utility was disclosed publicly via the project’s GitHub on December 9, 2021. The vulnerability impacts Apache Log4j 2 versions 2.0 to 2.14.1.
The vulnerability allows for unauthenticated remote code execution. Log4j 2 is an open source Java logging library developed by the Apache Foundation. Log4j 2 is widely used in many applications and is present, as a dependency, in many services. These include enterprise applications as well as numerous cloud services.
The Randori Attack Team has developed a working exploit and has been able to successfully leverage this vulnerability in customer environments as part of our offensive security platform. The vulnerability is reachable via a multitude of application specific methods. Effectively, any scenario that allows a remote connection to supply arbitrary data that is written to log files by an application utilizing the Log4j library is susceptible to exploitation. This vulnerability is highly likely to be exploited in the wild and is likely to impact thousands of organizations. This vulnerability poses a significant real world risk to affected systems.
In analyzing CVE-2021-44228, Randori has determined the following:
Default installations of widely used enterprise software are vulnerable.
The vulnerability can be exploited reliably and without authentication.
The vulnerability affects multiple versions of Log4j 2.
The vulnerability allows for remote code execution as the user running the application that utilizes the library.
Impact
The Log4j 2 library is very frequently used in enterprise Java software. Due to this deployment methodology, the impact is difficult to quantify. Similarly to other high-profile vulnerabilities such as Heartbleed and Shellshock, we believe there will be an increasing number of vulnerable products discovered in the weeks to come. Due to the ease of exploitation and the breadth of applicability, we suspect ransomware actors to begin leveraging this vulnerability immediately.
Recommendation
If you believe you may be impacted by CVE-2021-44228, Randori encourages all organizations to adopt an assumed breach mentality and review logs for impacted applications for unusual activity. If anomalies are found, we encourage you to assume this is an active incident, that you have been compromised and respond accordingly.
Upgrading to the patched versions of Log4j 2 or impacted applications will eliminate this vulnerability. Randori recommends any organization that believes they may be impacted to update to a patched version urgently.
If patching is not possible, it is highly advised organizations apply the temporary mitigation below and monitor impacted applications closely for anomalous behavior.
To mitigate the vulnerability in place of updating Log4 2j, the following parameter should be set to true when starting the Java Virtual Machine:
Openfire makes use of the Log4j framwork, for which a vulnerability has been published. We should update/mitigate.
From https://www.randori.com/blog/cve-2021-44228/
A high severity vulnerability (CVE-2021-44228) impacting multiple versions of the Apache Log4j 2 utility was disclosed publicly via the project’s GitHub on December 9, 2021. The vulnerability impacts Apache Log4j 2 versions 2.0 to 2.14.1.
The vulnerability allows for unauthenticated remote code execution. Log4j 2 is an open source Java logging library developed by the Apache Foundation. Log4j 2 is widely used in many applications and is present, as a dependency, in many services. These include enterprise applications as well as numerous cloud services.
The Randori Attack Team has developed a working exploit and has been able to successfully leverage this vulnerability in customer environments as part of our offensive security platform. The vulnerability is reachable via a multitude of application specific methods. Effectively, any scenario that allows a remote connection to supply arbitrary data that is written to log files by an application utilizing the Log4j library is susceptible to exploitation. This vulnerability is highly likely to be exploited in the wild and is likely to impact thousands of organizations. This vulnerability poses a significant real world risk to affected systems.
In analyzing CVE-2021-44228, Randori has determined the following:
Default installations of widely used enterprise software are vulnerable.
The vulnerability can be exploited reliably and without authentication.
The vulnerability affects multiple versions of Log4j 2.
The vulnerability allows for remote code execution as the user running the application that utilizes the library.
Impact
The Log4j 2 library is very frequently used in enterprise Java software. Due to this deployment methodology, the impact is difficult to quantify. Similarly to other high-profile vulnerabilities such as Heartbleed and Shellshock, we believe there will be an increasing number of vulnerable products discovered in the weeks to come. Due to the ease of exploitation and the breadth of applicability, we suspect ransomware actors to begin leveraging this vulnerability immediately.
Recommendation
If you believe you may be impacted by CVE-2021-44228, Randori encourages all organizations to adopt an assumed breach mentality and review logs for impacted applications for unusual activity. If anomalies are found, we encourage you to assume this is an active incident, that you have been compromised and respond accordingly.
Upgrading to the patched versions of Log4j 2 or impacted applications will eliminate this vulnerability. Randori recommends any organization that believes they may be impacted to update to a patched version urgently.
If patching is not possible, it is highly advised organizations apply the temporary mitigation below and monitor impacted applications closely for anomalous behavior.
To mitigate the vulnerability in place of updating Log4 2j, the following parameter should be set to true when starting the Java Virtual Machine:
log4j2.formatMsgNoLookupsFurther Information
[1] https://news.ycombinator.com/item?id=29504755
[2] https://github.com/apache/logging-log4j2/pull/608