Why Fixing the Log4j Flaw Will Take a Lot of Work

You may have heard about the easily exploitable vulnerability found in Log4j, a widely used, open-source logging utility used to track software activity. Because of its wide distribution, this is likely to present many cybersecurity headaches for quite a long time.

First, the background. The Log4j utility is an open-source Java library maintained by the nonprofit Apache Software Foundation. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) estimates that hundreds of millions of devices are likely affected by the vulnerability, which has almost half a million downloads from its GitHub Project page. Specifically, the Log4Shell vulnerability has impacted version 2.0 through version 2.14.1 of Apache Log4j. It is highly recommended that organizations quickly update to version 2.15.0.

In order to respond to the flaw, cybersecurity practitioners are responding with fixes and detailed methods to identify and patch the software in affected devices. But the scale and serious nature of the problem is likely to require organizations to implement a detailed and arduous response plan.

CISA Responds to Attacks

The Hacker News reports that ransomware groups are already attempting to monetize the vulnerability. It states that a Romanian cybersecurity company had documented attempts “to target Windows machines with a novel ransomware family called Khonsari as well as a remote access Trojan named Orcus by exploiting” the Log4j vulnerability.

CISA has taken a particularly active role in coordinating public and private sector response to this threat. On Monday the director of the agency led a phone briefing for industry leaders in which she called the vulnerability as one of the most serious she had seen in her career. CISA’s recommendations are straightforward but will no doubt take organizations time to implement given the pervasiveness of Log4j in the wild. CISA recommends three immediate steps regarding this vulnerability:

1. Enumerate any external-facing devices that have Log4j installed.
2. Make sure that your security operations center is actioning every single alert on the devices that fall into the category above.
3. Install a web application firewall (WAF) with rules that automatically update so that your SOC is able to concentrate on fewer alerts.

Identify, mitigate, and patch. That's good advice but it is often easier said than done, especially when tracking down software libraries that could eventually be found in some unexpected places.

Chris Wysopal, the CTO of application security firm Veracode, emphasized that point in a recent webinar discussing the flaw: "There might be applications that you have good visibility into and you find rather quickly, but it is challenging to find all your Java applications,"said Wysopal.

He brought up another important concern, the fact that many vendor applications are also written in Java. “A lot of appliances, a lot of packaged software use Java, so I would expect that people are going to be asking their vendors when they're going to be patched," said Wysopal.

Cybersecurity Vendors Must Move Quickly

CISA makes a similar point and has urged vendors to move quickly, noting: “End users will be reliant on their vendors, and the vendor community must immediately identify, mitigate, and patch the wide array of products using this software. Vendors should also be communicating with their customers to ensure end users know that their product contains this vulnerability and should prioritize software updates."

So, perhaps more than usual, the speed at which organizations can fully patch their assets is not completely under their control. That said, asset management and vulnerability management remain critical components of good security hygiene and will speed the process.

CISA and other organizations have several online assets to help organizations find the remediation resources they need for their particular production environments and to otherwise keep up to date on the vulnerability and evolving exploits. Here are a few:

• CISA’s Known Exploited Vulnerabilities Catalog
  
• CISA’s Log4j Vulnerability Guidance (This page is being continually updated but already include links to mitigation guidance from Microsoft, Cisco, Palo Alto, CrowdStrike, IBM, Tenable, Broadcom’s Symantec, Splunk, and VMware.)

• CISA’s Log4j Github page
• CVE page for CVE-2021-44228 (Log4j)
• NIST page for CVE-2021-44228 (Log4j)

The bottom line is that the Log4j vulnerability is going to be with us for quite some time and is going to require fast and detailed cooperation among the cybersecurity vendors, organizations like CISA, and practitioners.