TABLE OF CONTENTS

• Who is impacted?
• Mitigation:
  • Steps for Mitigation
• Log4J FAQs:
  • How many components of Znode are impacted by Log4J Vulnerability?
  • Is the vulnerability on Elasticsearch Exploitable?
  • Will automated security scanners flag Log4J as a security issue after the patch?
  • Does this need to be completed when upgrading Znode?

Who is impacted?

All released Znode 9+ versions use Elasticsearch for native site searches. Znode versions 9.0.x through 9.4.x use Elasticsearch version 5.5.0. Znode versions 9.5.x through 9.7.0.0 using Elasticsearch version 7.6.0. Znode versions older than 9.0.x are not impacted as it does not use Elasticsearch. Elasticsearch’s Security Announcement has been reviewed for the impact and remediation measures for the versions of Elasticsearch used by Znode.

Mitigation:

Elasticsearch’s remediation is to set the JVM option -Dlog4j2.formatMsgNoLookups=true and remove the vulnerable JndiLookup class from the Log4j package and restart each node of the cluster.

In order to ensure the remediation of this vulnerability, all the following steps must be taken.

Please follow steps 1 to 10 for the JVM options change and 11 to 16 for the Log4j change.

Steps for Mitigation

1. Open the Windows Services Manager
   1. Right-click on the Start button to open the WinX Menu.
   2. Select Run.
   3. Type services. msc in the Run box which opens.
   4. Windows Services Manager will open.
2. Find Elasticsearch service 
    
3. Stop Elasticsearch service
    
4. Now go to the elastic search folder; i.e. D:\elastic search 7.6.2\elasticsearch-7.6.2-windows-x86_64\elasticsearch-7.6.2\config 
   Note - folder path and version of Elasticsearch may vary; the above path is just for reference.
5. Find the jvm.options file and open it for editing
   
6. Find the section “#log4j 2” in the JVM.options file.
7. Add the following new section above the “#log4j 2”  
   # JVM Options Setting For Log4j 
   -Dlog4j2.formatMsgNoLookups=true 
8. If step 6 is not found then find section  ## JVM temporary directory
   1. Add -Dlog4j2.formatMsgNoLookups=true under the ## JVM temporary directory section
9. If steps 6 and step 8 both are not found 
   1. Add the following new section below the ## GC configuration
      # JVM Options Setting For Log4j
      -Dlog4j2.formatMsgNoLookups=true
10. Save and close
11. Go to the Elasticsearch folder and find the lib folder  
    i.e. D:\elastic search 7.6.2\elasticsearch-7.6.2-windows-x86_64\elasticsearch-7.6.2\lib
    Note- folder path and version of Elasticsearch may vary; the above path is just for reference.
    1. Elasticsearch version 5.5 -> log4j-core-2.8.2.jar
    2. Elasticsearch version 7.6.x -> log4j-core-2.11.1.jar
    3. Elasticsearch version 8.8.x -> log4j-1.2-api-2.19.0.jar
12. Find the log4j-core jar file in the lib folder
    Note  - log4j-core jar version may vary according to the Elasticsearch version 
13. Create a backup of the original log4j-core jar file
14. Download and replace the log4j-core jar file with the appropriate patched version provided by Znode.
    Znode followed the steps provided by Elasticsearchin order to manually update the affected files which resulted in a new log4f-core jar file. Linked below are the patched versions of the jar files that have been created.
    
    

    For Znode versions 9.0.x through 9.4.x using Elasticsearch version 5.5.0

    Download the patched log4j-core-2.8.2.jar file
     

    For Znode versions 9.5.x through 9.7.0.0 using Elasticsearch version 7.6.0.

    Download the patched log4j-core-2.11.1.jar file

15. Restart Elasticsearch Service
16. Verify all search-related areas are working appropriately like creating an index, site search, etc.

Log4J FAQs:

How many components of Znode are impacted by Log4J Vulnerability?

Elasticsearch, used for Znode’s native search feature, is the only component that contains a package that uses Log4J. No other Znode components utilize Log4j.  

Is the vulnerability on Elasticsearch Exploitable?

No. Elasticsearch has issued a statement that they have not identified a working exploit for RCE (Remote Code Execution) or DoS (Denial of Service). Elasticsearch has suggested steps to patch as an additional precaution.

Will automated security scanners flag Log4J as a security issue after the patch?

Automated scanners use version numbers to identify a vulnerability. Once the mitigation steps have been followed as suggested by Elasticsearch and outlined in this article, the security issue is considered resolved. Since the Log4j jar file version numbers will remain the same, some security scans may produce false positives in their reporting.

Does this need to be completed when upgrading Znode?

No. The resolution for this issue will be included when installing any version of Znode 9.7.1.0 and after.