Update 14th January
While the Log4j shell vulnerability surfaced a month ago, it is still being exploited in the wild. Attackers are utilizing it to gain remote code execution (RCE), enabling the deployment of ransomware, crypto miners, and the access of unauthorized systems and data. Exploitation remains simple, allowing attackers to get full control without using sophisticated techniques.
There are more threat actors exploiting this vulnerability today than two weeks ago – and its prevalence means that while many systems have been patched, significant weaknesses remain in many organizations. Please refer to our updated ‘closing the vulnerability’ advice below for HolistiCyber’s recommended in-depth defense approach.
—————
In a year that will be remembered for cyberattacks, the Apache Log4J, or Log4Shell, zero-day vulnerability may lead to the biggest series of attacks of them all as we move closer to the new year.
Apache Log4J is an open-source Java package used to enable logging in many popular applications. There is a vulnerability, identified by the Apache Software Foundation (ASF) as CVE-2021-44228, which is found on popular services including Apple iCloud, Twitter, and Minecraft. Amazon, Cisco, Cloudflare, ElasticSearch, and Red Hat are just a few major manufacturers that include Apache Log4J in their software.
The bug has been assigned a maximum CVSS score of 10, partly due to the enormous attack surface that has been exposed, and partly due to the ease of exploitation (we’ll get there shortly). Log4J is used ubiquitously in software and platforms and is the type of program that can sit in the background of a system without making itself known.
Adding to the complex nature of this vulnerability is that it is used in numerous applications that involve a client and primary application. Organizations that use the client are vulnerable until their vendor updates both the main application and the client. For those using a legacy application, those updates might never take place.
The Log4J vulnerability enables threat actors to completely take over affected servers through remote code execution. Ran Shahor, CEO of HolistiCyber says, “The impact of this vulnerability is great because it becomes trivial for attackers to achieve their goals, be it malicious code execution, ransomware, or data theft. The breadth of systems containing this vulnerability is vast – while the actual mitigation is fairly easy, identifying systems and third-party technologies that contain it will be a major challenge.”
A Simple Exploit
Adding to the nature of the threat is the simplicity with which it can be exploited. The hacker only needs to get the app to log a special string, and the system is compromised. The string, which is small enough to fit in a tweet, is sent to the server. The server then logs the data which contains a malicious payload.
The vulnerability is triggered by the malicious payload, leading the server to request data from a Java Naming and Directory Interface (JNDI). The malicious server responds with a part to a remote Java class file, which is injected into the server process. This triggers a second stage, allowing the attacker to execute their code at will.
Closing the Vulnerability
ASF has released a patch and recommends upgraded Log4J versions to log4j-2.15.0-rc1.
For those that are unable to update the patch, they can close the vulnerability by changing log4j2.formatMsgNoLookups to true by adding:”‐Dlog4j2.formatMsgNoLookups=True” to the JVM command for starting the application. This patch may be considered the primary layer of defense.
However, given the prevalence of Log4J in third-party software – meaning it is may be difficult to identify every instance of the vulnerability on your estate, HolistiCyber recommends an in-depth defense approach.
Our recommended second layer of defense involves applying rules on your existing security controls, to block injection in advance. Examples of this may include the deployment of security models on WAF, IPS, and API endpoint controls.
To see if your organization has been attacked, examine log files for any services using affected Log4J versions, or get in touch with one of our experts to assist.
Under Attack? Get assistance now
