Apache Log4j2 Vulnerability (CVE-2021-44228, CVE-2021-45046, CVE-2021-45105) - Advisory For FortiSOAR

[Amit1]

Latest Updates:

Dec. 14 2021
A further vulnerability (CVE-2021-45046) was disclosed on December 14th after it was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations.

Dec. 18 2021
Another vulnerability was discovered related the log4j 0-day exploit known as CVE-2021-45105.

The below assessment takes into consideration the latest updates mentioned above.

For FortiSOAR versions >= 6.4.3 

FortiSOAR is not impacted by the vulnerability CVE-2021-44228. However, a search for log4j on the server might show some results. Following is a detailed explanation for each of these log4j references and corresponding recommendations: 

• Log4j references in /opt/cyops-tomcat/webapps: 
  • There is an unused log4j library in /opt/cyops-tomcat/webapps/gateway/WEB-INF/lib/log4j-1.2.17.jar that can be safely removed using the following command: 
    sudo rm /opt/cyops-tomcat/webapps/gateway/WEB-INF/lib/log4j-1.2.17.jar 
    sudo systemctl restart cyops-tomcat 
  • There are other log4j 2.14.1 jars that are not impacted. You can refer to the spring.io blog: https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot for the confirmation:  
    "The log4j-to-slf4j and log4j-api jars that we include in spring-boot-starter-logging cannot be exploited on their own. Only applications using log4j-core and including user input in log messages are vulnerable." 

• Log4j libraries in /usr/share/elasticsearch:  
  FortiSOAR uses ElasticSearch 7.10 and OpenJDK 11 that are not impacted as per the ElasticSearch recommendation: https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-es...:  
  
  "Elasticsearch 6 and 7 are not susceptible to remote code execution with this vulnerability due to our use of the Java Security Manager. Investigation into Elasticsearch 5 is ongoing. Elasticsearch running on JDK8 or below is susceptible to an information leak via DNS which is fixable by the JVM property identified below." 
  

  [Update December 15]

  A further vulnerability (CVE-2021-45046) was disclosed on December 14th after it was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. Our guidance for Elasticsearch, APM Java Agent, and Logstash are unchanged by this new vulnerability.
  

  [Update December 18]

  ​​Log4j2 Version 2.17.0 was released to address a denial of service vulnerability reported in CVE-2021-45105. Elasticsearch, Logstash, and APM Java agent are not exploitable by this vulnerability and the prior guidance is still valid.

  More details can be found here

  As recommended in the above forum, you can additionally do the following changes: 
  • Add the following to the end of the /etc/elasticsearch/jvm.options file: 
    -Dlog4j2.formatMsgNoLookups=true 
  • systemctl restart elasticsearch cyops-search 
    
    

• Any log4j references in /usr/share/logstash:  
  FortiSOAR no longer user logstash and it was removed in the 6.x series. However, if any traces are present due to a failed or incomplete upgrade, remove the same immediately using the following steps: 
  • get the logstash version using: rpm -qa | grep logstash 
  • remove using: yum remove <rpm listed in the above output> 
  • Ensure that the /usr/share/logstash folder is removed   

For FortiSOAR versions < 6.4.3 

• Log4j references under /opt/cyops-tomcat/webapps:  
  • FortiSOAR is not impacted by the vulnerability CVE-2021-44228. These versions of FortiSOAR use log4j library 1.2.17, which is not impacted by this vulnerability. However, since this is an old version of log4j, it is strongly recommended for customers to upgrade FortiSOAR to newer versions. Once upgraded to version >= 6.4.3, the library can be removed as mentioned in the previous section. 
  • There are other log4j 2.x jars that are not impacted. You can refer to the spring.io blog: https://spring.io/blog/2021/12/10/log4j2-vulnerability-and-spring-boot for the confirmation:  
    "The log4j-to-slf4j and log4j-api jars that we include in spring-boot-starter-logging cannot be exploited on their own. Only applications using log4j-core and including user input in log messages are vulnerable." 

• Log4j libraries in /usr/share/elasticsearch  
  FortiSOAR uses ElasticSearch 6.6 and OpenJDK 11 that are not impacted as per the ElasticSearch recommendation: https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-es...:  
  "Elasticsearch 6 and 7 are not susceptible to remote code execution with this vulnerability due to our use of the Java Security Manager. Investigation into Elasticsearch 5 is ongoing. Elasticsearch running on JDK8 or below is susceptible to an information leak via DNS which is fixable by the JVM property identified below." 
  

  [Update December 15]

  A further vulnerability (CVE-2021-45046) was disclosed on December 14th after it was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. Our guidance for Elasticsearch, APM Java Agent, and Logstash are unchanged by this new vulnerability.
  

  [Update December 18]

  ​​Log4j2 Version 2.17.0 was released to address a denial of service vulnerability reported in CVE-2021-45105. Elasticsearch, Logstash, and APM Java agent are not exploitable by this vulnerability and the prior guidance is still valid.

  More details can be found here

  
  As recommended in the above forum, you can additionally do the following changes:  
  • Add the following to the end of the /etc/elasticsearch/jvm.options file: 
    -Dlog4j2.formatMsgNoLookups=true 
  • systemctl restart elasticsearch cyops-search 
    
    

• Any log4j references in /usr/share/logstash:  
  FortiSOAR no longer user logstash and it was removed in the 6.x series. Prior to that too, it was only installed in the FortiSOAR Community Appliance for the "Security Analytics" feature demo. If the logstash installation is still present on your instance, you must remove the same immediately using the following steps: 
  • get the logstash version using: rpm -qa | grep logstash 
  • remove using: yum remove <rpm listed in the above output> 
  • Ensure that the /usr/share/logstash folder is removed  

------------------------------
Amit Jain
PM, FortiSOAR
------------------------------