LOG4J 2 VULNERABILITY IMPACT ON MICROSOFT 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 Response to Apache Log4j Security Vulnerabilities
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 partiesif we identify any impact to customer data.
Apply the Latest Security Patches
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:
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.0or 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.
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:
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 Background
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 Vulnerabilities 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.
Log4j Mitigation for Microsoft Products & Services
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’sSecurity 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 partiesif they identify any impact to customer data.