Cybersecurity Blog | Ingalls Information Security

Log4Shell - Log4j Vulnerability (CVE-2021-44228)

Written by Cyrus Robinson | Dec 15, 2021 5:00:00 AM

Apache Log4j2 <=2.14.1 JNDI features used in the configuration, log messages, and parameters do not protect against attacker-controlled LDAP and other JNDI-related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default. You should assess your entire environment for applications that use Apache Log4j, in infrastructure and workloads, and remediate them as soon as possible either through patches or workarounds when available.


Affected Software / System

This advisory specifically applies to the following products:

log4j 2.x confirmed - log4j 1.x only indirectly (previous information disclosure vulns) (in some configurations))


CVE (if applicable)

CVE-2021-44228


Type

Log4Shell log4j vulnerability


Exploit Status: 

CVE-2021-44228 is currently being exploited in the wild.


Rating

“Critical” severity with a CVSS 3.0 rating of 10.0


Impact

The Log4j 2 library is very frequently used in enterprise Java software. Due to this deployment methodology, the impact is difficult to quantify. Like other high-profile vulnerabilities, such as Heartbleed and Shellshock, we believe there will be an increasing number of vulnerable products discovered in the weeks to come. Microsoft reported that their security teams have seen Cobalt Strike beacons being dropped after log4j attacks. Due to the ease of exploitation and the breadth of applicability, we suspect ransomware actors to begin leveraging this vulnerability immediately.


Mitigations

Direct remediation:
Upgrade any older Log4j 2.x to 2.16.x - requires Java 8. 2.15.0-rc1 insufficient. For older log4j, you can rename/remove the JndiLookup.class. Note that any project still using log4x 1.x is running a deprecated and unsupported version with other known vulnerabilities - CVE-2019-17571 is CVSS 9.8

Mitigations – easiest*
If you can't upgrade log4j, you can mitigate the RCE vulnerability by setting log4j2.formatMsgNoLookups to True (-Dlog4j2.formatMsgNoLookups=true in JVM command line) (but only for >= 2.10.0). Putting Cloudflare in front of your site (and terminating your SSL there) could be an easy but only partial solution

Mitigations - official Log4j project ( https://logging.apache.org/log4j/2.x/ )*
Users of Log4j 2.10 or greater may add -Dlog4j2.formatMsgNoLookups=true as a command-line option or add log4j2.formatMsgNoLookups=true to a log4j2.component.properties file on the classpath to prevent lookups in log event message. Users since Log4j 2.7 may specify %m{nolookups} in the PatternLayout configuration to prevent lookups in the log event messages. Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the JndiContextSelector and JMSAppender to no longer function.

*These mitigations may not work for all implementations of Log4j. Always reference vendor-specific disclosures and guidance for the best remediation strategy.


Ingalls recommends the following actions:

Ingalls encourages organizations to adopt an assumed breach mentality and review logs for impacted applications for unusual activity. If you find these hashes in your software inventory, then you have the vulnerable log4j library in your systems and need to take action: https://github.com/mubix/CVE-2021-44228-Log4Shell-Hashes. If anomalies are found, we encourage you to assume that you have been compromised and respond accordingly. Upgrading to the patched versions of log4j or impacted applications will eliminate this vulnerability.

Additionally, we recommend turning off recursive DNS on web-accessible servers (filter them through a discretionary service that only allows essential resolution) and changing your outbound firewall rules to default deny. The exploit works by performing a DNS resolution to a public site (usually an attacker-controlled LDAP server, but other protocols are also being leveraged), and then making an egress fetch to retrieve a malicious java payload. Blocking outbound traffic at your perimeter/edge prevents the second stage (querying an attacker-controlled server) of the attack for many of the public Proofs of Concept. If you cannot block all outbound connections, at the very least, block outbound LDAP. Generally, it is a good idea to restrict outgoing server traffic by whitelisting any required traffic. If this is not possible, you can nevertheless monitor outgoing connections and use a to alert you of such connections.

  1. For Ingalls MDR customers, these exploit attempts are detected by our Network Sensor appliance. Please ensure that all HTTP traffic (including within your DMZ) is being monitored by an Ingalls Network Sensor. If there are networks not covered in your Ingalls Network Security data work with Ingalls to get them added.
  2. For Ingalls DNS Defense customers, secondary stage activities can be blocked at the DNS level. Please implement the guidance provided by Cisco Umbrella to ensure comprehensive DNS protection within their environment: https://support.umbrella.com/hc/en-us/articles/230904088-Preventing-circumvention-of-Cisco-Umbrella-with-firewall-rules
  3. For Ingalls Vulnerability Management customers, this vulnerability can be detected remotely using our managed Nessus vulnerability scanners. Please provide Ingalls SOC with a list of potentially vulnerable servers for specific enumeration and scanning. This detection will also be included in scheduled scans after December 14th.

 

Ingalls is dedicated to protecting your network and your information by providing defense-in-depth security through your Managed Detection & Response (MDR) service. As an added layer of defense, Ingalls now offers monitoring and support by a team of live Security Analysts in our Security Operations Center (SOC) 24 hours a day, every day of the year. ‘Round the clock, MDR provides extended coverage with continuous analysis, response and escalation so you can have the peace of mind that comes from knowing your network is being monitored in real-time even if your business hours have stopped. Please contact us for more information.