Executive Summary

Apache Log4j, dubbed CVE-2021-44228, is an open-source logging utility in almost all major Java-based applications and servers. Currently running on 3 billion devices worldwide, Log4j has been exposed to a high-risk vulnerability underactive and vigorous exploitation.

12.17.2021 Update

Log4j version 2.15.0 (CVE-2021-44228) has been identified as incomplete in specific non-default configurations. The vulnerability has a broad impact and requires immediate attention by users currently running any applications containing Log4j. The updated CVE-2021-45046 is recommended and outlined below.

Critical Advisory

The Apache Foundation has issued an essential advisory and recommends users install the latest version, Log4j 2.15.0, and apply mitigations.

Identify the Vulnerability

Examine your log files for any services using affected log4j versions (anything from versions 2.0-beta9 to 2.14.1 and all versions of 1.x). Look for user-controlled strings like “Jndi:ldap.”

Related CVE: CVE-2021-44228

CVE-2021-44228 as a CVSS score of 10.0. If exploited, an attacker can take control of a system running Log4j versions 2.0-beta9 to 2.14.1 and all versions of 1.x. Log4j.

Issue

A bug has been identified in the Log4j library that can allow an attacker to execute arbitrary code on a system using Log4j to write out log messages.  This vulnerability allows hackers to issue text commands to Java-based applications that invoke the LOG4j library, allowing the execution of remote commands to the host—a remotely exploitable security flaw, which does not require authentication.

Challenge

The challenge revolves around the way Java packing works. JAR files are packages and have dependencies. LOG4J is one of the more common libraries.

Necessary to Note

Maven and Gradle can automatically add JAR files as you build your Java application- posing additional challenges.

Recommendations

1. Load the Syft and Grype open-source tools from Anchor
   1. Syft
      • Generates software bill of materials (SBOM)
      • Can also decree which versions of LOG4j your Java applications may be running
      • Uncover direct and transitive dependencies
      • Output SBOMs in JSON, SPDX, and CycloneDX formats
   2. Grype
      • Vulnerability scanner that can also read SBOM’s from Syft
      • Scan OS and language-specific packages
      • Automate scans
      • Combine with Syft for faster scans
2. Scan systems and libraries looking for any occurrences of the LOG4J library
3. Install the latest version, Log4j 2.15.0, and apply mitigations
4. 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
5. For releases from 2.0-beta9 to 2.10.0, the mitigation is to remove the JndiLookup.class file from the classpath:
   $ zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class
6. 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

Can’t Upgrade

If you can’t upgrade right now, some versions of Log4j, a specific configuration directive in the log4j.properties files may mitigate the issue. Example:  log4j2.formatMsgNoLookups=true

This may provide short-term mitigation for this issue in packages using Log4j by configuring this directive while waiting for new versions of those packages to be released.

Additional Information and Countermeasures

1. CVE-2021-44228 relies on particular patterns in log messages and parameters, for example \$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+. For each potentially impacted service, we recommend performing a log analysis to expose any attempts at exploitation.
2. Suspicious Inbound and Outbound Activity. By analyzing suspicious inbound and outbound connections, you may be able to sweep your environment and identify whether any systems were displaying signs of active compromise.
3. Targeted Systems & Services. By leveraging pattern analytics against network data, you may be able to uncover systems and services targeted by threat actors. This may allow you to perform correlative searches against our asset inventory and drill down to each host to determine if any of those machines were exposed to the vulnerability or actively exploited.
4. Network Indicators.  From the aforementioned analysis, you may gain insight into the infrastructure of various threat actors and identify network indicators being utilized in the attempted exploitation of this vulnerability. Outbound activity to these indicators can then be blocked in a security gateway appliance (i.e. Cloudflare Gateway, Forcepoint, Palo Alto Networks, Fortinet, Broadcom, Check Point, etc.)
5. Restricting outbound traffic. Restricting the ability to call home is an essential part of the kill-chain to make exploitation of vulnerabilities much harder. As noted above, you may be able to leverage Kubernetes network policies to restrict egress to the Internet for impacted systems. In this context, it prevents the next stage of the attack, and the network connection to attacker-controlled resources is dropped.
6. Consider a solution designed to monitor and protect DNS and prevent DDoS attacks while enforcing best practices. Make sure your vulnerable origin servers services are set up via authenticated origin pulls. This means none of the servers will be exposed directly to the Internet.
7. Additional information from the Microsoft Security Response Center may be found here: https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/
8. A list of vendors and how to mitigate the Log4j vulnerability for their solution(s): https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
9. A list of vendors and how to mitigate the Log4j vulnerability for their solution(s):https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592
10. A repository from the CISA provides guidance and an overview of related software regarding the Log4j vulnerability (CVE-2021-44228). https://github.com/cisagov/log4j-affected-db
11. For customers running Log4j version 2.15.0, the previously mentioned CVE-2021-44228 was incomplete in certain non-default configurations. Information on CVE-2021-45046 can be found here: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046

For additional information, contact:

Dan Gregory
VP | System Engineering, CBI
dgregory@cbisecure.com | 313.649.4611