LOG4J - Indications

Step by step guide to check and secure your system

• General check of the system

  We suggest the following tool to check your system for the CVE-2021-44228 vulnerability: The log4j-detector open source project. (This tool also identifies LOG4J libraries in JAR archives, where they are typically packaged).

  The execution time can be several hours.

  Download the file directly from the GIT Hub project to make sure you are using the latest version of the little tool. To do this, go to the

  GIT Hub Projekt

  and select the latest jar version of the detector.

  

  After that, download the jar file to the computer.

  

  Now you have the tool and you just need to use it. To do this, open a console window (as admin) and execute the following command:

  java -jar [path to lof4j detector file] --verbose [destination you want to search] > [Path and name of the log file to be created]

  Example:

  The log4j jar file is located directly on drive C:\ and the hard disk D:\ is to be scanned. The log file documenting the vulnerability findings should be written to the Windows temp folder.

  java -jar C:\log4j-detector-2021.12.13.jar --verbose D:\ > C:\temp\log4jHITS.txt

   

• Versions affected

  Log4J versions 1.x are not affected by the current vulnerability according to current knowledge.
  
  Vulnerable versions are Log4J 2.x (2.0-beta9 to 2.15).
  
  Version 2.16 is considered fixed.

• Measures for Siemens/BCT

  In the meantime, a tool has proven itself - also recommended by Siemens - to have the measures carried out automatically. This tool is called logpresso and is available under the following link.
  
  

  The following procedure has proven itself for our consultants:

  1. Scan the system for affected log4j incidents:
     log4j-scan.exe --all-drives --report-csv
  2. Scan the system for affected log4j occurrences in zip files:
     log4j-scan.exe --all-drives --report-csv --scan-zip
  3. Stop services and applications - downtime
  4. Execution of the actions that are carried out according to the current status.  More detailed information can be found in the GitHub project of logpresso itself:
     log4j-scan.exe --all-drives -fix
  5. Reboot the system and start the services/applications.
  6. Re-scan as in point 1 supplemented by the scan as described in point 2 above with services running.
  7. Evaluate the results of the final scan and, if necessary, make the manual adjustment as described below.

   

  Notes

  Be sure to start the console as administrator.

  Where logpresso.exe is executed, a backup directory is created to restore the initial state. Please make sure that there is enough disk space available (20 GB).

  Regarding point 1 and point 2: this can also be done in one command. However, the scan of the *.zip files is more time-consuming, which is why we have listed it separately. Zip files should also be adjusted with the known measures. Teamcenter deploys or later installation/execution could distribute the vulnerability in the system again.

  Regarding point 4: While we recommend a scan of the entire system to get an overview, we recommend to only consider BCT and Siemens products when performing the measures. For other affected software, we ask you to contact the respective software manufacturers and be informed about the respective measures. The argument -all-drives is therefore to be adapted according to the overview you get from the previous scans.

   

  Instructions for manual adjustment, if necessary
  
  Delete JndiLookup from the affected classpath. BCT suggests the following steps:

  After the above tool has identified the affected log4j-core-*.jar files, a line from the log might look like the following:
  
  C:\EXAMPLE\BEISPIELservice.jar!/BOOT-INF/lib/log4j-core-2.7.jar contains Log4J-2.x >= 2.0-beta9 (< 2.10.0) _VULNERABLE_ :-(

  Now open the .jar file at the path specified in the log with e.g. 7zip. Here in the example is the path to the detected file C:\EXAMPLE\BEISPIELservice.jar!/BOOT-INF/lib/log4j-core-2.7.jar

  

  Since here jars are packed in jars, you have to navigate to the JndiLookup.class with the help of 7zip to delete it from the archive.
  The location of this JndiLookup.class can always be found via the substring \org\apache\logging\log4j\core\lookup\

  This results in the storage location in this example:

  C:\EXAMPLE\BEISPIELservice.jar\BOOT-INF\lib\log4j-core-2.7.jar\org\apache\logging\log4j\core\lookup\

  

  Now delete (or rename) the JndiLookup.class and update the archive afterwards, which is confirmed by a pop-up window (when the window is closed).

  It is essential to perform another scan after the performed actions.

• Possible consequential problems of the measures

  Problem description:

  Executable jar files with embedded log4j-core-2.x.jar become unusable if they are cut as described (in the actions). 7-zip compresses the files when writing them, but embedded (nested) jar files may not be compressed.

  This is for example the case with the bct-checkitdesigner.jar, if the affected jar file is not executed after the measure is implemented, the following error messages are displayed:
  
  java -jar "bct-checkitdesigner-service_1.jar"
  Exception in thread "main" java.lang.IllegalStateException: Failed to get nested archive for entry BOOT-INF/lib/log4j-core-2.7.jar
  at org.springframework.boot.loader.archive.JarFileArchive.getNestedArchive(JarFileArchive.java:108)
  at org.springframework.boot.loader.archive.JarFileArchive.getNestedArchives(JarFileArchive.java:86)
  at org.springframework.boot.loader.ExecutableArchiveLauncher.getClassPathArchives(ExecutableArchiveLauncher.java:70)
  at org.springframework.boot.loader.Launcher.launch(Launcher.java:49)
  at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:51)
  Caused by: java.io.IOException: Unable to open nested jar file 'BOOT-INF/lib/log4j-core-2.7.jar'
  at org.springframework.boot.loader.jar.JarFile.getNestedJarFile(JarFile.java:256)
  at org.springframework.boot.loader.jar.JarFile.getNestedJarFile(JarFile.java:241)
  at org.springframework.boot.loader.archive.JarFileArchive.getNestedArchive(JarFileArchive.java:103)
  ... 4 more
  Caused by: java.lang.IllegalStateException: Unable to open nested entry 'BOOT-INF/lib/log4j-core-2.7.jar'. It has been compressed and nested jar files must be stored without compression. Please check the mechanism used to create your executable jar file
  at org.springframework.boot.loader.jar.JarFile.createJarFileFromFileEntry(JarFile.java:284)
  at org.springframework.boot.loader.jar.JarFile.createJarFileFromEntry(JarFile.java:264)
  at org.springframework.boot.loader.jar.JarFile.getNestedJarFile(JarFile.java:252)

   

  Fixing the problem:
  
  The jar tool from the JDK has the "0" switch for this to save without compressing. This results in the following recommendation as a fix should the problem occur:

  1. Search JndiLookup.class with 7-Zip-FileManager and delete in the jar, write change
  2. Extract the log4j-core-jar with the command-line jar-tool from the JDK
     %JDK_HOME%\bin\jar -xvf bct-checkitdesigner-service.jar <path-to-log4jcore.jar>
  3. Import without compressing
     %JDK_HOME%\bin\jar -u0vf bct-checkitdesigner-service.jar <path-to-log4jcore.jar>
  4. Delete exported directory with rmdir /S /Q.

  
  You can apply the described repair directly to embedded log4j-core-2.x.jar. If you have already executed the measures and notice that the described errors occur, then go to point 2 in the repair measures to fix the problem.
  
  If you have any questions about this, please contact our support.
  
  

• BCT Software / Siemens Software

  BCT Software

  Regarding this vulnerability as safe are all BCT products from version v21R3.
  
  In the previous versions are affected by the vulnerability:

  • BCT CheckIt Designer Microservice
  • Microservices for BCT Active Workspace AddOns

   

  The vulnerability can only be exploited if the corresponding microservices are running, i.e. either manually started, deployed in an application server, or installed as a separate service.

  Basically we recommend you to upgrade or patch to the latest version of the BCT software. Starting with version v21R3 the jar library affected by the vulnerability is no longer used. Any microservices from old versions that are still installed should be removed.

  If you have one of the affected modules (in a version <21R3) in use and cannot upgrade or patch to a current version, please perform the actions under point 3 below. If you need help, contact the support.
  
  
  Immediate measures we recommend for all customers:

  1. Scan your environment with a log4j Detector.
  2. Qualify the results.
     Are the finds (in the generated log file) in productive use? Installers, directories from previous installations can be removed. If microservices are affected, it must be checked whether they are actually in use. If this is not the case, please remove the microservices.
  3. Apply the described "Measures for Siemens/BCT" if you cannot apply a direct upgrade/patch.
  4. Perform a rescan.

  
  Note: There is BCT software that uses log4j 1.x. This version is not affected by vulnerability CVE-2021-44228.
  
  

   

  Siemens Software

  Siemens has published documentation for its products which is updated continuously. It lists affected Siemens applications and the necessary measures to be taken.

FAQs

• Which systems are particularly at risk?

  Application servers that allow/use access from outside the company network are considered particularly at risk. Servers and clients that use IoT applications are also considered particularly at risk. These systems should be prioritized with the recommended steps.

• Can I run the detector scan while the system is running?

  We have performed a test for this and obtained identical results in the detections with the services running and stopped. Downtime is not necessary for the scans.

• Can I safely delete the JndiLookup.class?

  This question cannot be answered generally and must be clarified with the respective software manufacturer.

  The class is not used with BCT software products. It can be removed as described in the manual. For Siemens, please check the affected software in advance under the following LINK.

• I can't delete the JndiLookup.class, what should I do?

  If you cannot delete the class, it is most likely because the corresponding jar archive is in use/access. Plan a downtime for jar archives affected by this.

• Is there an update for NX12 regarding the vulnerability?

  NX12 has been out of maintenance for some time. There will be no updates for this product.

  Siemens is working on releasing updates and patches for products that are currently under maintenance.

• Is BCT Inspector in Opcenter affected?

  BCT Inspector in Opcenter is not affected.

  But if you use Teamcenter Quality in Active Workspace then the microservices are affected up to and including BCT version v21R2.

  Opcenter itself can be affected. Siemens provides workarounds and instructions under the following LINK.