Actually, the page should not go online at all. At least not yet.
But because of the Log4j exploit (or Log4shell) I decided to at least write this post. So please forgive the default template and everything else that needs to be done.
In the end I just want to offer a small PowerShell solution that can help with the analysis of log4j. Sometimes it is not known in networks, which systems are really affected or use log4j at all.
I would like to offer the script expressly as untested!
It should also be ensured that reliable backups exist! A test run with me has worked wonderfully - but that does not necessarily speak for other systems.
It should only be used by experienced administrators. It is also certainly good to have a look at it beforehand.
You should also evaluate if you really want to use the "automatic" cleanup, - or if you prefer to do it manually based on the results.
What exactly does the Powershell script do?
Finally it traverses a whole network area (must currently be a /24 network) and checks if a system is accessible behind it.
If it is a Windows system, the drives are queried via WMI.
These drives are then searched individually for log4j* files. If something is found, the .jar archive is unpacked into a temporary directory and the version is read from the manifest file.
And if it turns out that it is a version 2.0 or higher - the .jar archive is searched for the jdni class.
Please note that it also finds a potentially patched version, as for now it just looks for a version <= 2.0!
If this search is also positive, the feedback is sent directly to the Powershell, as well as to a log file.
Additionally there is the possibility to delete the file or class automatically (which is one of the suggested mitigations). The .jar file is then repacked and the original file is replaced.
You run the file from a system that has at least PowerShell v5.0 installed. But that should'n be a problem nowadays. The system should have access to SMB and WMI of the remote systems. - And finally it should run under a suitable account (e.g. member of the domain admins).
To make this work, you should create a new directory, e.g. C:\log4j - if it does not exist, the script will create it for you, though.
There you can put your log4j-scanner.ps1 (or whatever you want to call it).
Run the script as local admin, otherwise you may get some access permission errors.
In the last step you have to edit the file:
Under the file header you will find the entry:
$ipnet = "192.168.1" - you have to change this entry. If you want to scan e.g. "192.168.200.0/24", you have to enter "192.168.200" - without the last octet.
You should also change $workdir, if you didn't follow my suggestion and used C:\log4j. Hopefully the file is also commented sufficiently.
But as I said: Use it at your own risk! I do not take any responsibility!
Update 15.12.2021:
- Version 2.16.0 is considered safe
- working directory will be created automatically
- the temporary working dir will have a random suffix. So it is possible to run this script simultanously from the same host (e.g. for different subnets)
- basic error handling for wmic. It shouldn't spam the powershell console with error messages about systems without working WMIC
- some NTFS permission fixes which prevented the script from deleting some temporary files
And here's the script, visible below - and of course available as Download.