Log4j explanation and Microsoft services (Mostly)

New Blog Post | Microsoft's Response to CVE-2021-44228 Apache Log4j 2 -  Microsoft Tech Community

You don’t every day see a CVE with the amount of 10/10, but now the day came and in the form of Log4j and LogShell / LogJam vulnerability.

What is log4j?

log4j is a reliable, fast and flexible logging framework (APIs) written in Java, which is distributed under the Apache Software License.

log4j has been ported to the C, C++, C#, Perl, Python, Ruby, and Eiffel languages.

log4j is highly configurable through external configuration files at runtime. It views the logging process in terms of levels of priorities and offers mechanisms to direct logging information to a great variety of destinations, such as a database, file, console, UNIX Syslog, etc.

log4j has three main components:

  • loggers: Responsible for capturing logging information.
  • appenders: Responsible for publishing logging information to various preferred destinations.
  • layouts: Responsible for formatting logging information in different styles.

How does it work?

Log4j is an open source logging framework that allows software developers to log various data within their application. This data can also include user input. It is used ubiquitously in Java applications, especially enterprise software

log4j Architecture
LevelDescription
OFFThe highest possible rank and is intended to turn off logging.
FATALSevere errors that cause premature termination. Expect these to be immediately visible on a status console.
ERROROther runtime errors or unexpected conditions. Expect these to be immediately visible on a status console.
WARNUse of deprecated APIs, poor use of API, ‘almost’ errors, other runtime situations that are undesirable or unexpected, but not necessarily “wrong”. Expect these to be immediately visible on a status console.
INFOInteresting runtime events (startup/shutdown). Expect these to be immediately visible on a console, so be conservative and keep to a minimum.
DEBUGDetailed information on the flow through the system. Expect these to be written to logs only. Generally speaking, most lines logged by your application should be written as DEBUG.
TRACEMost detailed information. Expect these to be written to logs only. Since version 1.2.12.[14]

List of possible vulnerable devices and software


National Cyber Security Centrum (NCSC-NL) has release a really comprehensive list here

Mitigation

How to mitigate or prevent with Microsoft services?

Microsoft 365 Defender

Turn on cloud-delivered protection in Microsoft Defender Antivirus to cover rapidly evolving attacker tools and techniques. Cloud-based machine learning protections block the majority of new and unknown variants. Microsoft Defender Antivirus detects components and behaviors related to this threat as the following detection names:

On Windows:

On Linux:

Users of Microsoft Defender for Endpoint can turn on the following attack surface reduction rule to block or audit some observed activity associated with this threat.

  • Block executable files from running unless they meet a prevalence, age, or trusted list criterion

Due to the broad network exploitation nature of vectors through which this vulnerability can be exploited and the fact that applying mitigations holistically across large environments will take time, we encourage defenders to look for signs of post-exploitation rather than fully relying on prevention. Observed post exploitation activity such as coin mining, lateral movement, and Cobalt Strike are detected with behavior-based detections.

Alerts with the following titles in the Security Center can indicate threat activity related to exploitation of CVE-2021-44228 on your network. Alerts that support both Windows and Linux platforms are indicated below:

  • Network connection seen in CVE-2021-44228 exploitation (detects network traffic connecting to an address associated with CVE-2021-44228 scanning or exploitation activity)
  • Possible exploitation of CVE-2021-44228 (detects coin miners, shells, backdoor, and payloads such as Cobalt Strike used by attackers post-exploitation)
  • Possible Log4j exploitation (detects multiple behaviors, including suspicious command launch post-exploitation)
  • Suspicious script launched

Alerts with the following titles in the Security Center can indicate threat activity on your network but may not necessarily be related to related to exploitation of CVE-2021-44228. We are listing them here as well as these generic behavioral alerts can also trigger in customer environments and it is also highly recommended that they are triaged and remediated immediately:

  • Suspicious remote PowerShell execution
  • Download of file associated with digital currency mining
  • Process associated with digital currency mining
  • Cobalt Strike command and control detected
  • Suspicious network traffic connection to C2 Server
  • Ongoing hands-on-keyboard attacker activity detected (Cobalt Strike)

Azure AD

Azure Web Application Firewall (WAF)

In response to this threat, Azure Web Application Firewall (WAF) has updated Default Rule Set (DRS) versions 1.0 and 1.1, which are available for Azure Front Door global deployments. We have updated rule 944240 “Remote Command Execution” under Managed Rules to help in detecting and mitigating this vulnerability by inspecting requests’ headers, URI, and body. This rule is already enabled by default in block mode for all existing WAF Default Rule Set configurations. Customers using WAF Managed Rules would have already received enhanced protection for the Log4j2 vulnerability (CVE-2021-44228), no additional action is needed.

Recommendation: Customers are recommended to enable WAF policy with Default Rule Set 1.0/1.1 on their Front Door deployments to immediately avail of additional protection from this threat, if not already enabled. For customers who have already enabled DRS 1.0/1.1, no action is needed. We will continue to monitor threat patterns and modify the above rule in response to emerging attack patterns as required.

Note: Above protection is also available on Default Rule Set version 2.0, which is available under preview on Azure Front Door Premium. Customers using Azure CDN Standard from Microsoft can also avail of the above protection by enabling DRS 1.0.

Azure Firewall Premium 

Customers using Azure Firewall Premium have enhanced protection from the Log4j RCE CVE-2021-44228 vulnerability and exploit. Azure Firewall premium IDPS (Intrusion Detection and Prevention System) provides IDPS inspection for all east-west traffic and outbound traffic to internet. The vulnerability rulesets are continuously updated and include CVE-2021-44228 vulnerability for different scenarios including UDP, TCP, HTTP/S protocols since December 10th, 2021. Below screenshot shows all the scenarios which are actively mitigated by Azure Firewall Premium.

Recommendation: Customers are recommended to configure Azure Firewall Premium with both IDPS Alert & Deny mode and TLS inspection enabled for proactive protection against CVE-2021-44228 exploit.  

Screenshot of Azure Firewall Premium

Customers using Azure Firewall Standard can migrate to Premium by following these directions. Customers new to Azure Firewall premium can learn more about Firewall Premium.

Workarounds

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:

  • In case the Log4j 2 vulnerable component cannot be updated, Log4J 2 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.
  • For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

Information from Microsoft https://www.microsoft.com/security/blog/2021/12/11/guidance-for-preventing-detecting-and-hunting-for-cve-2021-44228-log4j-2-exploitation/

Microsoft statements about their services

Azure App Service (Windows and Linux)

Azure App Service and Functions does not distribute Log4J in the managed runtimes such as Tomcat, Java SE, JBoss EAP, or the Functions Runtime. However, your applications may use Log4J and be susceptible to this vulnerability.

Azure App Service for Containers

If you are deploying Linux or Windows containers to App Service, then you will need to set the system property in your container image. Most likely this will be in the entry point of your Dockerfile.

Azure Application Gateway, Azure Front Door, and Azure WAF 

In our investigation so far, we have not found any evidence that these services are vulnerable however customer applications running behind these services might be vulnerable to this exploit. We highly recommend customers to follow mitigations and workarounds mentioned in this blog to protect their applications. Additional guidance for Azure WAF is located here.

Azure Functions

Configuring the system property will depend on your choice of hosting option: dedicated, premium or consumption. As a reminder, the primary recommended mitigation is upgrading Log4J to 2.15.0 and re-deploying your application. If you cannot do that for whatever reason, then you can apply the system property.

Azure Spring Cloud

Azure Spring Cloud does NOT directly distribute Log4j. However, your applications deployed to Azure Spring Cloud may use Log4j and be susceptible to this vulnerability. Log4j usage may originate from:  

  • Your application sources. 
  • Application Performance Monitoring tools activated for the application. 

Spring Boot Applications

Spring Boot users are only affected by this vulnerability if they have switched the default logging system to Log4j 2. The log4j-to-slf4j and log4j-api jar files that are included in spring-boot-starter-logging cannot be exploited on their own. Only applications using log4j-core and including user input in log messages are vulnerable. If your application is impacted and you can redeploy the application, we recommend that you upgrade your application to Log4j v2.15.0 using Maven or Gradle, and redeploy to Azure Spring Cloud – see more details at Log4j 2 vulnerability and Spring Boot.

Afterword

Take this seriously if you see any software, appliances or hardware that could be affected. Better to be safe than sorry.

Here is a Sentinel query to find the Indicators of compromise (IOCs)

KEEP CALM STAY SAFE Poster | | Keep Calm-o-Matic
Author: Harri Jaakkonen

Leave a Reply

Your email address will not be published. Required fields are marked *