Newsroom

The Log4Shell Zero-Day Exploit: A Quick Review

December 17, 2021

What a start to the holidays…

If you’re a Network Admin or a CISO, chances are you’ve already put in several hours dealing with the Log4Shell vulnerability. For anybody looking to get a quick overview of what this vulnerability is about and how to protect against it, please read on!

Where Did This Come From and Who Does it Affect?

Log4j is a Java-based logging tool developed by the Apache Foundation that’s widely used in business system development to record log information. Developers may write error messages caused by user input into the log, for example. However, attackers can use this feature to create special request packets through this vulnerability and ultimately trigger remote code execution.

The Log4Shell or “LogJam” zero-day exploit lets an unauthenticated attacker inject text into log messages to execute arbitrary code loaded from malicious servers. While it was first discovered by Alibaba Cloud’s security team on November 24^th, it took until December 9^th for the first reports of exploitation to emerge. As so often happens, these exploits started to crop up at almost the exact time the vendor addressed the issue (Apache released a patch for the vulnerability on December 10).

Back in November when Alibaba’s team first reported this vulnerability to Apache, they also revealed that Log4Shell impacts default configurations of multiple Apache frameworks. These include Apache Struts2, Apache Solr, Apache Druid, Apache Flink, and others.

What It Does

The Log4Shell issue is one of the worst vulnerabilities we’ve seen in a long time and may turn out to be among the most impactful vulnerabilities ever, potentially enabling a complete takeover of any systems running Log4j 2.0-beta9 up to 2.14.1.

Apart from some games like Minecraft, very few home applications still use Log4j, but it’s still widely used by both enterprise apps and cloud services. These include web apps and products from Apple iCloud, Amazon, Twitter, and Steam, all of which are likely susceptible to RCE exploits targeting this vulnerability.

We’re almost certain that the list of vulnerable products will grow rapidly over the coming weeks, and because this is a wormable vulnerability (in the same manner as WannaCry and Blaster), we fear it will be used inside networks very soon.

What You Can Do About It

We recommend organizations take an approach based on these five steps:

Identify and prioritize all instances of Log4j in your environment (be diligent; there are likely more than you realize)
Patch, disable, or remove Log4j where possible
Block outbound Internet by default, proxy and inspect permitted traffic
Monitor for evidence of attacks and compromised systems
Leverage intrusion prevention technologies where possible

A number of website scanning tools are available to help you begin the process and there are also public tools for parsing file systems to look for the vulnerable classpath.

Blocking all outbound traffic from public-facing systems is a good first step at mitigation. There are also ways to disable this functionality depending on application needs.

To patch Log4j itself, you can download the latest version here. We also recommend upgrading the applications and components that are known to be affected, such as srping-boot-strater-log4j2/Apache Solr/Apache Flink/Apache Druid.

This situation is unfolding very quickly, and if you’re feeling overwhelmed, iON can help. We can assist with turning the five steps above into specific remediation tasks and help you prioritize them. Contact your iON representative or reach out to us here.