Security teams at companies large and small are scrambling to patch a previously unknown vulnerability called Log4Shell, which has the potential to let hackers compromise millions of devices across the internet. If exploited, the vulnerability allows remote code execution (RCE) on vulnerable servers, giving an attacker the ability to import malware that would completely compromise machines. The vulnerability is found in log4j, an open-source logging library used by apps and services across the internet. Logging is a process where applications keep a running list of activities, they have performed which can later be reviewed in case of error. Nearly every network security system runs logging process, which gives popular libraries like log4j an enormous reach. A RCE flaw was found in Apache Log4j2 that allows a remote, unauthenticated/authenticated attacker to use logger along with owned LDAP server to execute arbitrary code (RCE) loaded from that LDAP server. The attacker could get, modify, or delete resources on other services that may be behind a firewall and inaccessible otherwise. The impact of this flaw varies based on what services and resources are available on the network and capabilities of the RCE.
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. 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.
As per Apache Foundation’s logging security team, 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 class path: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
Java 8u121 (see www.oracle.com/java/technologies/javase/8u121-relnotes.html )protects against remote code execution by defaulting “com.sun.jndi.rmi.object.trustURLCodebase” and “com.sun.jndi.cosnaming.object.trustURLCodebase” to “false”.
How can Avocado help organizations to mitigate Log4Shell and other unknown vulnerabilities, that are currently in CIRCULATION but are still UNDETECTED?
Avocado Security Platform (ASP) enables runtime protection of applications running in production environments, against CVE- 2021-44228 for enterprise applications like Apache Log4J2 without requiring any upgrade, change or re-engineering of the target application.
The attack has two steps:
- Penetration using specific signature: jndi:ldap://<IP Address>:<TCP port number>/<command>
- Lateral attacks or outbound activities including RCE, exfiltration, lateral
Any penetration into Apache logger can result into lateral attack by –
- Spawning Remote Code Execution
- Remote Command Execution
- New process execution and data exfiltration to C&C
- Outbound or later session by execution of scripts
- Executing unsanctioned communication code in the penetrated host process context
- Loading unsanctioned code into memory and executing
Avocado’s Zero-Trust enabled by patented pico-segmentation (which does not require any manual policy), intercepts and mitigates such lateral attacks performed via logger exploit, backdoor or insider jobs.
Avocado’s data protection policies identify specific penetration by signature also. For example, Apache logger can be enabled to intercept CVE-2021-44228 exploit by enabling an ASP data protection policy. Options include:
- The CRS Rule Set regex : \$\{jndi:(ldap[s]?|rmi|dns):/[^\n]+
- Import ModSecurity CRS rule
- Import your WAF rule for CVE-2021-44228
For intercepting CVE-2021-44228 RCE attack, Avocado’s RCE interception policy has actions configured. These policies are configurable, or security administrators can import the updated CRS rules from Mod Security. By default, it stops such penetration attempts by identifying, classifying, and dropping the session.
Please ask Avocado’s team at info@avocadosys.com, for the rule which would create virtual patch for your Apache logger deployments. It is simple and does not require any changes in Apache logger application or architecture.
