Exploiting Log4j: 40% of Corporate Networks Targeted So Far

The year is set to end with a cybersecurity bang - not a whimper - thanks to the widespread prevalence of the Apache Log4j vulnerability. Security teams have gone into overdrive to try and assess the risk facing their organization due to the software, which is widely used in Java applications.

See Also: Webinar | Identity Crisis: How to Combat Session Hijacking and Credential Theft with MDR

One of the main challenges is that if successfully exploited, the zero-day flaw, designated CVE-2021-44228 and also known as the Log4Shell vulnerability, can be used for remote code exploitation.

Vulnerabilities that offer attackers this capability regularly rank among the most risky flaws, for obvious reasons, and Log4j is no exception. But the sheer prevalence of the flaw makes it especially damaging, as Florian Roth, CTO of Nextron Systems, has noted.

What people seem to miss:
The #Log4Shell vulnerability isn't just a RCE 0day.
It's a vulnerability that causes hundreds and thousands of 0days in all kinds of software products.
It's a 0day cluster bomb. pic.twitter.com/Cij9kK4Cvg— Florian Roth (@cyb3rops) December 11, 2021

Since the flaw became public knowledge Thursday, IT security vendor Check Point Software Technologies reports that attackers have been scanning the internet for exploitable devices at a massive scale.

"We have so far seen an attempted exploit on over 40% of corporate networks globally," it says.

Security firm McAfee Enterprise has been tracking widespread efforts to target the flaw across at least 58 countries. "Although bear in mind we only see the exploit and not the intent," says Raj Samani, its chief scientist.

To fix the problem, Apache on Wednesday released Log4j version 2.15 and urged everyone to immediately update. The new version fixed a flaw, present in versions 2.0 through 2.14.1, via the inclusion of JNDI - for Java Naming and Directory Interface - functionality, which developers made active by default.

On Monday, meanwhile, Apache released a new version of Log4j - 2.16 - that disables JNDI by default.

Experts warn that mitigating the Log4j version 2.14.x problem will be more akin to a marathon than a sprint. That's because Log4j is used by numerous vendors, and many have yet to identify all products at risk or develop and release patches. Once they do, enterprise IT and security teams will need to thoroughly test those patches to ensure they don't break existing setups, before rolling them out to production.

To help, Trend Micro has released a web-based Log4j vulnerability testing tool to help identify any server-based applications that might be vulnerable.

So far, vendors have collectively counted more than 250 vulnerabilities in software frameworks, libraries and products that will require fixes.

'About as Serious as It Gets'

Because of the flaw's ubiquity, the risk it poses is "about as serious as it gets," Cybereason CSO Sam Curry says. While it's too soon to say whether this might rank as the worst vulnerability of the decade, he says "it's a candidate."

As noted by Caitlin Kiska, an information security engineer in the healthcare sector, the ubiquity of Log4j will necessitate lengthy, arduous efforts to deal with it.

How I explained Log4J to my mother:
Imagine there is a specific kind of bolt used in most of the cars and car parts in the world and they just said that bolt needs to be replaced.— Caitlin (@TheGamblingBird) December 13, 2021

Organizations that track their IT assets and therefore have access to an inventory of software and hardware - such as servers - that may be vulnerable will be better positioned to identify what to fix, and in what order.

But of course, not all technology being used by businesses continues to be supported by the developer or vendor that built it. In such cases, organizations will need to retire systems or find some way to safeguard them.

CISA Guidance

Given such concerns, the U.S. Cybersecurity and Infrastructure Security Agency has issued Log4j vulnerability guidance recommending that all organizations using the vulnerable software take the following steps:

• Identify devices at risk: "Enumerate external-facing devices that have Log4j."
• Set SOC alerts: All security operations centers should have actions in place to sound alerts if they detect any Log4j exploit attempts.
• Use web application firewalls: "Install a WAF with rules that automatically update."
• Update: Install software updates as quickly as possible, once they become available.

CISA has created a new webpage to help track and take action against the Apache Log4j #RCE vulnerability CVE-2021-44228. Read more at https://t.co/5UPFpnhhii. #Cybersecurity #InfoSec— US-CERT (@USCERT_gov) December 14, 2021

In-the-Wild Attacks

Already, attackers wielding numerous strains of malware have been attempting to exploit the flaw, with Muhstik and Mirai malware in particular being used to load cryptocurrency mining malware - aka coin miners - onto Linux systems they successfully exploit.

Experts say any organization that has been running software with a vulnerable version of Log4j should assume it has been breached, until proven otherwise. "Patching doesn't remove the existing compromise," says Jake Williams, CTO at BreachQuest.

Criminal exploitation is not the only risk facing vulnerable organizations. Experts say nation-state attackers never shy away from using similar tactics, especially because it makes their efforts look criminal in nature, rather than standing out as espionage.

Given the prevalence of Log4j and immediate attempts by criminals to exploit it, "under the auspices of the noise, more advanced attackers may act aggressively against quality targets," Check Point warns.