This article is more than 1 year old
Apache takes off, nukes insecure feature at the heart of Log4j from orbit with v2.16
Now open-source logging library's JNDI disabled entirely by default, message lookups removed
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.
- The logging library is commonly used by Java code and is buried in tons of software, including some security defense products. Some useful commands for finding evidence of Log4j deployments on Linux boxes are listed here
- Check Point Research says it's seen at least 60 variants of exploit code used against vulnerable machines
- How the flaw was found and reported, and the scramble to patch it in time as word spread of the hole
- The US government's hub of information about the vulnerability and what to do next
- The Netherlands' National Cyber Security Center's incredible collection of software and other products affected by Log4Shell that will need patching or protecting as well as indicators of compromise and other info
- El Reg's coverage of Log4Shell
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:
From version 2.16.0, the message lookups feature has been completely removed. Lookups in configuration still work.
Furthermore, Log4j now disables access to JNDI by default. JNDI lookups in configuration now need to be enabled explicitly. Also, Log4j now limits the protocols by default to only java, ldap, and ldaps and limits the ldap protocols to only accessing Java primitive objects. Hosts other than the local host need to be explicitly allowed.
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.
- Log4j RCE: Emergency patch issued to plug critical auth-free code execution hole in widely used logging utility
- Log4j doesn't just blow a hole in your servers, it's reopening that can of worms: Is Big Biz exploiting open source?
- Log4j RCE latest: In case you hadn't noticed, this is Really Very Bad, exploited in the wild, needs urgent patching
- Timekeeping biz Kronos hit by ransomware and warns customers to engage biz continuity plans
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. ®