The news of Log4j and its vulnerability has long since passed, but it is important to understand what happened, as the effects and the vulnerability still linger. It is also important to reiterate how dangerous a threat like this can be to systems worldwide, along with the ways to remediate it. In this article, I will go over what the vulnerability brought by Log4j is, how it can be detected within systems, and the ways developers can mitigate it properly.
In another article, I discussed what Log4j is, along with where and how it is usually used. Log4j is a logging framework developed by the Apache Software Foundation as an open-source tool. It is meant to help keep track of errors in Java-based applications in an online environment. Not only does Log4j 2 track messages and errors from systems, but it can also take in commands to generate advanced logging data. Essentially, Log4j 2 can communicate with data sources, including internal directory services. It is here that a major exploit was found.
Read: Overview of Log4J Logging Tool
In early December of 2021, it was announced that Apache Software Foundation’s Log4j had a zero-day vulnerability that had existed since 2013. It was discovered by Chen Zhaojun, a member of Alibaba’s security team, on November 24 of 2021, and was privately disclosed to Apache upon discovery and publicly announced on the 9th of December. This vulnerability was given the highest CVSS (Common Vulnerability Scoring System) severeness score of 10. Dubbed the Log4Shell, the exploit is relatively easy to execute and is widespread, with many saying it affects several hundreds of millions of devices.
As mentioned, Log4j 2 features are able to communicate with other sources of data, including internal directory services. Because of this, malicious actors can feed Log4j 2 with their own commands from outside the network to make it download and execute malicious code. How this exploit is used depends on the system that is affected. So far, it has been reported that the majority of malicious activities are relegated to scanning and fingerprinting an environment. However, other reported activities include stealing credentials, installing ransomware, exfiltrating data, and otherwise taking extensive control of a network.
What is Log4Shell?
CVE-2021-44228, aka Log4Shell, is a vulnerability that enables a remote malicious actor to take control of an Internet-connected device if it is running certain versions of Log4j 2. It is a vulnerability that specifically allows attackers to take advantage of Log4j’s connection to arbitrary JNDI (Java Name and Directory Interface) servers. Hackers can use this to send Java code to those servers, gain information about the environment, and even take control of it. It is considered a zero-day exploit as it is very likely that hackers knew about it before experts.
What makes this vulnerability so dangerous is how permeating the actual Log4j library is. Major tech companies like Nvidia, Intuit, Hewlett Packard Enterprise, Cloudflare, Microsoft, IBM, Red Hat, Salesforce, Siemens, and more are using Log4j as their logging solution. Not just organizations, but ubiquitous platforms from VMware to Amazon Web Services are using this tool in their products and services. Even entertainment applications like Steam and Minecraft (Java Edition) rely heavily on Log4j. The intricate layers of dependencies among these technologies mean that patching this problem is going to be complex and time-consuming. This is the reason why this vulnerability has such an intense CVSS score in the first place.
All this being said, a fix was released on December 6th of 2021, as Apache issued a patch for CVE-2021-44228 as version 2.15 of log4j 2. However, this specific patch only partially solved the vulnerability, resulting in CVE-2021-45046, which allowed attackers to still lookup information if they already had control over the Thread Context Map on data if the logging configurations were not left on defaults.
Apache fixed that problem with the release of version 2.16 on December 13th. Another patch (version 2.17) was issued on December 17th to solve a related problem that resulted in a Denial-of-Service issue (CVE-2021-45105). A fourth patch in version 2.17.1 was also released on December 28 to solve a similar, yet separate, Remote Code Execution issue to the original vulnerability (CVE-2021-44832).
Read: Best Practices in Cloud Security
How to Fix Log4j Vulnerabilities
Organizations that work with Log4j 2 – or use third-party technologies that include this library in their own systems – should immediately update those technologies. Because of how widespread this vulnerability is, organizations should act hastily in order to protect their environments. IDS services like SentinelOne and Dynatrace can assist in identifying vulnerable systems as well as their dependencies. Security teams no doubt know about this flaw already and so have already engaged in mitigating this through traditional application security means, even if it meant repeating this for the consecutive vulnerabilities discovered.
Consumers should be just as concerned as any organization, considering that many companies use the Log4j 2 library either directly or indirectly in their services and applications. Many network-enabled storages and smart home devices use Log4j 2 as well. It is recommended that users disable those devices until they are sure an update from the manufacturer fixing this issue has been released. Most companies have some sort of messaging regarding this on their websites, along with what they are doing in answer to the Log4j 2 vulnerability.
If you believe that either Remote Code Execution vulnerabilities (CVE-2021-44228 or CVE-2021-45046) exist within your own environment, the Cybersecurity and Infrastructure Security Agency (CISA) – along with several contributors – have made a scanner available for public use that can find versions of Log4j that are affected by this vulnerability. You can find this scanner on their GitHub page. For a full list of Apache technologies that are affected by CVE-2021-44228, Apache has released a list here. It is important to state that after finding these vulnerable versions, you should update those environments’ Log4j libraries to the latest version (version 2.17.1 or 2.3.2 recommended).
For a full description of the security issue and the steps towards mitigating them, it is recommended to visit Apache’s security page addressing CVE-2021-44228, CVE-2021-44832, CVE-2021-45046, and CVE-2021-45105 here.