Microsoft continues our analysis of the remote code execution vulnerability (CVE-2021-44228) related to Apache Log4j (a logging tool used in many Java-based applications) disclosed on 9 Dec 2021. As we and the industry at large continue to gain a deeper understanding of the impact of this threat, we will publish technical information to help customers detect, investigate, and mitigate attacks, as well as guidance for using Microsoft security solutions to increase resilience against related attacks. We will update this blog with information and protection details as they become available.
In addition to monitoring the threat landscape for attacks and developing customer protections, our security teams have been analysing our products and services to understand where Apache Log4j may be used and are taking expedited steps to mitigate any instances. If we identify any customer impact, we will notify the affected party. Our investigation to date has identified mitigation steps customers could take in their environments as well as on our services.
To address this vulnerability, Microsoft recommends customers apply the latest security updates to remediate this vulnerability. Please review the Apache CVE and the Apache security advisory for further details:
All systems, including those that are not customer facing, are potentially vulnerable to this exploit, so backend systems and microservices should also be upgraded. The recommended action is to update Log4j 2 to 2.15.0. A service restart will be required.
To help mitigate the risk of this vulnerability until the more complete security update can be applied, customers should consider the following mitigations steps. A service restart will be required for these changes to take effect. These workarounds should not be considered a complete solution to resolve this vulnerability:
The vulnerability, tracked as CVE-2021-44228 and referred to as “Log4Shell,” affects Java-based applications that use Log4j 2 versions 2.0 through 2.14.1. Log4j 2 is a Java-based logging library that is widely used in business system development, included in various open-source libraries, and directly embedded in major software applications. The scope of impact has expanded to thousands of products and devices, including Apache products such as Struts 2, Solr, Druid, Flink, and Swift. Because this vulnerability is in a Java library, the cross-platform nature of Java means the vulnerability is exploitable on many platforms, including both Windows and Linux. As many Java-based applications can leverage Log4j 2, organizations should contact application vendors or ensure their Java applications are running the latest up-to-date version. Developers using Log4j 2 should ensure that they are incorporating the latest version of Log4j into their applications as soon as possible in order to protect users and organizations.
The vulnerability is a remote code execution vulnerability that can allow an unauthenticated attacker to gain complete access to a target system. It can be triggered when a specially crafted string is parsed and processed by the vulnerable Log4j 2 component. This could happen through any user provided input.
Successful exploitation allows for arbitrary code execution in the targeted application. Attackers do not need prior access to the system to log the string and can remotely cause the logging event by using commands like curl against a target system to log the malicious string in the application log. When processing the log, the vulnerable system reads the string and executes it, which in current attacks is used to execute the code from the malicious domain. Doing so can grant the attacker full access and control of the affected application.
Given the fact that logging code and functionalities in applications and services are typically designed to process a variety of external input data coming from upper layers and from many possible vectors, the biggest risk factor of this vulnerability is predicting whether an application has a viable attack vector path that will allow the malformed exploit string to reach the vulnerable Log4j 2 code and trigger the attack.
A common pattern of exploitation risk, for example, is a web application with code designed to process usernames, referrer, or user-agent strings in logs. These strings are provided as external input (e.g., a web app built with Apache Struts). An attacker can send a malformed username or set user-agent with the crafted exploit string hoping that this external input will be processed at some point by the vulnerable Log4j 2 code and trigger code execution.