As the reality sets in over implications of the Log4j vulnerability, security staff have hunkered down to quickly remediate the problem. The question now is whether that sprint will be followed by a marathon.
Experts who spoke to SC Media estimated months to years of finding new instances of this vulnerability across enterprises and vendors.
"This is now a permanent part of the landscape," said Chris Wysopal, co-founder and chief technology officer of Veracode.
"I look at it as a classic iceberg," said Michael White, technical director and principle architect with Synopsys. "There are 3 billion devices that run Java and Log4j is a very common logging library. Most if not all applications will need to do some kind of logging. This will be prevalent in places where we may not expect."
Log4j is one of the most popular packages for Java, which in turn is one of the most popular languages. It provides a logging functionality that is useful in a variety of different contexts and impacted vendor products have already been broad. They range from Minecraft to Tesla to VMware.
Historically, there have not been many vulnerabilities as pervasive and dangerous as Log4j. To find another, you would have to go back to some of the foundational internet vulnerabilities that appeared around 2014: Shellshock and Heartbleed.
Those were still being found and exploited years after discovery.
"Shellshock is old and decrepit, ancient, but still, somehow in some places sticks around," said John Hammond, senior security researcher at Huntress Labs. " And I think this one is a little bit more sinister."
Huntress Labs works with a large managed service provider clientele, which Hammond said are currently "sitting on their hands" waiting for vendors to finish analyzing products for vulnerabilities and to acknowledge which were vulnerable. In the short term, that leaves some holes in what they can remediate. Furthermore, as reported by sister brand ChannelE2E, the concern in the MSP software market basically parallels the Kaseya VSA REvil attack from July 2021: if one MSP software platform gets hit, portions of the broader MSP service provider and SMB customer supply chain ecosystem could get hit.
"We often say it, but it matters now more than ever: Hold your vendors accountable," he said.
Allie Mellen, an analyst at Forrester, said a continuing dialogue with vendors could do just that.
"In the short term, enterprises and trade teams should be expecting vendors to be proactively communicating with them about the status of their offering and whether or not they are vulnerable," she said. "In the longer term, both sides might need better awareness of software bills of materials."
There are two sources of potential third-party risk that will come out of the Log4j. There are a wide assortment of products that use Log4j, which, if they lose the race to patch before malicious actors begin to exploit, will create risk in their enterprise users. But there is also a risk that affected vendors have been breached currently using Log4j with actors looking to leverage access to products and business data for subsequent attacks.
Wysopal said the former is a real risk in the short term.
"I've also heard people saying they have devices on their organization running Java, that they know are running Log4j. But it's an internal device that is managed by a vendor, and it only talks to the vendor network. That sounds like a perfect supply chain attack," he said.
During Heartbleed, vulnerabilities in vendor products lasted for years. There is some optimism that with nearly a decade of industry maturity and the widespread publicity Log4j has garnered, such longevity won't happen this time around. Matt Olney, director of threat intelligence for Cisco Talos Labs said he thought the other kind of third-party risk, where sleeping actors will pop up later, may be of greater concern.
Talos tracks a very consistent pattern of exploration following the release of vulnerabilities.
"We always see the coin miners and Mirai botnet first out of the gate in terms of early adopters," he said. "They always seem to be there on day one as soon as something new comes out. Then other actors who are more concerned about stability and being quiet take another few days to catch up. The more dangerous actors, more interested in espionage or financial gain, come in on the back end,” he said.
"The first couple of three weeks is going to be working our way through the attacker spectrum, while the defenders race to understand what's happening and patch aggressively at the vendor level," he added.
Indeed, very quickly out of the gate, 360 Netlab reported two botnets, including Mirai, that already adopted the Log4j vulnerability. Olney said attackers more concerned about stealth, including ransomware actors who need more dwell time to exfiltrate files and set up, take longer to prepare to use any new mechanism.
One of the reasons that several researchers believe Log4j is a long-haul vulnerability is that its use is nested throughout an organization and the lifespan of data. The quantity of assets that need patching, the management of assets to know what needs patching, and the likelihood of noticing when assets slip through the cracks are all cause of concern.
"Some of the vulnerable apps are for batch processing and run on a nightly basis, or every so many hours," said Wysopal. "People are saying they would try the exploit against a target. And then they would see it work like four or six hours later."
Regardless of the duration, much of the danger is upfront. Successful mitigation will rely on beating an attacker in a footrace. The general consensus is clear: this is a vulnerability that can cause havoc if not treated seriously.
"It's bad," said Olney. "It's real bad."
