Widespread Exploitation of Critical Remote Code Execution in Apache Log4j
Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker-controlled LDAP and other JNDI related endpoints. This vulnerability is now being widely used by threat actors in the wild in both targeted and opportunistic attacks.
CVE-2021-44228 is the described vulnerability whereby an attacker with access to log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled (this is enabled by default).
Affected versions: All Apache Log4j (version 2.x) versions up to 2.14.1 are vulnerable if message lookup substitution was enabled.
1) Security teams and network administrators should update to Log4J 2.15.0 immediately, invoking emergency patching procedures and/or incident response procedures to identify affected systems, products, and components and remediate this vulnerability with the highest level of urgency. If this is not possible due to operational reasons, in releases >=2.10, this behaviour 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.
2) Security teams should also monitor web application logs for evidence of attempts to execute methods from remote codebases (i.e. looking for jndi:ldap strings) and local system events on web application servers executing curl and other, known remote resource collection command line programs. Due to increasingly advanced evasion methods, it is also recommended to look for any unusual outbound ldap traffic, and applications such as “wget” and “curl” to unfamiliar IP addresses
3) Security teams should continue to pay close attention to all security advisories mentioning Log4j and prioritizing updates for those solutions.
4) For systems installed with Java SE, Oracle recommend the following upgrade:
It is recommended that a vulnerability scan be deployed, targeting all systems running Java based applications are using the Log4j library updated to the latest version (2.15.0) or have the workaround applied above.
Bear in mind all internal and external Java applications may be affected by this vulnerability, therefore it should not be assumed that only external facing application are at risk – internal applications should also be verified as a point of urgency.
Rapid7 IDR & iVM Users:
For Charterhouse Group customers who operate their own Rapid 7 IDR and IVM systems, further information, and recommendations from Rapid 7 can be found here:
For SentinelOne Complete and Pentesec MDR Customers:
SentinelOne has the ability to detect any attack vectors prescribed by the security intelligence community in relation to this CVE and will automatically mitigate the threat. SentinelOne continue to actively monitor the situation in collaboration with industry partners, and any further updates will be applied in due course.
For Check Point Firewall customers:
Pentesec Firewall Managed Service customers have had the IPS signature applied. Customers should however still refer to the Mitigation information compiled above in order to apply best security protections. Do not rely on the signature alone (unless carrying out SSL offloading inbound).
A community driven list of potentially affected systems can be found here:
Pentesec Security Essentials customers are under continuous monitoring for attempted exploitation.
Pentesec MDR customers are protected with the SentinelOne MDR platform, which will mitigate any attack relating to this CVE.
We are closely monitoring the situation and any further updates will follow.