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.
However, that release only partially closed the hole (CVE-2021-44228) by disabling by default one aspect of the library’s exploitable functionality – message lookups with JNDI. Now version 2.16 is out, and it disables all of 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 at least exploitable in certain non-default configurations, and this moderate-severity oversight has earned its own bug ID: CVE-2021-45046. Apache conceded JNDI “has significant security issues,” so it’s probably best to deactivate it by default.
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 deploy cryptocoin miners and ransomware, at least.
Quick links
- The logging library is often buried in software. 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. 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 safety 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 to be safe: 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 claims to have seen a ransomware attack against Windows OSes linked to a Log4j exploit, dubbing the ransomware Khonsari.
Russia’s 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. ®