The Log4j vulnerability continues to current a significant menace to enterprise organizations one yr after the Apache Software Foundation disclosed it final November — despite the fact that the variety of publicly disclosed assaults focusing on the flaw itself has been lower than many might need initially anticipated.
A excessive share of methods nonetheless stay unpatched towards the flaw, and organizations face challenges to find and remediating the difficulty after which stopping the flaw from being reintroduced into the surroundings, safety researchers say.
“The undeniable fact that Log4j is utilized in [nearly] 64% of Java functions and solely 50% of these have up to date to a completely mounted model means attackers will proceed to focus on it,” says David Lindner, CISO at Contrast Security. “At least for now, attackers proceed to have a discipline day to find paths to use by way of Log4j.”
Multiple Attacks But Fewer Than Expected
The Log4j flaw (CVE-2021-44228), generally known as Log4Shell, exists in Log4j’s Java Naming and Directory Interface (JNDI) operate for knowledge storage and retrieval. It offers distant attackers a trivially simple solution to take management of susceptible methods — an issue provided that Log4J is utilized in nearly each Java utility surroundings. Security researchers contemplate it as one of the vital vulnerabilities lately due to its prevalence and the relative ease with which attackers can exploit it.
Over the previous yr, there have been quite a few studies about menace actors focusing on the flaw as a solution to acquire preliminary entry right into a goal community. Many of those assaults have concerned nation-state-backed superior persistent menace (APT) teams from China, North Korea, Iran, and different nations. In November, for example, the US Cybersecurity and Infrastructure Security Agency (CISA) warned about an Iran-government-backed APT group exploiting the Log4j vulnerability in an unpatched VMware Horizon server to deploy cryptomining software program and credential harvesters on a federal community.
The warning was just like one from Fortinet in March about Chinese menace actor Deep Panda utilizing the equivalent vector to deploy a backdoor on course methods and one other from Ahn Labs about North Korea’s Lazarus Group distributing its personal backdoor the identical means. Others akin to Microsoft have additionally reported observing state actors akin to Iran’s Phosphorous group and China’s Hafnium menace actor utilizing Log4 to drop reverse shells on contaminated methods.
Despite such studies — and several other others about financially motivated cybercrime teams focusing on Log4j — the precise variety of publicly reported compromises involving Log4 has remained comparatively low, particularly when in comparison with incidents involving Exchange Server vulnerabilities like ProxyLogon and ProxyShell. Bob Huber, chief safety officer at Tenable, says the dimensions and scope of reported assaults have been surprisingly decrease than anticipated, contemplating the simplicity of the vulnerability and the assault path. “Only lately have we seen some vital proof of focusing on, as famous by latest nation state exercise from CISA,” Huber says.
Undiminished Threat
However, that doesn’t imply the menace from Log4j has diminished over the previous yr, safety researchers word.
For one factor, a big share of organizations stay as susceptible to the menace as they have been a yr in the past. An evaluation of telemetry associated to the bug that Tenable lately carried out confirmed 72% of organizations have been susceptible to Log4j, as of Oct. 1. Tenable discovered that 28% of organizations globally have absolutely remediated towards the bug. But Tenable discovered that organizations which had remediated their methods typically encountered Log4j repeatedly as they added new property to their environments.
In many cases — 29%, in actual fact — servers, Web functions, containers, and different property grew to become susceptible to Log4j quickly after preliminary remediation.
“Assuming organizations construct the repair into the left facet of the equation — throughout the construct pipeline for software program — charges of reintroduction ought to diminish,” Huber says. “Much of the speed of reintroduction and alter relies upon drastically on a corporation’s software program launch cycle.”
Also, regardless of virtually ubiquitous consciousness of the flaw inside the cybersecurity neighborhood, susceptible variations of Log4j stay vexingly laborious to seek out at many organizations due to how functions use it. Some functions would possibly use the open supply logging element as a direct dependency of their functions, and in different cases an utility would possibly use Log4j as a transitive dependency — or a dependency of one other dependency, says Brian Fox, CTO at Sonatype.
“Since transitive dependencies are launched out of your direct dependency decisions, they might not all the time be recognized or instantly seen to your builders,” Fox says.
In many instances, when the Apache Foundation first disclosed Log4Shell, firms needed to ship out 1000’s of inner emails, gather leads to spreadsheets, and recursively scan file methods, Fox says. “This price firms useful time and sources to patch the element and extended the magnitude of the vulnerability’s malicious impact,” he says.
Data from the Maven Central Java repository that Sonatype maintains exhibits that 35% of Log4 downloads at present proceed to be of susceptible variations of the software program. “Many firms are nonetheless making an attempt to construct their software program stock earlier than they’ll even start a response and are unaware of the implications of transitive dependencies,” Fox says.
Because of the entire points, the US Department of Homeland Security overview board earlier this yr concluded that Log4 is an endemic safety threat that organizations might want to cope with for years. Members of the board assessed that susceptible cases of Log4j will stay in methods for a few years to come back and put organizations susceptible to assault for the foreseeable future.
The One Positive Outcome
Security researchers monitoring the bug say that the optimistic fallout from Log4j is the heightened consideration it has drawn to practices akin to software program composition evaluation and software program invoice of supplies (SBOM). The challenges that organizations have confronted simply figuring out whether or not they’re susceptible or the place the vulnerability would possibly exist of their surroundings has fostered a greater understanding of the necessity for visibility into all of the elements of their codebase — particularly these from open supply and third-party sources.
“The investigation into the Log4J concern has reaffirmed the necessity for higher software program provide chain attestation along with SBOMs that sustain with the pace of DevOps,” says Matthew Rose, CISO at ReversingLabs. “Application safety and structure groups have realized that simply on the lookout for threat in components of the applying like supply code, APIs, or open supply packages will not be sufficient. They now understand {that a} full understanding of the applying’s structure is simply as vital as discovering SQLI or cross-site scripting bugs (XSS),” he says.