Log4j: what you need to know
There is never a dull moment in the information security space. It’s a constant battle between adversaries and cyber security experts. But, every now and then, there is a major security event or discovery of a new critical zero-day vulnerability that can literally break the internet. The Log4j zero-day vulnerability, with a perfect 10.0 CVSS score and classified as “Critical” severity, is one of those mega security events!
On Friday, December 10th, the information security world was rocked by the disclosure of Log4j (CVE-2021-44228), a critical zero-day vulnerability in the widely-used Java logging library Apache Log4j, which allows attackers to remotely execute code and gain access to machines.
So, what is Log4j? What is it used for? Why this vulnerability is so critical? What can you do to protect against it? In this blog, we will present information about Log4j, and how you can deal with it.
What is Log4j?
Apache Log4j is a Java-based logging utility, which is part of the Apache Logging Services. Log4j is used for logging capabilities or a record of an activity. Typical usage of Log4j will be in a definition of log levels (fatal, error, warn, etc.), mechanisms to write to different log files, problem troubleshooting or data tracking within programs, log rolling patterns, and more. The fact that Log4j is free makes it extremely popular and widely used in most web services.
Log4j vulnerability
Apache Software Foundation’s group of volunteers was alerted on November 24th of a vulnerability in Log4j, which resulted in a remote code execution after a member of Alibaba’s cloud security team discovered it.
On December 10th, an unusual warning sent shockwaves through the cybersecurity community after makers of the video game Minecraft shared the vulnerability in a blog post, alerting gamers that hackers had identified a flaw in their game that could be used to infiltrate their computers.
“Hello everyone! Earlier today, we identified a vulnerability in the form of an exploit within Log4j – a common Java logging library. This exploit affects many services – including Minecraft Java Edition. This vulnerability poses a potential risk of your computer being compromised, and while this exploit has been addressed with all versions of the game client patched, you still need to take the following steps to secure your game and your servers.”
Why it is so critical?
The Log4j vulnerability is relatively simple to take advantage of and the impact is dramatic, such as attackers looking to get a foothold in networks in order to sell that access to ransomware operators. Other attacks can use the Log4j vulnerability to download Trojan malware, which can then trigger the download of an .exe file that can, in turn, install a crypto-miner or any other malware on the compromised device to gain access to critical data and services.
Since Log4j is embedded in a vast array of applications, services, cloud platforms, web applications, email services, and enterprise software tools that are written in Java and used by organizations and individuals around the world, the potential impact can affect millions of devices worldwide.
Attacks around the word
Since the publication of the Log4j vulnerability, there are reports of cyber attackers who are attempting to exploit it each and every minute. Attackers are already attempting to scan the internet for vulnerable instances of Log4j.
“More than 35,000 Java packages, amounting to over 8% of the Maven Central repository (the most significant Java package repository), have been impacted by the recently disclosed log4j vulnerabilities,” wrote James Wetter and Nicky Ringland of Google’s Open Source Insights Team in yesterday’s blog post.
According to Google, the vast majority of vulnerable Java packages in Maven Central borrow log4j “indirectly”—that is log4j is a dependency of a dependency used by the package. For clarity, Google shared a simple diagram of this relationship in their blog post.
Out of the 35,863 packages identified by Google, just about 7,000 borrowed log4j directly, indicating not all developers may have adequate visibility into their software. “User’s lack of visibility into their dependencies and transitive dependencies has made patching difficult; it has also made it difficult to determine the full blast radius of this vulnerability,” they explained.
So, what’s the best path for mitigation against the Log4j vulnerability?
The vulnerability, which was published under CVE-2021-44228, affects Apache Log4j version 2 (2.0 through 2.12.1 and 2.13.0 through 2.15.0) JNDI features used in the configuration, log messages, and parameters, which do not protect against attacker-controlled LDAP and other JNDI related endpoints.
An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From Log4j 2.15.0, this behavior has been disabled by default.
So, the Apache Software Foundation has released version 2.15.0 to address the flaw and one is tempted to think that the issue is behind us. But, it is not…
A few days from the release of 2.15.0, it was found that this version is vulnerable to DoS attack and, you know the drill… A new CVE was published under CVE-2021-45046, which initially classified as “Low” severity with a risk base score of 3.7, was now changed to “Critical” with a base score of 9.0. A new Log4j version 2.16.0 was released to address this vulnerability.
OK, we have version 2.16.0, which “fixes everything.” So, one may think that this crisis is behind us. But, we did say that it’s a never-ending battle without a dull moment, right?
Version 2.16.0 was found also to be vulnerable to DoS attack, and this time was scored as “High” with a base CVSS score of 7.5 under CVE-2021-45105.
To fix the vulnerability, log4j version 2.17.0 (for Java 8) has been released and allows only “lookup strings in configuration” to expand recursively. In any other usage, only the top-level lookup would be resolved, and not any nested lookups.
The Allot perspective and solution
Once the Log4j vulnerability was discovered, Allot cybersecurity experts analyzed it to see if Allot solutions (consisting of Allot Smart and Allot Secure) were vulnerable and a security advisory was published to address it. After a thorough analysis of Allot’s solutions and services for CSPs and enterprises, it was determined that the vast majority of them were not vulnerable. A hotfix was immediately released to address the vulnerable components.
I highly recommend the implementation of the hotfixes, not just for Allot products, but for any product deployed in the network that has a patch or a hotfix to close this critical vulnerability.
Additionally, it is highly recommended to deploy Intrusion Prevention System (IPS) rules to detect and prevent attack patterns. Due to the critical nature of this vulnerability, Allot added a new signature to its Network Intelligence platforms and deployed inline in CSPs and enterprise networks. The new signature is available as a hot patch under ERT-PP 3.153.90 to detect Log4j attacks and to add another layer of protection to your devices, services, and applications that are utilizing Log4j and are exposed to the vulnerability.
The new Log4j attack pattern detection will also be available in the next protocol pack update, which is scheduled for December 22nd.
