It’s not my intention to be alarmist about the Log4j vulnerability (CVE-2021-44228), known as Log4Shell, but this one is pretty bad.
First of all, Log4j is a ubiquitous logging library that is very widely used by millions of computers. Second, the director of the U.S. Cybersecurity & Infrastructure Security Agency (CISA) says this is the most serious vulnerability she has ever seen in her career spanning decades, and many security experts agree. Third, researchers say that cyberattackers are already exploiting the vulnerability hundreds of times every minute. The fact is, Log4Shell is relatively easy to exploit, so even low-skilled hackers can take advantage.
OK, maybe it is time for alarm.
Log4j is open-source software from the Apache Software Foundation. As explained by The Conversation, this logging library is widely used to record events such as routine system operations and errors, and to communicate diagnostic messages regarding those events. A feature in Log4j allows users of the software to specify custom code for formatting a log message. This feature also allows third-party servers to submit software code that can perform all kinds of actions – including malicious ones – on the targeted computer. The result of an exploit for the bug is that an attacker can control a targeted server remotely.
Attackers Took Early Advantage
Within weeks of discovery of the flaw in mid-December, it was already reported that nation-state actors linked to North Korea, China, Iran and other countries had created toolkits for mass-exploiting this vulnerability quickly. Log4Shell also became a darling of the ransomware and botnet gangs operating around the globe. A real danger in this flaw is that there are so many ways to exploit it for malicious purposes.
How prevalent is Log4j in business systems? Analysis by Wiz and Ernst & Young of more than 200 enterprise cloud environments with thousands of cloud accounts showed that 93 percent of those environments are at risk from the vulnerability.
Google researchers discovered that more than 8 percent of all packages on Maven Central, a large Java package repository, have at least one version that is impacted by this vulnerability—an “enormous” amount by all standards of ecosystem impact.
So, yeah, that’s pretty extensive presence of this vulnerability. As for the global impact, it’s still too early to tell. Much will depend on how well organizations respond to the threat.
Everyone Must Take Action
For everyone affected by this, there is both a business and moral imperative to take immediate steps to mitigate the vulnerability if it exists within public-facing systems. Naturally, no business wants its systems to be vulnerable to an attack that can lead to the corruption or theft of data and the potential for severe business disruption.
As for the moral imperative, the Federal Trade Commission points out that companies have a responsibility to take steps “to reduce the likelihood of harm to consumers.” With the fallout from the Equifax breach still fresh in memory, the FTC warns that it “intends to use its full legal authority to pursue companies that fail to take reasonable steps to protect consumer data from exposure as a result of Log4j, or similar known vulnerabilities in the future.” Not every company serves consumers, of course, but that shouldn’t matter with regard to addressing this issue.
CISA issued a list of “immediate actions” that organizations must undertake to remediate the risks posed by Log4Shell. The top action is to understand the extent of the problem by identifying which of your assets use the Log4j software and then apply an appropriate patch. Stop the bleed, so to speak.
After that, you must assume you have already been compromised, hunt for signs of malicious activity within your systems, and continue to monitor for odd traffic patterns or behavior that could be indicative of an ongoing attack.
It’s essential to detect the threat activity as the vulnerability is exploited or as attackers successfully insert themselves into your environment. This is where the efficacy of your security tools is put to the test.
How Effective Are Your Security Tools?
Security tools that are dependent on traditional rule-based detection and pattern matching may have easily caught some of the commands being executed by injected malware in the early days of this exploit. However, as variants of Log4Shell hit the wild with better execution tactics, traditional security information and event management (SIEM) and extended detection and response (XDR) tools may struggle to identify attacks unless tool vendors make very frequent updates to the rule base. And that just isn’t practical. Taking a layered security approach that includes some advanced detection methods such as machine learning, artificial intelligence and behavior analytics will also be crucial.
Every organization should have a mitigation plan in case something like this comes up again in the future. Whether it be to shut down the offending piece of software, or immediately patch it and test the patch before it goes back into production, teams need to be prepared for a proactive response within hours or even minutes.
Log4Shell is a wake-up call for everyone. We shouldn’t hit the snooze button until the next vulnerability comes around.
Saryu Nayyar is CEO at Gurucul.
Enjoy additional insights from Threatpost’s Infosec Insiders community by visiting our microsite.
