Forum Discussion
Apache Log4j Detection for Windows - Manifest / Properties...
Apache Log4j Detection for Windows - Manifest / Properties Detection Update
Summary:
In the light of resource requirements to scan entire file systems along with inspecting each Java archive file in-depth while checking the manifest and properties files, we have decided to require that the following settings be enabled to leverage the detection using manifest and properties files in Apache Log4j JAR Detection (Windows) (156001):
- ‘Perform thorough tests’ setting must be enabled
- ‘Override normal accuracy’ setting must be set to ‘Show potential false alarms’
This feature was first released in Nessus plugin feed 202201080412.
We are looking at ways to further optimize this feature to enable faster scans while lowering its impact on system resources.
Impact:
Customers may observe fewer resources being consumed on Windows scan targets during a local or Agent scan but may also observe slightly fewer Apache Log4j detections that were detected via the manifest or properties file over the past several days. Once ‘Perform thorough tests’ and ‘Override normal accuracy’ settings are configured as mentioned above, the detections should re-appear.
A consequence of this change is that some Apache Log4j vulnerabilities may appear as remediated if they were previously detected via this method and subsequent scans did not have the aforementioned settings enabled.
Plugin:
Apache Log4j JAR Detection (Windows) (156001)
References:
Assessment Scan Settings - Perform thorough tests and Override normal Accuracy settings
Target Release Date:
January 12, 2022 (released in Nessus plugin feed 202201130817)
15 Replies
@Greg Betz I am a little confused by this update. It says target release date is 1/12 but the plugin feed you listed says 01/08 is that right? Also, this change only applies to the Windows plugin? Is there something coming for the Linux plugin?
@Bryan Jones The detection method to check the MANIFEST or properties file in detected Java archive files for the presence and version of Log4j was added in 202201080412.
This release highlight is for a new requirement that both the ‘Perform thorough tests’ and ‘Override normal accuracy’ settings need to be set as mentioned above in order for the MANIFEST/properties detection method to run.
Regarding the Apache Log4j detection for Linux, we're monitoring whether we need to introduce the same requirement but as far as we aware, this detection method on Linux requires fewer resources. If you (or anybody reading this) is having an issue with either detection plugin, please open a technical support ticket so that we can properly diagnosis the issue.
Appreciate the clarification for Windows and the insight on Linux.
The requirement mentioned in the Release Highlight was released in Nessus plugin feed 202201130817.
Noticing 25k of powershell log entries and spikes in memory usage (up to 2-5 GB even with the newer plugin set- "normal" (non-paranoid, non-thorough policy). Case opened with Support already with the details
Yes, the file system search for Log4j also creates a huge amount of Powershell events (EID 800). We have seen that one file system search by plugin 156001 results in 128.000 (!) EID 800 events for each server.
Is this plugin part of the "Log4Shell Vulnerability Ecosystem" policy and if we have existing scans configured which use it will they automatically get updated to reflect this change, or do I have to manually change something please?
Hello @James H, this plugin is part of the "Log4Shell Vulnerability Ecosystem" and "Log4Shell" policies. The plugin will still run but the inspection of Java archive files for manifest and properties file will not run unless the following non-default settings are set:
- ‘Perform thorough tests’ setting must be enabled
- ‘Override normal accuracy’ setting must be set to ‘Show potential false alarms’
So scan entire file systems along with inspecting each Java archive file in-depth continues whether "thorough test" and "override normal accuracy" is set or not. The change here is to not check manifest and properties files unless you have those things set.
This does not appear to help with the memory usage issue, which according to the engineers/developers I have reporting issues to me is due to "not disposing of their zip archives when done using them, and leave them open until the script completes". If you do not have enough RAM for the amount of JAR/WAR/EAR files, you may see a powershell instance consume all available RAM. "in my experience with Powershell, it can be very lazy about garbage collection and you often need to call it explicitly when working with large data structures."
Another one also found this: "> cmd.exe /c dir /A-L /s /r /b
will recurse symlinks. As such, when it finds a symlink to a directory containing WAR/JAR/EAR files, I believe it will multiply the memory required to parse the true directory at best, and at worst parse any symlinks recursively until the machine runs out of RAM(to hold the list of paths) or pathlength(260 default)."
We started having issues with memory exhaustion in the past week. What can be done to resolve this issue? It has already cause several servers to lock up and be forced to reboot.
Hi Jon,
Check this thread out about Windows Log4j detection, - https://community.tenable.com/s/feed/0D53a00008ITlIWCA1
Tenable is working to resolve some issues with #156001 ETA sometime today
https://www.tenable.com/plugins/nessus/156001
I'm still waiting for a fix (i have a support case open too) in the meantime i'm disabling ALL log4j plugins for affected servers.
Great, happy to see that resource utilization for plugin 156001 is improved. Seeing memory on our production VM's running 8Gb RAM maxed out for an extended period of time was not entertaining.
However, 50% of our environment is Windows Server 2012 R2 that does not - nor will ever be running - newly-mandatory PowerShell 5.x or better (or either of its .NET and WMF prerequisites). This is resulting in False Negatives
Positivesin a production environment, and affecting our ability to get a remediation plan to the customer.Is there any hope for production sites that need both plugin 156001 to identify Log4j JAR files and to maintain Windows Server 2012 R2 until it is retired?
Please contact Tenable Technical Support (https://www.tenable.com/support/technical-support#contact-support) with issues and requests so that we can better assist you.
Unfortunately, I already have a support case open - one that has been open since 1/11/22. Three escalations requested but have not had any indication of a resolution.
Newly-required PowerShell 5.x has been the only recommendation to resolve False Negatives with plugin 156001, but our servers cannot run this revision, which is why I posted to the community looking for potential alternative(s).
