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.
Table of Contents
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
| Level | Description |
|---|---|
| OFF | The highest possible rank and is intended to turn off logging. |
| FATAL | Severe errors that cause premature termination. Expect these to be immediately visible on a status console. |
| ERROR | Other runtime errors or unexpected conditions. Expect these to be immediately visible on a status console. |
| WARN | Use 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. |
| INFO | Interesting runtime events (startup/shutdown). Expect these to be immediately visible on a console, so be conservative and keep to a minimum. |
| DEBUG | Detailed 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. |
| TRACE | Most 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:
- Trojan:Win32/Capfetox.AA– detects attempted exploitation on the attacker machine
- HackTool:Win32/Capfetox.A!dha – detects attempted exploitation on the attacker machine
- VirTool:Win64/CobaltSrike.A, TrojanDropper:PowerShell/Cobacis.A – detects Cobalt Strike Beacon loaders
- TrojanDownloader:Win32/CoinMiner – detects post-exploitation coin miner
- Trojan:Win32/WebToos.A – detects post-exploitation PowerShell
On Linux:
- Trojan:Linux/SuspectJavaExploit.A, Trojan:Linux/SuspectJavaExploit.B, Trojan:Linux/SuspectJavaExploit.C – blocks Java processes downloading and executing payload through output redirection
- Trojan:Linux/BashMiner.A – detects post-exploitation cryptocurrency miner
- TrojanDownloader:Linux/CoinMiner – detects post-exploitation cryptocurrency miner
- TrojanDownloader:Linux/Tusnami – detects post-exploitation Backdoor Tsunami downloader
- Backdoor:Linux/Tusnami.C – detects post-exploitation Tsunami backdoor
- Backdoor:Linux/Setag.C – detects post-exploitation Gates backdoor
- Exploit:Linux/CVE-2021-44228.A, Exploit:Linux/CVE-2021-44228.B – detects exploitation
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
- To facilitate these steps and minimize business impact, you may wish to use application tagging capabilities to identify those applications which you haven’t validated as patched and target stricter policies to them.
- Enable MFA for all access to these resources to prevent probing using accounts with compromised passwords.
- If you are using Azure AD Identity Protection, enable blocking on risky logins (we recommend blocking on medium or higher). This will prevent access via ToR exit nodes and anonymizing VPNs.
- If you use Azure AD Conditional Access, restrict access to your resources to known/trusted locations or networks.
- Require Azure AD joined or better, MDM managed devices to access these resources.
- Monitor the risky sign in reports or use the risk workbook to track anomalous logins to your applications to help focus your investigations.
- While ADFS, as a Windows service, does not use the impacted libraries, other federation providers do. If you use a non-Microsoft federation provider (for example, for SAML 2.0), watch for token anomalies which indicate compromise of those systems.
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.
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)
RSS - Posts