Apache Takes Off, Nukes Insecure Feature At The Heart Of Log4j From Orbit With 2.16

Last week, version 2.15 of the widely used open-source logging library Log4j was released to tackle a critical security hole, dubbed Log4Shell, which could be trivially abused by miscreants to hijack servers and apps over the internet.

That release closed the hole (CVE-2021-44228) by disabling by default the Java library’s primarily exploitable functionality: JNDI message lookups. Now version 2.16 is out, and it disables all JNDI support by default, and removes message lookup handling entirely for good measure, hopefully finally preventing further exploitation.

This is needed because version 2.15 is still exploitable in certain non-default configurations, and this moderate-severity oversight has earned its own bug ID: CVE-2021-45046.

Crucially, this move is defense in depth: Apache conceded JNDI “has significant security issues,” so it’s just deactivated it by default with a fresh release. Version 2.15 was most probably enough to protect you from attack, version 2.16 makes it certain.

It all comes as network observers say they’re seeing tens of thousands of attempts per minute to exploit internet systems via the logging library, with miscreants using the remote-code-execution hole to steal cloud infrastructure credentials, and deploy cryptocoin miners and ransomware, at least.

In its latest release notes for Log4j 2.x, the Apache Foundation said: “Dealing with CVE-2021-44228 has shown the JNDI has significant security issues. While we have mitigated what we are aware of it would be safer for users to completely disable it by default, especially since the large majority are unlikely to be using it.”

Thus version 2.16.0 has shipped with JNDI, the Java Naming and Directory Interface, switched off. JNDI is the API that was explosively discovered to be exploitable in Log4j last week. It’s supported by Log4j so that objects can be fetched from remote servers to use in log entries.

With JNDI enabled, Log4j could be tricked into fetching Java code from an attacker-controlled server and blindly executing it, compromising the device. To achieve this, the attacker would need to feed some specially crafted text in, say, an app account username or site search query, that when logged by Log4j would trigger the remote code execution.

According to the Apache team:

That basically means if you want to use JNDI lookups, you need to take the safeties off your software stack.

NCC Group’s Jeff Dileo mused in a blog post: “In reality, the JNDI stuff is regrettably more of an ‘enterprise’ feature than one that developers would just randomly put in if left to their own devices. Enterprise Java is all about antipatterns that invoke code in roundabout ways to the point of obfuscation, and supporting ever more dynamic ways to integrate weird protocols like RMI to load and invoke remote code dynamically in weird ways.”

Essentially, if you’re using (or deploying) Log4j 2.x versions 2.14 or below, upgrade to 2.16, and if you’re already on 2.15, consider 2.16 for peace of mind: the JNDI code is not known to be terribly secure.

Exploitation probably from crims rather than nation states

Britain’s National Cyber Security Centre earlier today said it wasn’t seeing much obviously malicious web traffic linked to Log4j other than scanning to identify vulnerable systems, though as the day has worn on, infosec folk say attacks are ramping up. Bitdefender claimed to have seen a ransomware raid on Windows machines involving a Log4j exploit, dubbing the ransomware Khonsari.

Kaspersky Lab published some findings from its telemetry suggesting most exploit attempts were being launched from Russian IP addresses, which in itself doesn’t mean anything yet – though it chimes with previously reported information from Bitdefender.

For now, developers need to roll out their application and server software with patched versions of Log4j, and organisations need to not only install them but also check to see if they’ve already been pwned. ®

READ MORE HERE