LOG4J 2 Vulnerability Impact on MSFT Enterprise Products & Services.

Microsoft continues their analysis of the remote code execution vulnerabilities related to Apache Log4j (a logging tool used in many Java-based applications) disclosed on December 9, 2021.

Initiatives: Microsoft Security | Information Security, Cybersecurity
Audience: CISO, CTO, CIO | IT Executives

Microsoft Log4j Vulnerability

Microsoft continues our analysis of the remote code execution vulnerabilities related to Apache Log4j (a logging tool used in many Java-based applications) disclosed on 9 Dec 2021. Currently, Microsoft is not aware of any impact, outside of the initial disclosure involving Minecraft: Java Edition, to the security of our enterprise services and has not experienced any degradation in availability of those services as a result of this vulnerability.

Our security teams have been analyzing our products and services to identify and mitigate any instances of CVE-2021-44228 and CVE-2021-45046 in Apache Log4j 2.

Affected Microsoft products requiring customer action have been released in our Security Update Guide – CVE-2021-44228. Customers are encouraged to apply these updates as quickly as possible. If you are using any Microsoft services other than those explicitly listed in the CVE, no action is required by you at this time. As we continue our investigation, we will notify affected parties if we identify any impact to customer data.

To address these vulnerabilities, Microsoft recommends customers apply the latest security updates. Please review the Apache CVEs and the Apache security advisory for further details:

• Apache Log4j 2.x CVEs: CVE-2021-44228 and CVE-2021-45046
• Apache security advisory: Apache Log4j Security Vulnerabilities

All systems, including those that are not internet facing, are potentially vulnerable to these vulnerabilities, so backend systems and microservices should also be upgraded.  No Java version can mitigate these vulnerabilities. The recommended action is to update Apache Log4j 2. An application restart will be required.

• Java 8 or newer: update Log4j to 2.16.0 or later
• Java 7: update to Log4j 2.12.2 or later

Systems that have already been updated to 2.15.0 should move to 2.16.0 or later as soon as possible for extra protection against other potential vulnerabilities described in CVE-2021-45046.

Systems running on Log4j 1.x are not impacted by these vulnerabilities. In 2015, Apache announced Log4j 1.x has reached end-of-life. Microsoft recommends customers to upgrade to Log4j 2.16.0 or later for the latest security updates.

• Apache Announcement: Log4j 1.x End of Life
• Apache Log4j 1.x vulnerability – 1.2 up to 1.2.17: CVE-2019-17571

To help mitigate the risk of these vulnerabilities in Log4j 2.x until the more complete security update can be applied, customers should consider the following mitigations steps for all releases of Log4j 2.x – except releases 2.16.0 or later and 2.12.2. These workarounds should not be considered a complete solution to resolve these vulnerabilities:

• For all releases of Log4j 2.x prior to 2.16.0, the most effective mitigation, besides a security update, is to prevent the JndiLookup.class file from being loaded in the applications’s classpath.
  • Customers can do this by deleting the class from affected JAR files. For example:
    $ zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
  • Log4j may also be present in other files as a bundle or as a shaded library. Microsoft advises customers to do an extensive search beyond log4j-core-*.jar files.
• In case the Log4j 2 vulnerable component cannot be updated, Log4j versions 2.10 to 2.14.1 support the parameter log4j2.formatMsgNoLookups to be set to ‘true’, to disable the vulnerable feature. Ensure this parameter is configured in the startup scripts of the Java Virtual Machine:
  -Dlog4j2.formatMsgNoLookups=true.
• Alternatively, customers using Log4j 2.10 to 2.14.1 may set the LOG4J_FORMAT_MSG_NO_LOOKUPS=”true” environment variable to force this change.
• Kubernetes administrators may use “kubectl set env” to set the LOG4J_FORMAT_MSG_NO_LOOKUPS=”true” environment variable to apply the mitigation across Kubernetes clusters where the Java applications are running Log4j 2.10 to 2.14.1, effectively reflecting on all pods and containers automatically.
• An application restart will be required for these changes to take effect.

Log4j Exploit Attacks in 2022

The vulnerabilities, tracked as CVE-2021-44228 and CVE-2021-45046 and referred to as “Log4Shell,” affects Java-based applications that use Log4j 2 versions 2.0 through 2.15.0. 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, Swift, Karaf, and others.

Because these vulnerabilities are in a Java library, the cross-platform nature of Java means the vulnerabilities are exploitable on many platforms, including Windows, macOS, and Linux. As many Java-based applications can leverage Log4j 2 directly or indirectly, 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 to protect users and organizations.

Log4j Exploit Top Attacking Web Clients in 2022

Microsoft Log4j2 Exploit Analysis

The vulnerabilities allow remote code execution by 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 these vulnerabilities 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 application 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.

Microsoft 365 Defender Protection for Log4j Vulnerability

After further analysis of MSFT services and products, below are a few mitigation strategies given by various Microsoft services.

The mitigation based on disabling message lookup functionality – through enabling the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS – does not cover all risks related to these vulnerabilities. Customers should still apply the latest security updates or apply other documented mitigation steps such as the removal of the JndiLookup.class file from the application classpath.

Affected Microsoft products requiring customer action have been released in Microsoft’s Security Update Guide – CVE-2021-44228. MSFT enterprise customers are encouraged to apply these updates as quickly as possible.

If you are using any Microsoft services other than those explicitly listed in the CVE, no action is required by you at this time. As they continue their investigation, Microsoft will notify affected parties if they identify any impact to customer data.