Apache takes off, nukes insecure feature at the heart of Log4j from orbit with v2.16
- Reference: 1639524607
- News link: https://www.theregister.co.uk/2021/12/14/apache_log4j_2_16_jndi_disabled/
- Source link:
However, that [1]release only partially closed the hole ( [2]CVE-2021-44228 ) by disabling by default one aspect of the Java library's exploitable functionality – JNDI message lookups. 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: [3]CVE-2021-45046 . Apache also conceded JNDI "has significant security issues," so it's decide it is best to just deactivate it by default.
[4]
It all comes as network observers [5]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.
Quick links
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 [6]listed here
Check Point Research [7]says it's seen at least 60 variants of exploit code used against vulnerable machines
How the flaw was found and reported, and [8]the scramble to patch it in time as word spread of the hole
The US government's [9]hub of information about the vulnerability and what to do next
The Netherlands' National Cyber Security Center's [10]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 [11]coverage of Log4Shell
In its latest [12]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.
[13]
[14]
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 [15]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."
[16]
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 [17]claimed to have seen a ransomware raid on Windows machines involving a Log4j exploit, dubbing the ransomware Khonsari.
[18]Log4j RCE: Emergency patch issued to plug critical auth-free code execution hole in widely used logging utility
[19]Log4j doesn't just blow a hole in your servers, it's reopening that can of worms: Is Big Biz exploiting open source?
[20]Log4j RCE latest: In case you hadn't noticed, this is Really Very Bad, exploited in the wild, needs urgent patching
[21]Timekeeping biz Kronos hit by ransomware and warns customers to engage biz continuity plans
Kaspersky Lab published some [22]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. ®
Get our [23]Tech Resources
[1] https://www.theregister.com/2021/12/13/log4j_rce_latest/
[2] https://nvd.nist.gov/vuln/detail/CVE-2021-44228
[3] https://www.cve.org/CVERecord?id=CVE-2021-44228
[4] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2Ybl2fRz57g2OKCWOVSpwZwAAAFI&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[5] https://twitter.com/eastdakota/status/1470705081003614218
[6] https://twitter.com/cyb3rops/status/1470689721990922242
[7] https://blog.checkpoint.com/2021/12/13/the-numbers-behind-a-cyber-pandemic-detailed-dive/
[8] https://www.bloomberg.com/news/articles/2021-12-13/how-apache-raced-to-fix-a-potentially-disastrous-software-flaw
[9] https://www.cisa.gov/uscert/ncas/current-activity/2021/12/13/cisa-creates-webpage-apache-log4j-vulnerability-cve-2021-44228
[10] https://github.com/NCSC-NL/log4shell
[11] https://www.theregister.com/Tag/log4j
[12] https://issues.apache.org/jira/browse/LOG4J2-3208
[13] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Ybl2fRz57g2OKCWOVSpwZwAAAFI&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[14] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33Ybl2fRz57g2OKCWOVSpwZwAAAFI&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[15] https://research.nccgroup.com/2021/12/12/log4j-jndi-be-gone-a-simple-mitigation-for-cve-2021-44228/
[16] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_security/front&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44Ybl2fRz57g2OKCWOVSpwZwAAAFI&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[17] https://businessinsights.bitdefender.com/technical-advisory-zero-day-critical-vulnerability-in-log4j2-exploited-in-the-wild
[18] https://www.theregister.com/2021/12/10/log4j_remote_code_execution_vuln_patch_issued/
[19] https://www.theregister.com/2021/12/14/log4j_vulnerability_open_source_funding/
[20] https://www.theregister.com/2021/12/13/log4j_rce_latest/
[21] https://www.theregister.com/2021/12/13/ultimate_kronos_group_ransomware_attack/
[22] https://securelist.com/cve-2021-44228-vulnerability-in-apache-log4j-library/105210/
[23] https://whitepapers.theregister.com/
Re: So why did this feature exist in the first place?
Because enterprise software is defined by feature bloat and buzzword compliance. Security is not the primary drive or sales argument.
It would be funny if there was no truth in that statement...
Re: So why did this feature exist in the first place?
Log4j is an otherwise lightweight, open source logging component built by a group of about 10 entirely-uncompensated volunteer committers. It is not by any stretch of anyone's imagination "enterprise" software.
It's just used in a lot of enterprisey bits. And we enterprisey vendor types never checked what it really does. Because we're cheapskates like that.
It helps to understand how Apache projects work. All development is done on weak consensus. That is any committer can object to a proposal, but this is generally discouraged and a lack of objections is enough to proceed. So ASF projects frequently include features that probably made a whole load of sense to whoever was writing the commit and whoever +1'd it, but really do not in retrospect.
That is the double-edged sword of the ASF model. Stuff gets done without too much bother, but occasionally nobody stops to ask - why? Especially so in the smaller projects without vendor sponsorship.
Re: So why did this feature exist in the first place?
Exposing the feature to user-supplied content in a way that enables this particular exploit is a fairly natural outcome of the sort of feature-maximization that comes when you give your variable-expansion syntax general purpose function-invoking capabilities. The syntax and effect is not vastly dissimilar from GNU Make variable expansion and function application, and that's been around forever.
The part that executes remote code? That's a built in part of Java that has been there since the beginning. Java has always had the ability to load new classes at run time, and that is part of the object-oriented modelling: if some system that you're communicating with wants to send you data that happens to be of a type that your program doesn't recognize, then it can also send you the code that implements it, because why not? And since the code is write-once, run-anywhere, it'll run anywhere. This is such a core part of java that it is unusual to have ahead-of-time compilation of Java programs to native code, because such code would not be able to perform this particular trick/exploit.
These two come together in the ability of the variable expansion syntax to express JNDI lookup requests to LDAP based databases that can return data with new types and new code from arbitrary servers, where those variable expansions also apply to strings that can be supplied by users (such as user names and browser type).
A classic example of something being more than the sum of its parts: more like the product of its parts...
So why did this feature exist in the first place?
Seriously, who wanted it and what reason did they give?
It's self-evidently incredibly insecure, and on the face of it doesn't have any non-malicious uses at all.