Log4j: Is your organization prepared for the next critical 0-day vulnerability?

In December 2021, the announcement of a Log4j vulnerability became a wake-up call for software vendors around the world. Organizations around the world needed to look for the log4j component in all their applications and make sure they had a plan of action in place to keep their users safe. Failure to do so could have devastating results. Many have gone so far as to say that the impact of Log4j could be even more severe than the infamous 2017 Equifax hack.

What is the Log4j vulnerability?

On December 9, the first announcements of the vulnerability came out. CVE-2021-4228, is an open source logging component used in numerous applications. Popular frameworks such as Apache include Log4j, making it ubiquitous in major technology players and their software. CBS News said, of the impact, that “the list of potential victims spans nearly a third of all web servers worldwide.”

The vulnerability is especially critical because it is simple to exploit. According to Sonatype, “This is a low-qualification attack that is extremely simple to execute. It allows the attacker to execute arbitrary code in any application that is vulnerable and use this capability to execute an attack.”

One of the first organizations to discover the Log4j vulnerability was the popular online game Minecraft. Since Log4j was used to log chat messages within the game, the vulnerability meant that anyone within a public Minecraft server could exploit others within the server by simply typing commands into the chat box.

What happens now?

Now that the world knows about the log4j vulnerability, companies are still working to patch their applications and ensure their users are safe from this catastrophic security flaw.

The Federal Trade Commission issued a stern announcement on January 4: “The FTC intends to use its full legal authority to prosecute companies that fail to take reasonable steps to protect consumer data from exposure as a result of Log4j, or similar known vulnerabilities in the future.”

As the big companies start to release patches and the headlines start to drop the whole issue, we start to breathe a sigh of relief. But, if we don’t come out of this whole situation with better knowledge on how to prevent something similar from happening again, we could be setting ourselves up for an even bigger failure.

Lessons learned from the Log4j vulnerability

One of the biggest lessons from the Log4j vulnerability is that companies need to know what’s inside their software to keep themselves and their customers safe.

Sergio Caltagirone, vice president of threat intelligence at cybersecurity firm Dragos, was interviewed by CBS News and made the analogy, “People are able to say, ‘Am I allergic to peanuts? Does this have nuts in it?’ Now we need to be able to say, ‘This log4j vulnerability has come up. Do I have this in my environment?’”

But how do you have a list of components of an application? It is important to create a software bill of materials (SBOM). Which lists all the component names, license information, version numbers and vendors within each of an enterprise’s applications.

SBOMs enable organizations to quickly respond to questions in critical situations. In a matter of minutes, an enterprise with an SBOM can track known vulnerable components and make informed decisions to safeguard those specific areas of their applications. Not only does an SBOM work in an extreme situation like Log4j, but it also makes it more efficient and easier for development teams to remediate various other vulnerabilities as they build software on a day-to-day basis.

But what’s the next step in building your Software BOM? Our Sonatype partners provide world-class solutions for all aspects of Software Composition Analysis, including building an SBOM.


Find out more here: https://www.sonatype.com/products/vulnerability-scanner

For more information: