The Log4j vulnerability, tagged as CVE-2021-44228, was publicly disclosed on December 10, 2021. Described as one of the most widespread vulnerabilities of all time, it triggered an all-hands on deck response. Following months of heads-down efforts by the infosec community, what’s the state of this vulnerability today?

The US Cybersecurity and Infrastructure Security Agency (CISA) summarized the Apache Log4j vulnerability as “very broadly used in a variety of consumer and enterprise services, websites, and applications – as well as in operational technology products – to log security and performance information. An unauthenticated remote actor could exploit this vulnerability to take control of an affected system.”

Attacks attempting to exploit the Log4j vulnerability spiked in the early days following the initial public announcement. In the first 72 hours, security researchers reported over 830,000 attacks, or more than 100 per minute. Despite this initial onslaught, however, the pace of attacks had slowed by January. In a mid-month briefing, CISA director Jen Easterly said they were not aware of any significant incident due to the Log4j vulnerability, and, at the time of this writing, none have been reported subsequently.

Quick action by companies including Apache to create and deploy fixes may have helped in limiting the damage so far. The US government also played an important role. CISA provided information and guidance on mitigating Log4j and made available for public use a database of vulnerable software as a reference source. To compel companies to act swiftly, the FTC, issued stern guidance in February that it may take enforcement actions against businesses that fail to appropriately patch all of their Log4j instances.

But it’s unlikely that we’ve heard the last of Log4j. Even as late as March, cybersecurity company, Qualys, found that nearly one-third of Log4j instances remain vulnerable to exploitation. One problem is that detecting Log4j is not always so simple. Within packaged software, Java files like Log4j can be nested layers deep in other files or can be packaged in ways that create challenges for tools trying to keep up with all the packaging formats.  If a company is able to detect Log4j in third party software, they have to wait for the software vendor to issue a patched release and they must make certain they are not using an outdated version of the software that might circumvent the patch.

Other concerns about Log4j have been raised recently concerning vulnerability of enterprise data lakes and potential AI contamination. Zectonal, a cloud data security specialist, has shown that the Log4j can be used by an attacker to poison a data lake. The attacker embeds a string of text within a malicious big data file payload to open a shell inside the data lake. The file bypasses application firewalls and scanning devices and is often encrypted or compressed, making detection even more difficult. Once in, the data-poisoning attack can be launched. Obviously, the consequences of using corrupted data for AI and machine learning applications can be devastating, so the damage from attacks of this type can be severe.

Late last year, CISA Director Jen Easterly famously said that the Log4j security flaw was the worst she had seen in her career and that, “we do expect Log4Shell to be used in intrusions well into the future.” While the damage from Log4j in the first six months has been relatively minor, given the ubiquity of Log4j and the insidious nature of a very simple-to-use remote code execution vulnerability, it’s likely that Ms. Easterly may still be proven right.

Fortunately, it’s also likely that Log4j will drive cybersecurity companies and users of open-source code to redouble their efforts to scan open-source packages for both integrity and security before they are approved for use in products. Companies like Phylum, for example, are helping in these efforts by applying innovative technologies to ensure software supply chain security automating threat detection through the application of advanced heuristics and machine learning methods.

At BlueWing, we understand the increasingly challenging cybersecurity threat landscape and actively support those working toward solutions.

For those companies with continued potential exposure to Log4j, we recommend reviewing CISA’s list of immediate actions to mitigate Log4j exploitation, available at: https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance.