As highlighted in our December 10, 2021, article, the Apache Log4j vulnerability is garnering significant attention throughout the public and private sectors. There are reportedly upwards of 100 million devices and servers affected by the security flaw. The software has broad use in a variety of consumer and enterprise services, websites and applications, as well as in operational technology products. The exploit is said to be easy to mimic and install; there are apparently already online instructions and sample code enabling would-be malign actors, too.

According to a recent statement from the Director of the Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA), there has been “active, widespread exploitation” of the identified vulnerability. This is consistent with media reports that ransomware threat actors—as well as advanced persistent threat (APT) groups with links to the governments of Iran, Turkey, North Korea and China—are exploiting the flaw. CISA has deemed the vulnerability critical, directed all civilian federal agencies to “urgently patch or remediate” it and “signal[ed]” that non-federal partners follow suit.¹ The FBI is requesting that Log4j victims report to its Internet Crime Complaint Center (IC3.gov) as much information as possible to assist the FBI and CISA in determining prioritization for outreach.

IN DEPTH

The situation continues to develop rapidly, with Apache issuing a second Log4j-related Common Vulnerabilities and Exposures (CVE) disclosure and releasing a new update on December 13, 2021. Companies that updated Log4j to version 2.15.0 will need to immediately implement version 2.16.0, as the prior version is no longer deemed secure.

Additionally, threat actors are developing new methods to evade the original mitigation techniques deployed at the network level. Companies are advised to continue monitoring the situation in the coming weeks and months as new patches are released—both for Log4j and applications that incorporate Log4j—and additional exploit signatures become available for web application firewalls (WAFs), intrusion prevention and detection systems (IPS/IDS) and endpoint protection software.

The risk from Log4j is not limited to a company’s own systems and networks. Companies should look beyond their own environments to assess whether, and to what extent, their vendors and their vendors’ vendors are using the Apache Log4j library, prioritizing those vendors with access to company systems and data. The following are some initial considerations and issues that a company might explore with its vendors (and of itself if not already done):

• Whether the vendor has conducted a vulnerability assessment to identify if they have potentially been impacted by Log4j (including the vendor’s systems and their software products or services, as well as those of their vendors);

• Whether the vendor uses Log4j in any way in its systems or software products;

• If the vendor uses Log4j, whether it has made the required patches and updates and/or completed other recommended remediation measures to address the vulnerability in their systems and software products;

• If the vendor uses Log4j, a description of the controls it has implemented to mitigate additional risk posed by this vulnerability;

• Whether the vendor is conducting daily (if not more frequently) searches of the regularly updated lists of known vulnerable vendors and applications (e.g., https://github.com/NCSC-NL/log4shell/tree/main/software) to identify whether the vendor uses any of those vulnerable vendors or applications;

• Whether the vendor has discovered any indicators of compromise (IoCs) related to Log4j within their environment or the environment of their vendors; and

• Whether the vendor has a point of contact who can answer additional questions.

The questions above are intended to provide companies with considerations for itself and conversations with vendors, as well as to assist vendors with the inquires they are likely to receive. Unfortunately, the types of vendors a company should consider querying may be quite broad; these vendors may include a company’s cloud providers, software product providers, managed service providers, outsourcing vendors, and practically anyone with access to a company’s networks, systems or data. Seemingly small devices (e.g., IoT devices like network printers and cameras) may be in scope for this review.

Companies also should consider engaging forensics experts to help track down and validate the answers to these questions and monitor their systems over the coming days, weeks and months as more becomes known about the pace and characteristics of this threat. Additional patching may be required for Log4j and applications that use this popular library as security researchers test the latest versions for additional vulnerabilities. The scrutiny is not just limited to Log4j; security researchers, and likely threat actors, are reportedly turning to other popular open-source products to test them for vulnerabilities.

As the latest developments show, the full impact of the Log4j vulnerability has yet to be determined. Organizations, regardless of size and sector, need to remain on guard, vigilant in their remediation, and prepared for potential exploits within their own environments and throughout their supply chains.

¹ CISA has created an Apache Log4J Vulnerability Guidance webpage and is maintaining a community-sourced GitHub repository that provides a list of publicly available information and vendor-supplied advisories regarding the Log4j vulnerability.