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.
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-2021-44228 is currently being exploited in the wild.
“Critical” severity with a CVSS 3.0 rating of 10.0
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.
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 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.
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.