Exploiting Log4j: 40% of Corporate Networks Targeted So Far

Apache Releases Log4j Version 2.16.0 to Disable Java Naming and Directory Interface
Exploiting Log4j: 40% of Corporate Networks Targeted So Far
Frequency of attempts to test or exploit the Log4j flaw, seen across 58 countries over a 48-hour period (Source: McAfee)

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: The State of Organizations' Security Posture as of Q1 2018

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.

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.

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.

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.


About the Author

Mathew J. Schwartz

Mathew J. Schwartz

Executive Editor, DataBreachToday & Europe, ISMG

Schwartz is an award-winning journalist with two decades of experience in magazines, newspapers and electronic media. He has covered the information security and privacy sector throughout his career. Before joining Information Security Media Group in 2014, where he now serves as the executive editor, DataBreachToday and for European news coverage, Schwartz was the information security beat reporter for InformationWeek and a frequent contributor to DarkReading, among other publications. He lives in Scotland.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing inforisktoday.asia, you agree to our use of cookies.