“This could allow attackers… to craft malicious input data using a JNDI Lookup pattern resulting in a denial of service (DOS) attack,” the CVE description says.
Apache has already released a patch, Log4j 2.16.0, for this issue. The CVE says Log4j 2.16.0 fixes the problem by removing support for message lookup patterns and disabling JNDI functionality by default. It notes that the issue can be mitigated in prior releases by removing the JndiLookup class from the classpath.
John Bambenek, principal threat hunter at Netenrich, told ZDNet the solution is to disable JNDI functionality entirely (which is the default behavior in the latest version).
“At least a dozen groups are using these vulnerabilities so immediate action should be taken to either patch, remove JNDI, or take it out of the classpath (preferably all of the above),” Bambenek said.
The original flaw in Log4j, a Java library for logging error messages in applications, has dominated headlines since last week. Exploits started on December 1, according to Cloudflare, and an initial alert by CERT New Zealand sparked others by CISA and the UK’s National Cyber Security Centre.
The Dutch National Cyber Security Center released a lengthy list of software that is affected by the vulnerability.
International security company ESET released a map showing where Log4j exploitation attempts have been made, with the highest volume occurring in the US, UK, Turkey, Germany, and the Netherlands.
“The volume of our detections confirms it’s a large-scale problem that won’t go away anytime soon,” Roman Kováč, Chief Research Officer at ESET, said.
Many companies are already experiencing attacks leveraging the vulnerability; security platform Armis told ZDNet that it detected log4shell attack attempts in over a third of its clients (35%). Attackers are targeting physical servers, virtual servers, IP cameras, manufacturing devices, and attendance systems.