Summary

Which Log4j versions are installed in your own IT landscape? And which tools can help with transparency? SAM tools use inventory solutions to gather programs and files. Can't they just take on this task too?

This article describes how Spider can support the transparency of which Log4j versions are installed via jar archive files in the IT landscape. Learn more about our January 2022 expansion of the Spider suite.

Why did we decide to expand Spider with a Log4j vulnerability report?

First of all, there is a particular criticism of Log4j vulnerability. We understood from discussions with customers that it is not easy  to achieve transparency about the Log4j versions used in a IT landscape. There are different strategies which are needed for the detection of Log4j.  Windows Add And Remove Programs often does not go far enough. Instead, the specific JAR files and their locations are asked more often.

Because a SAM tool is based on inventory data, which also includes files, the question arises whether it might not be possible to collect and evaluate the "log4j*.jar" files. The Spider Recognition module was previously only able to process exe-files. The amount of exe-files in itself is a particular challenge in the recognition process. What would it mean if the log4j jar files are now also processed?

This has been investigated and a report has been developed. Only a few settings have to be made, to collect log4j.jar files and to get the report up and running about which jar file and which version are found on which system.

The collection can be done with the inventory solution Spider Inventory (former Columbus Inventory) as well as with the Microsoft Endpoint Configuration Manager (formerly SCCM).
The report on all file evidence (file scan) is often very time-consuming and slow, which is why we worked on a good solution so that a quick report can be created and also be exported.

These extensions are possible with the first January release 2022.

What does this extension include?

• Existing Spider Inventory (Columbus Inventory) already supports that multiple file extensions can be gathered. According to this, the .jar file extension can be added by changing the configuration of the config files (cfg-file).
  No new Spider Inventory version is required. Only the configuration changes need to be rolled out.
  
  
• If Microsoft Endpoint Configuration Manager is used, the collection of *.jar files for log4j can be added there. The connector has been extended so that these "log4j*.jar" files can also be exported and processed in Spider, if they occur. 
  In order to use the new connector version, the Spider Data Collector has to be updated.
  
  
• The Spider Recognition module (release January 2022 and above) processes log4j*.jar files so that they are stored as file evidence (file scan) in addition to the .exe files. We have decided that only log4j*.jar files will be processed and saved. Other jar files are discarded during import so that the file scan is not unnecessarily enlarged and arithmetic operations are not unnecessarily slowed down.
  To take advantage of this, the Spider Recognition module has to be updated.
  
  
• Spider delivers a new vulnerability report for Log4j. The report shows gathered log4j*.jar files on the scanned devices for authorized legal entities. The following fields are available in the report so that there is a good overview of where which Log4J Jar files are installed:
  AsssetNo, hostname, status, last scan date , legal entity, filename of the log4j-jar file, the installation path, the Log4j version extracted from the filename. 
  In order to use the new report, Spider has to be updated.

What steps are required?

• Update of the Recognition module with version 1.2201.1 or higher.
  
  
• If Spider Inventory is used, roll out the configuration change so that * .jar files are also gathered.
  For this, the file extension .jar must be added as the file extension in the configuration file (cfg file).
  
  
  

• For using the Microsoft Endpoint Configuration Manager (former SCCM) connector, the update of Spider Data Collector to version 1.2201.1 or higher is required.
  The collection of .jar files must be expanded in the Configuration Manager. In addition to the exe files, the connector only exports files that match the pattern log4j*.jar.
  
  
• Update Spider to version 6.4.5-R8 or higher to get the new fast running vulnerability report based on log4j.jar file evidence. By default, the report is authorized for the Asset Manager role.
  The report can be found under the Vulnerability Reports group.

A few words about the report:

The report shows log4j jar files including the file path. The version is extracted from the file name during processing and enables a targeted search for specific versions.
Assets are shown with the columns AssetNo, Hostname, Status, Last Scan Date and Legal Entity. Only authorized assets via Legal Entities are visible.

The report was implemented as a procedure-based report and enables a quick response, even in large environments for which many files are processed (e.g. 1 million data records).

The following screenshot shows an example of a data record for the report.

What if a different connector is used?

If another connector or inventory system is used, that provides file scan, we can check whether it is possible to collect and export log4j*.jar files here. If you are interested, we look forward to a comment or an email.

For Spider Datacenter Inventory for Linux / Unix this functionality is currently not available. If Spider Datacenter Inventory is used and the collection and processing of jar files for Log4j is an important requirement for you, we look forward to an email for further coordination.