Security experts consider Log4j to be one of the most serious threats to come down the pipe in recent years. It’s viewed in this way because of two factors: the sheer number of systems that are vulnerable, and the ease with which an attacker can compromise a network.
The Log4j issue is a type of remote code execution vulnerability, and a very serious one that allows an attacker to drop malware or ransomware on a target system. This can, in turn, lead to complete compromise of the network and the theft of sensitive information as well as the possibility of sabotage.
The vulnerability has been given the Critical rating and the highest threat score possible (10.0) by the Common Vulnerability Scoring System (CVSS), the industry standard for at-a-glance assessments of the severity of security vulnerabilities.
All of this is said to illustrate that this is a very serious issue that needs to be addressed immediately — but what exactly should you be doing about it?
What is Log4j, and who does the vulnerability impact?
Log4j is a very popular Java library that has been around since 2001 and is used by countless pieces of software to log activity and error messages. The core vulnerability (CVE-2021-44228) impacts Apache Log4j 2, the current edition of the library.
Log4j will first log messages in software, then scan them for errors. Its logging capabilities allow it to communicate with other internal functions on systems, such as directory services. This creates the opening for the vulnerability. A way to craft malicious strings of code that can be executed via Log4j was discovered. The primary attack is to feed messages to Log4j that instruct the system to download and execute malware from a remote server, which then grants the attacker greater access to the victim’s system.
The Log4j vulnerability was discovered in, of all places, Minecraft; specifically, the Java version of the game. Threat actors discovered that entering a malicious line of code in the game’s chat caused it to be logged by Log4j in a way that allowed for commands to be executed. If an attacker is able to enter a string of code into a form that is logged by Log4j, even something as small as a name field used for logging in to cloud services, it is possible that this vulnerability can be exploited. Windows, Linux, and Mac environments are all equally vulnerable.
Organizations of all types and sizes make use of Log4j. It might sound flippant to say “a lot” in answer to how many are impacted, but it’s really the best possible answer under the circumstances. It’s bundled into so many things and used so widely that only very general estimates are possible. Google’s security team says that 35,000 Java packages are impacted, or over 8% of the content of the world’s most-used Java repository (Maven Central). That’s 4x the footprint that the average vulnerability has. As of the end of December 2021 about half of those packages had been patched.
Organizations of all types and sizes should assume that the Log4j vulnerability is lurking somewhere in their software environment.
How long has the Log4j vulnerability been out there?
A security researcher working for Alibaba, Chen Zhaojun, first discovered the vulnerability and reported it to Apache on November 24, 2021. However, subsequent forensic investigations indicate that threat actors discovered it first and have been using it since at least December 1 2021.
Attacks exploiting the Log4j vulnerability appear to have been limited to Minecraft servers until the issue was made public by Apache on December 9, 2021. Since then, security researchers have counted millions of attempts to use it that have been targeted at organizations all over the world.
Security experts do not project that the issue will be fully “fixed” for years given the amount of existing software out in the wild that needs to be patched or updated.
How much of a risk does Log4j pose to the average company?
Everyone that has Log4j present in their systems is at serious risk of a breach. After the vulnerability was made public in December, security researchers almost immediately logged millions of attempts to make use of it in attacks. That number has since ballooned to an estimated 10 million attempts every hour.
Criminals are actively scanning the internet for any and all connected devices that contain a vulnerable version of Log4j, and many are not discriminating in who they will compromise. This can be done with an automated script, depositing ransomware or creating a backdoor into a system for later exploration.
There are some industries that seem to be receiving more targeted Log4j attacks than others, however. The retail sector is fielding the greatest number of attacks, likely due to criminals seeking stored payment information and gift cards that are easily converted to cash. The tech industry, financial services and manufacturing are also fielding more attacks than others.
Some regions are also more heavily targeted than others. The United States, United Kingdom, Germany, Turkey and the Netherlands are presently seeing millions more attacks than many other countries.
The fact that it is easy to scan for and exploit means that small time, low skill cyber criminals will naturally be attracted to it. But some of the most advanced hackers in the world, including the Chinese and North Korean state-backed Advanced Persistent Threat (APT) groups, have also been observed trying to use it.
Since it only takes one instance of Log4j in a system to cause a compromise, and since a compromise can lead to very quick takeover of the system, this vulnerability is a major risk to all types of companies.
If an organization is compromised, what kind of damage will the Log4j vulnerability cause?
Since the attackers can harness Log4j to download and run malware on a system, the possibilities are essentially limited only to what kinds of malware they have available to run. They might establish a quiet foothold on a target system to exfiltrate valuable files and spy on communications, they might install ransomware, they might engage in vandalism or sabotage, or they might do some combination of all of the above.
If Log4j is used to exploit a system, it should be assumed that the attackers have full access to it. It is also possible that attackers established a foothold in systems prior to patching, something that security and IT teams should consider if a vulnerable instance of the software has been sitting in place during the breach window.
Does Log4Shell consist of just one vulnerability?
No, the original Log4j vulnerability has essentially mutated into three newer forms as Apache has issued patches, though all were addressed by the end of 2021.
Apache patched the original vulnerability, CVE-2021-44228, on December 6, 2021. However, it turned out that this patch did not entirely fix the issue. The subsequent new vulnerability, CVE-2021-45046, was patched on December 13, 2021. However, a new vulnerability was discovered after this; CVE-2021-45105, which was addressed by a third patch on December 17, 2021. This didn’t quite do it, however, as yet another related vulnerability (CVE-2021-44832) and a fourth patch was issued on December 28, 2021.
This might all sound complicated, but from a patching perspective it’s very simple. The “patches” are simply updated versions of Apache Log4j 2. So if you have anything prior to version 2.17.1, the one issued on December 28, 2021, you could still be vulnerable.
Fixing the issue is simply a matter of updating Apache Log4j 2 instances to at least version 2.17.1. However, that is easier said than done for many organizations given how many places Log4j is in use throughout the software environment.
Is the Log4j situation a threat to individual internet users?
For the most part, this is an issue that impacts organizations and businesses rather than individual users on their personal home internet. However, Log4j can be found in certain pieces of equipment intended for the home, chiefly home routers, network storage devices and certain types of internet-connected smart devices.
Check with the manufacturer of these devices to see if they have issued a notification about Log4j. They may have issued a patch that may take some additional steps to install. If a patch is required, disconnect the devices from the internet until you are ready to apply it.
How do you detect the Log4j vulnerability?
Since Log4j can be bundled into such a great variety of software, system administrators essentially have to take a full inventory of all of the apps and software in their environment to find and patch all the instances of it.
Patching is also not always the same process for each instance. In some cases, you get the relatively easy option of simply installing a new version of the software from the vendor that has been updated to protect against the Log4j vulnerability. Other impacted components, such as routers, might require a full system update. The more problematic instances will require a manual patching method of going into the code and editing pieces of it.
This work generally needs to be done by IT professionals familiar with the Java programming language, as Log4j instances can be several layers deep in Java archive files. But they will generally start by using scanning tools, such as Grype and Syft, to comb Java applications after they have been inventoried.
How do organizations fix the Log4j vulnerability?
Guidance has been made available from several different sources.
The Cybersecurity and Infrastructure Security Agency (CISA) has issued a guide that offers assistance in scanning internet-facing assets and prioritizing patching. It also makes suggestions for monitoring for unusual traffic that could be a sign of attempted exploitation of the Log4j vulnerability. This guidance also suggests that patching should be the primary and immediate focus, as some of the early suggested indirect mitigation measures have turned out to be fallible. Apache is maintaining a list of these outdated measures.
