Apps/Gaming

Log4j: The vulnerability and solution

The message from log4j and its vulnerability is long gone, but it is important to understand what happened as the impact and vulnerability still lingers. It is also important to reiterate how dangerous such a threat can be for systems worldwide along with the ways to fix it. In this article, I’ll go over what the vulnerability created by Log4j is, how it can be detected in systems, and how developers can appropriately mitigate it.

In another article, I discussed what Log4j is and where and how it is typically used. Log4j is a logging framework developed by the Apache Software Foundation as an open source tool. It is intended to help track bugs in Java-based applications in an online environment. Log4j 2 not only tracks messages and errors from systems, but can also accept commands to generate extended log data. Essentially, Log4j 2 can communicate with data sources, including internal directory services. A major exploit has been found here.

Read: Overview of the Log4J logging tool

In early December 2021, it was announced that the 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, 2021 and disclosed privately after discovery and disclosed publicly on December 9. This vulnerability has been awarded the highest CVSS (Common Vulnerability Scoring System) score of 10. Dubbed Log4Shell, the exploit is relatively easy to execute and widespread, with many saying it affects hundreds of millions of devices.

As mentioned, Log4j 2’s features are able to communicate with other data sources, including internal directory services. Because of this, malicious actors can feed Log4j 2 with their own commands from outside the network to trick it into downloading and running malicious code. How this exploit is used depends on the affected system. So far it has been reported that most malicious activities are limited 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, also known as Log4Shell, is a vulnerability that allows a remote malicious actor to take control of an internet-connected device running certain versions of Log4j 2. It is a vulnerability that allows attackers to specifically exploit Log4j by connecting to any JNDI (Java Name and Directory Interface) servers. Hackers can use it to send Java code to these servers, get information about the environment, and even take control of it. It counts as one Zero day exploit since it is very likely that hackers knew about it before experts.

What makes this vulnerability so dangerous is the penetration of the actual Log4j library. Big technology companies like Nvidia, Intuit, Hewlett Packard Enterprise, Cloudflare, Microsoft, IBM, Red Hat, Salesforce, Siemens and others use Log4j as their logging solution. Not only organizations, but ubiquitous platforms from VMware to Amazon Web Services use 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 between these technologies mean that patching this issue will be complex and time-consuming. That’s why this vulnerability has such an intense CVSS score in the first place.

Apart from that, a fix was released on December 6, 2021 when Apache released a patch for CVE-2021-44228 as log4j 2 version 2.15. However, this particular patch only partially fixed the vulnerability, resulting in CVE-2021-. 45046, which allowed attackers to continue looking up information when they already had control of thread context mapping for data if logging configurations were not left at default values.

Apache fixed this issue with the release of version 2.16 on December 13th. Another patch (version 2.17) was released on December 17th to solve a related issue leading to a Denial of Service Output (CVE-2021-45105). A fourth patch in version 2.17.1 was also released on December 28 to address a similar but separate remote code execution issue for the original vulnerability (CVE-2021-44832).

Read: Best practices in cloud security

How to fix Log4j vulnerabilities

Organizations working with Log4j 2—or using third-party technologies that integrate this library into their own systems—should update those technologies immediately. Because this vulnerability is so widespread, companies should act quickly to protect their environment. IDS services such as SentinelOne and Dynatrace can help identify vulnerable systems and their dependencies. Security teams are undoubtedly already aware of this flaw, and as such have already advocated mitigating it through traditional application security means, even if that meant repeating it for successive 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 storage and smart home devices also use Log4j 2. It is recommended that users disable these devices until they are sure that an update has been released by the manufacturer to fix this issue. Most companies have posted some kind of notice on their websites regarding this, along with their response to the Log4j 2 vulnerability.

If you believe your own environment has either remote code execution vulnerabilities (CVE-2021-44228 or CVE-2021-45046), the Cybersecurity and Infrastructure Security Agency (CISA) – along with several contributors – has a scanner for made available to the public use who can find versions of Log4j affected by this vulnerability. You can find this Scanners on their GitHub Page. For a complete list of Apache technologies affected by CVE-2021-44228, Apache has published a list here. It is important to point out that after finding these vulnerable versions, you should update the Log4j libraries of these environments to the latest version (version 2.17.1 or 2.3.2 recommended).

For a full description of the security issue and the steps to resolve it, it is recommended to visit the Apache security page dedicated to CVE-2021-44228, CVE-2021-44832, CVE-2021-45046, and CVE-2021-45105 here.

Related posts

Top visualizations for game telemetry data

TechLifely

MySQL Quick Tip: Using the DROP USER Command

TechLifely

Java Output Basics

TechLifely

Leave a Comment