The technology world is entering a new phase where code complexity and widespread use of global software tools have opened the door for a damaging security flaw that can last for years.

The enterprise community received a preview of this in 2012 when a security flaw was introduced in an update for OpenSSL, a popular cryptography library. The vulnerability became known as Heartbleed, which weakened security for common internet communication protocols, such as SSL and TSL. The Heartbleed bug has proved difficult to eradicate, and cybersecurity vendors continue to deal with vulnerabilities in OpenSSL.

“Software remains vulnerable,” Chris Krebs, former director of the Cybersecurity and Infrastructure Security Agency, said in an August keynote address during the Black Hat USA 2022 conference in Las Vegas, covered by SiliconANGLE. “Companies that are shipping products are shipping targets. If you are hosting a service, you are the target.”

Big moment in security

The latest security flaw to show signs of longevity is Apache Log4j. The Java-based logging tool is used in many software packages, and a vulnerability was first publicly disclosed in December through a Tweet from the Alibaba Cloud Security team. The security threat was quickly assigned a 10 on a scale of 10 by the National Vulnerability Database.

The urgency to fix Log4j is driven by a simple fact: Its distribution is massive. One software security company has calculated that it is in the top .003 percentile of software tools in terms of popularity. In the aftermath of the Log4j disclosure, cybersecurity firm Lacework Inc. noted that more than 3 billion devices run on Java and “attackers are trying to compromise every one.”

When the White House ordered the creation of a Cyber Safety Review Board in 2021, it did so with an understanding that the group would focus on recommendations for avoiding another SolarWinds breach, a troublesome compromise of the software supply chain that began in 2020. However, the CSRB pivoted in February and announced that it would immediately focus its attention on Log4j.

“Log4j was a big moment for all of us,” said Heather Adkins, deputy chair of the CSRB and senior director for security at Google LLC, who appeared during a Black Hat conference session in August. “You will see malicious actors innovate in how they implement this.”

Containing the damage

Public disclosure of the Log4j vulnerability in mid-December was akin to publishing a map to the bank vault with instructions for how to open the door. Security monitoring services and researchers quickly saw threat actors launch millions of attempts per hour to exploit the software flaw. VMware Inc.’s NSX Network Detection and Response unit reported more than 25 million exploit attempts against the Log4j tool.

It appears that the damage has largely been contained so far. The CSRB released a report in July that indicated government systems had not sustained significant damage as a result of the vulnerability. The Log4j exploit has been attributed to a Fintech attack, a compromise at the Belgian defense ministry, and distribution of the Dridex banking trojan.

Of greater concern has been the difficulty for enterprises to apply a fix. A July report from CyCognito Inc. found that 70% of firms in a subset of companies examined that had previously addressed Log4j were struggling to patch vulnerable assets and prevent a recurrence. Twenty-one percent of organizations in the report experienced triple-digit percentage growth in the number of exposed vulnerable assets.

“The vast majority of companies are in a worse situation than they were in January,” said Rob Gurzeev, co-founder and chief executive of CyCognito, in an exclusive interview with SiliconANGLE. “Log4j is so easy to exploit.”

Need for software inventory

The problems with Log4j have renewed calls for a software bill of materials. Some enterprises are encountering difficulty with fixes for Log4j because it is hard to know precisely where the tool has been deployed. Having an inventory of software ingredients would presumably go a long way toward identifying the points of greatest vulnerability.

The SBOM movement has been gaining traction over the past year. In 2021, the White House issued an Executive Order that called for wider use of SBOMs. Officials in the Cybersecurity and Infrastructure Security Agency and the Food and Drug Administration have expressed support and urged government branches to implement a wide range of software supply chain security practices.

The enterprise world is warming up to the SBOM as well, although perhaps not as quickly as the public sector. According to a report from the Linux Foundation, 78% of organizations surveyed expect to produce or consume SBOMs this year, but only 47% are actively using them.

“Log4j is a function used in thousands of Java applications,” said Allie Mellen, senior analyst, Security and Risk, at Forrester Research, in an interview with SiliconANGLE for this story. “Without an accurate inventory of where the function is used, it can be very challenging to track down every single application it is used in in the enterprise.”

Active exploits

In recent months, there has been evidence that threat actors are gathering around a new malware tool to exploit the Log4j vulnerability. Identified as “B1txo20” by practitioners at Qihoo 360’s Network Security Research Lab, the malware attacks Linux ARM and devices with x64 CPU architecture. It’s a botnet that can exfiltrate data to and from command and control servers.

“Though the headlines may have died down, Log4j is still being actively exploited by threat actors,” Mellen said. “Enterprises should patch their systems immediately to protect their organization against threat actors looking to exploit this vulnerability.”

Because Log4j is so widely used in the computing world that the tool’s vulnerability has led to sobering estimates for how long it might take to fully mitigate the risk. At the Log4j session during Black Hat, Robert Silvers, undersecretary for Policy at the Department of Homeland Security, surprised some in the audience with a declaration that organizations would be dealing with issues from the vulnerability for at least the next 10 years.

Predictions such as these raise the question of whether enterprises will continue to embrace open-source tools so freely given the inherent risk now seen in community-supported code. Forrester’s Mellen believes this serves as a much-needed reminder that companies need to contribute to the open-source ecosystem even more.

“Hopefully, this will be another example of why investing in and supporting open-source software is so important,” Mellen said. “Enterprise software stands on a foundation of open-source software, but is rarely supported with resources at the same level. This should serve as another example of why open-source software is important and why supporting open-source software is so crucial.”

Image: D3Damon/Getty Images