United States: The Log4j vulnerability: what this critical vulnerability means for your business
To print this article, all you need to do is register or log in to Mondaq.com.
As companies scramble to fix the newly exploited, pervasive Log4j vulnerability, companies’ actions are now the potential source of government scrutiny. Our privacy, cyber and data security team summarizes what the Log4j vulnerability is and how it is being exploited, the recent Federal Trade Commission warning to take the vulnerability seriously, and published public and private sector guidance on remediation.
- The vulnerability affects versions 2.0 to 2.16 and can enable DoS attacks
- The FTC calls this a “serious risk” and says it will use “its full legal authority” against companies that fail to protect consumers
- General principles and resources that can guide your analysis
Over the past month, the public and private sectors have watched with growing concern as the extent of the Log4j vulnerability has emerged. The best current information about the vulnerability and recommended mitigation actions comes from security firms and the government through the Cybersecurity and Infrastructure Security Agency (CISA). While the vulnerability itself poses significant potential risks to companies and their products, there is now also the potential for enforcement by the Federal Trade Commission (FTC) or other regulatory review of companies that fail to take “reasonable steps” to remediate the vulnerability .
What is the Log4j vulnerability?
Private and public sector partners report that the Log4j vulnerability is the most prolific (or one of the) most prolific vulnerabilities ever reported. The vulnerability resides in a Java-based tool from the Apache open source library that is used to parse logs. The tool essentially provides a logging system for applications to keep a running list of the activities they perform.
The vulnerability was originally thought to affect Log4j versions 2.0 through 2.14.1 as an attacker could have a Remote Code Execution (RCE) opportunity. The RCE could allow the attacker to take full control of the system and then steal information, launch ransomware, or perform other malicious activities. Now it is also known that the vulnerability can also allow denial of service attacks and can affect versions 2.0 to 2.16 to varying degrees.
The vulnerability is widespread as Log4j is widely deployed by enterprise and cloud applications and devices and the affected versions of the applications were released in early 2013. CISA has put together a Github repositoryidentifies potentially affected vendors and software and lists their status (affected, not affected, under investigation or fixed) and whether or not a patch has been released. This list currently includes thousands of vendors and software products, and government sources indicate that the number of entities ultimately touching resources including Log4j could be in the hundreds of millions.
How is Log4j exploited?
While the vulnerability was publicly disclosed on December 9, 2021, the vulnerability appears to have been presented at a black hat conference in 2016. While initial reports of exploitation mostly related to script kiddies who found the vulnerability and dumped Bitcoin mining code on Minecraft servers, there are now reports of follow-up activity, including both nefarious criminal activity and state-sponsored actors. Security firms have reported that many existing attackers have added Log4j-related exploits to their existing malware tools and tactics, and that exploit attempts remained high through the end of 2021.
What is the legal or regulatory risk?
Any significant vulnerability, particularly one that could be exploited to deliver ransomware or potentially provide a launch pad for data exfiltration, can pose potential legal and regulatory risks. But now the FTC has warned companies that it “intends to use its full legal authority” against any company that fails to take “reasonable steps” to protect consumers from the Log4j vulnerability. On January 4, 2022 release, the FTC warns that the Log4j vulnerability is being widely exploited by a growing number of attackers and poses a “serious risk” to millions of consumer products. The FTC is urging companies to “act now” to mitigate threats from the Log4j vulnerability or “similar known vulnerabilities” or risk legal action. Unfortunately, the FTC does not provide guidance on what these “similar known vulnerabilities” might be:
The obligation to take reasonable steps to mitigate known software vulnerabilities is governed by laws including, but not limited to, the Federal Trade Commission Act and the Gramm Leach Bliley Act. It is critical that businesses and their providers that rely on Log4j act now to reduce the likelihood of harm to consumers and avoid legal action from the FTC.
According to the FTC, companies using Log4j should update software packages to the latest version, take steps to identify and remediate this vulnerability, and share information about the vulnerability with relevant third parties with potentially vulnerable consumers. The FTC also encourages companies to consult CISA guidelines for additional mitigation steps. However, the FTC’s statement does not address the fact that many companies will not be able to update or patch their products until a vendor releases updates or provides further guidance, and as the CISA Github repository shows, is the list of products with pending patches significantly.
How can my organization mitigate this vulnerability and the associated risk?
There is no one-size-fits-all approach to the appropriate steps an organization should take to investigate and mitigate the Log4j vulnerability. However, there are general principles and resources that can guide your analysis.
- Understand your risk attitude. Due to the widespread use of Log4j in both front- and back-end systems and applications, it can be very difficult to identify and mitigate all applications, servers, operational technologies and other systems that use Log4j. Additionally, a company may rely on vendors to provide patching services if the Log4j vulnerability is built into one of their products. Nonetheless, organizations should take steps to understand their potential exposure to this vulnerability, including identifying where an organization is deploying Log4j as best as possible and what type of data could be affected if the vulnerability is exploited. To aid in this identification process, CISA has published lists of resources that can be used to identify use of Log4j in an organization’s environment.
- Once you have identified Log4j usage, you should consider published guidance on mitigation steps appropriate for your organization. Once Log4j is identified, both private and public partners recommend patching when you can (several updates from Apache are already available), monitoring when you can, and segmenting any products you can’t patch so there isn’t an outbound Internet access exists. Additionally, these sources also recommend using a web application firewall to block traffic if you are unable to patch and segment. More details on CISA’s guidance and more detailed technical mitigation recommendations are available here.
Ultimately, it can take months or even years to know the full extent of this vulnerability — and to mitigate it. In reality, how each company mitigates this vulnerability needs to be tailored to their operations, as some may have less control or visibility into the systems running Log4j.
The content of this article is intended to provide a general guide to the topic. In relation to your specific circumstances, you should seek advice from a specialist.
POPULAR ARTICLES ABOUT: Technology from the United States