Log4j Vulnerability | Client Alert | Aon's Cyber Solutions

UPDATED: December 20, 2021. This page is updated to reflect the most timely information available.

Apache has now released Version 2.17 of the patch for Log4j, which addresses vulnerabilities in the previous patch that made it vulnerable to DoS attack (CVE-2021-45105). We recommend updating to this latest version as quickly as possible.

UPDATED: December 15, 2021. This page is updated to reflect the most timely information available.

Last week, Version 2.15 of the widely used open-source Apache logging library Log4j was released to tackle a critical security vulnerability, called Log4Shell, which could be trivially abused to hijack systems over the internet. The 2.15 release closed the hole (CVE-2021-44228) by disabling by default the Java library’s primarily exploitable functionality: JNDI message lookups.

Apache has now released Version 2.16, which disables all JNDI support by default and removes message lookup handling entirely. This action was needed as Version 2.15 is still exploitable in certain non-default configurations, and this moderate-severity oversight has earned its own bug ID: CVE-2021-45046.

Ensure to update your systems using log4j to the newest Version 2.16 to ensure system integrity against this exploit. Attempts at utilizing the vulnerability are still occurring at an almost record-breaking rate across the Internet, including reports during the last 24 hours of nation-state sponsored and other commercially motivated threat actors actively seeking to exploit the vulnerability.

Sources:

Log4j – Apache Log4j Security Vulnerabilities

Apache Log4j Vulnerability Guidance | CISA

Log4j Overview

On December 9, 2021, a new cyber security vulnerability related to a remote code execution zero-day called “Log4j” (CVE-2021-44228 or “Log4Shell”) was identified by security researchers. This vulnerability is being described as a “severe risk” to enterprises by U.S. entities such as the Department of Homeland Security Cybersecurity and Infrastructure Agency (CISA) due to its widespread impact and ease of use.

Specifically, companies may not be able to assess their total risk exposure due to Log4j being used across multiple third-party software platforms.

The following information is provided to help security teams understand what this threat is, whether you may be impacted by it, and what can be done immediately to help reduce your risk.

What is Log4j?

Log4j is a widely used Java-based logging library developed by the Apache Software Foundation, which is primarily used for logging errors from applications, including web and mobile application servers, email servers and cloud services applications worldwide. In addition, Log4j is used in multiple Apache web frameworks such as Apache Druid, Apache Flink, Apache Solr, and ApacheStruts2.

Companies such as Amazon, Apple, Cisco, Elasticsearch, Red Hat, and many more produce applications that use the Log4j framework. Early reports indicate that almost all versions of Log4j – starting from 2.0-beta9 through 2.14.1 – are vulnerable to this zero-day exploit, which US-CERT has assigned as CVE 2021-44228. US-CERT has assigned this vulnerability the highest critical rating ten (10) as of the time of publication.

How does this affect my organization?

While Log4j is a library used within many applications, companies may not be aware that it is running in your environment. In addition to Apache, Log4j is bundled with Java applications as a logging mechanism. This vulnerability allows remote code execution (RCE) on vulnerable servers, which in turn gives an attacker the ability to import and run malware in your environment that could compromise machines.

How severe is this vulnerability?

“Log4Shell,” has been deemed to be a severe risk and critical threat to organizations due to its widespread use and ease of use of the exploit. An attacker would be able to take control of a system by simply passing a short, crafted command from the Internet to a computer running a vulnerable version. Afterward, an attacker can install crypto mining software, botnets, malicious beacons, and even ransomware.

After the vulnerability was released, attacks reportedly started immediately. Within 72 hours, scans by threat actors increased from several hundred to several thousand per minute to further perpetuate the attack and target organizations to gain a foothold before any mitigation occurs.

What can organizations do?

Update your applications to the latest version of Log4j, which is v2.15. Note that running an update may pose a challenge as many applications have the built-in vulnerable library as part of the logging mechanism. Apache recommends the following temporary method if updating is not possible:
- - In releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true.
  - 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.
Monitor your vendor sites for updates and patches to apply to any software in your organization. Conduct continuous threat and endpoint monitoring for the string “{jndi” as it can indicate scanning activities that could result in a compromise of the system.
Run EDR technology on all servers and perform remediation immediately upon discovery of any indicators of compromise or exploits. If vulnerable applications are found, assume they have been exploited and activate your incident response plan.
While patching is an essential part of the process, it is not the only mitigation step. “Fixing” the initial entry point but not investigating to fully understand the extent of the incident may leave your organization ill-informed about the potential impact. Conduct a threat hunt and compromise assessment, including but not limited to a search for the known specific indicators of compromise (IOCs) associated with this exploit.
Since there is no single solution for all clients, work with a trusted incident response partner to help assess your exposure.

Indicators of Compromise:

Below are additional resources that capture a limited set of IOCs seen with this event.

AUTHORED BY:

Stroz Friedberg Incident Response

Ed Michael, Manager, DFIR
Cheri Carr, Managing Director and DFIR Practice Leader
John Ansbach, Vice President, Engagement Management
Catarina Kim, Managing Director/Practice Leader, Intelligence Group

Client Alert | Log4j