SHARED INTEL: Log4j vulnerability presents a gaping attack vector companies must heed in 2022

By Byron V. Acohido

As we close out 2021, a gargantuan open-source vulnerability has reared its ugly head.

Related: The case for ‘SBOM’

This flaw in the Apache Log4J logging library is already being aggressively probed and exploited by threat actors — and it is sure to become a major headache for security teams in 2022.

“This vulnerability is so dangerous because of its massive scale. Java is used on over 3 billion devices, and a large number of those use Log4j,” says Forrester cybersecurity analyst Allie Mellen, adding that crypto miners and botnet operators are already making hay.


“We can expect more devastating attacks, like ransomware, leveraging this vulnerability in the future,” Mellen adds. “This vulnerability will be used for months if not years to attack enterprises, which is why security teams must strike while the iron is hot.”

This Log4j vulnerability was disclosed to Apache on Nov. 24 by the Alibaba Cloud Security team. Then on Dec. 9, the vulnerability, formally designated CVE-2021-44228, was disclosed on Twitter; meanwhile a  proof-of-concept exploit got posted on GitHub.

This flaw in an open-source web server software used far and wide  puts open-source risks in the spotlight – yet again. Companies will have to deal with Log4J in much the same manner as they were compelled to react to the open source flaws Heartbleed and Shellshock in 2014.

Simple text hacks

Over the past two decades, Java has come into use in apps of every type, spanning just about every industry. Like countless other open-source components, the Log4j library has been deeply embedded into business networks far and wide, including apps such as Apple iCloud, Steam, Samsung Cloud storage.


“Log4Shell is one of the worst vulnerabilities we have ever seen. It can impact businesses, governments, and consumers directly, and it will be exploited for months to come,” says  Nicholas Sciberras, head of engineering at Invicti’s Acunetix. “It’s powerful, ubiquitous, and easy to use – the ultimate hack for someone who wants to do something malicious – even without sophisticated knowledge.”

A Log4J exploit can take the form of a simple text string that can be inserted into a simple header or any kind of text field, Sciberras notes. It requires no authentication, tricks, or jumping from server to server.

“Java is one of the most popular languages for web applications, mobile applications – practically everything,” he says. “Log4j is a library used in nearly every Java installation because it is used for logging server operations. Many applications also keep logs for debugging purposes.”

SBOMs to the rescue

This attack vector provides a useful new path for any threat actor, even ones with limited skills, to extract sensitive data, upload files to the server, delete data, install ransomware, or pivot to other servers, Sciberras observes.

Organizations that fail to take steps to mitigate this risk could pay a steep price. The ones that do take heed will have to gain visibility of their deployed use of Log4J and then take steps to upgrade or replace this vulnerable open source library, which will be no small task.

“It’s becoming clear that organizations must adopt processes to build Software Bills of Materials for every application they deploy,” Sciberras opines. “They can then use SBOMs to help them focus incident response actions following a zero-day vulnerability announcement such as Log4Shell. Given the widespread use of open-source and other third-party components in modern applications, SBOMs are a foundational element of cyber resilience.”

SBOMs are the computing world’s version of bill-of-materials: a tried-and-true quality assurance best practice practiced in the engineering profession for decades. President Biden made a push for wider use of SBOMS in his cybersecurity executive order issued last spring.

Securing runtime

If Log4Shell helps accelerate wide adoption of SBOMs, that will be a very good thing.

In the short run, however, companies will have to do a lot more. They’ll have to take direct steps to counter rising Log4Shell exploits, predicts Jeff Williams, co-founder and CTO of Contrast Security.

Specifically, companies much get much more adept at mitigating advanced attacks utilizing malware that executes in runtime, then vanishes.


“SBOMs will help to create transparency around library use and encourage keeping them up to date,” Williams told me. “Longterm, companies will need runtime protection to detect and block extensible, novel attacks. They’ll want to push back into the development process with great tools to manage your software supply chain – and push even farther ‘left’ to help developers prevent the coding patterns that lead to these attacks, in this case, log-injection hacks.

Once again, an expansion of the threat landscape is adding urgency for companies to do triage. I’ll keep watch and keep reporting.


Pulitzer Prize-winning business journalist Byron V. Acohido is dedicated to fostering public awareness about how to make the Internet as private and secure as it ought to be.

Share on FacebookShare on Google+Tweet about this on TwitterShare on LinkedInEmail this to someone