Overview

Note: This is the only article that will be updated with findings from our development and security teams.

Update:

• December 20, 2021: CVE-2021-45105 Impact on FileCatalyst applications
• December 17, 2021: Is FileCatalyst exposed to CVE-2021-45046
• December 14, 2021: How to enable system properties for Log4j2 on FileCatalyst Products

What is the Log4j CVE-2021-44228 vulnerability? 

The CVE-2021-44228 vulnerability is a day zero security vulnerability under the highest severity rank that allows attackers to execute arbitrary code by injecting attacker-controlled data into a logged message. Using this vulnerability, attackers can execute code loaded from LDAP servers when message lookup substitution is enabled. This allows attackers to execute whatever code they wish to on systems that have an application running log4j, which presents a massive security concern. 

For more information regarding this vulnerability, please visit the following links: 

• CVE-2021-44228 definition: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228 
• Apache Log4j Security Vulnerabilities: https://logging.apache.org/log4j/2.x/security.html  
• Slf4j Comments on the Vulnerability: http://slf4j.org/log4shell.html 

What resources are exposed to this vulnerability? 

To be subject to this vulnerability outlined by CVE-2021-44228, you must meet two specific conditions. 

The first condition that must be met is that your application must be using a log4j2 library implementation between versions 2.0.0 and 2.14.1. These versions of Log4j2 introduced a lookup mechanism that allows the logger to perform string substitution using the JNDI protocol. This substitution mechanism is the item that is causing the CVE-2021-44228 security vulnerability, and it is present in all log4j2 libraries that exist within the version range. It is also important to note that this substitution mechanism is only current with the version 2 implementations of log4j. Version 1 log4j libraries do not have the JNDI substitution mechanism implemented, and because of this, they are not subject to security vulnerability. 

The second condition that must be met is that your application must be running on a Java version older than version 1.8.121. Before this release, Java 8 did not have any protection for applications attempting to run remote code execution in ways similar to the CVE-2021-44258 vulnerability. In version 1.8.121, Java introduced logic that prevents remote code execution from being executed by default. With that in mind, if you are running your Java application with a version that is higher than 1.8.121, then you will not be subject to the CVE-2021-44228 security vulnerability. 
 
 

What impact does CVE-2021-44228 have on the FileCatalyst applications? 

When it comes to FileCatalyst applications, CVE-2021-44228 has a low impact. The low impact is because the majority of the FileCatalyst applications do not use log4j for logging information during the application’s lifecycle. The majority of the FileCatalyst applications instead use the standard java.util.logger package that is bundled within the JREs that are distributed with each application. This logger implementation is separate from log4j, and thus, it is not subject to the CVE-2021-44228 vulnerability.  

Now, some FileCatalyst applications do reference log4j within their classpath definitions. However, these references are not subject to the CVE-2021-44228 log4j vulnerability for the reasons illustrated below.  

What FileCatalyst applications are not at risk? 

The following is a list of FileCatalyst applications that do not reference log4j and are not at risk to the CVE-2021-44228 security vulnerability. 

• FileCatalyst API 
• FileCatalyst Central 
• FileCatalyst Command Line 
• FileCatalyst LoadBalancer 
• FileCatalyst HotFolder 
• FileCatalyst Reverse Proxy 
• FileCatalyst Server API 
• FileCatalyst TransferAgent 

The following is a list of FileCatalyst applications that do reference log4j but are also not at risk to the CVE-2021-44228 security vulnerability: 

What FileCatalyst applications are at risk? 

Currently, no applications are at risk from CVE-2021-44228. All FileCatalyst applications either do not reference log4j as part of their dependencies or reference a version that does not have the string substitution resource required for the vulnerability.  

What can I do to protect myself from this vulnerability? 

Currently, there isn’t anything that you will need to do to protect yourself from this security vulnerability. All FileCatalyst applications now do not meet the requirements for CVE-2021-44228, and that will ensure that you are safe from this issue. If you want to take extra steps to ensure that you are not subject to vulnerability, then there are a couple of things that you can do.    

The first option you can do is ensure that all FileCatalyst applications are upgraded to the most recent available versions. Upgrading to the most recent will allow you to utilize the security fixes that FileCatalyst has implemented within their applications. It will ensure that you have the most up-to-date security fixes.  

The second option you have access to is setting the system property “log4j2.formatMsgNoLookups” to have a true value for both the FileCatalyst Server and FileCatalyst Workflow applications. While setting this value will not do anything within the current releases of the software (due to the log4j implementation not being the correct version), it will set the value and ensure that that your system will not expose the CVE-2021-44228 security vulnerability. 

How to enable system properties for Log4j2 on FileCatalyst Products?

FileCatalyst Server

1. Open the FileCatalyst Server Admin.
2. Click on Advanced and navigate to the System Properties tab.
   
3. Hit Add Property and set the following (case sensitive):
   
   Name: log4j2.formatMsgNoLookups
   Value: true
   
   
   
4. Hit Ok to close the pop up and hit Apply.
5. Restart the FileCatalyst Server.

FileCatalyst Workflow

The following steps will work on Linux and Windows OS:

1. Shut down your Tomcat service
2. Locate the catalina.properties file and open it in a text editor. The file iss usually in the conf directory inside your Tomcat installation folder.
3. At the bottom of catalina.properties add the following text exactly:
   
   log4j2.formatMsgNoLookups=true
   
   
4. Save and close the file.
5. Start the Tomcat service.

How do I verify that I am protected against CVE-2021-44228? 

To check for whether or not you are exposed to the CVE-2021-44228 vulnerability within the FileCatalyst Workflow application, you can take the following steps: 

1. Navigate to the login page of your FileCatalyst Workflow application. 
2. Click on the "Enter Tracking Number Here" Link, which should take you to the "download files" page. 
3. Note: If you have configured your login page not to display the "Enter Tracking Number Here" link, then alternatively, you can send files using the distribution form and then click on the "download files" link received in the email sent to the recipient. 
4. Instead of entering a valid tracking number on the download files page, enter the following string and click on the submit button: ${jndi:ldap://127.0.0.1:389/CVE202144228} 
5. Log on as the super-admin on to your FileCatalyst Workflow instance. 
6. Click on the "System Tools" option from the top navigation menu, then click on the "View and Configure Logs" option. 
7. Now click on the "View Current Log File" option. 
8. Scroll down to the bottom of the displayed log file and look for the String - "Tracking number not found in InitializeDownloadFilesTag: ${jndi:ldap://127.0.0.1:389/CVE202144228}". 
9. Ensure that you do not see the following lines in the log file "Error looking up JNDI resource [ldap://127.0.0.1:389/CVE202144228]". 

When you perform these steps, you should see something similar to this within the FileCatalyst Workflow instance: 

As you can see, the FileCatalyst Workflow application outputs the string in the log file and does not attempt to connect to the LDAP URL. With this, you are protected from the CVE-2021-44228 vulnerability. 

What is FileCatalyst doing to protect customers from this vulnerability further? 

To protect people from security vulnerabilities in third-party libraries, FileCatalyst continuously monitors dependencies by using a security tool to scan each dependency and check its version against the list of currently open security issues for the library being checked. If a library is found to have a security vulnerability, then the development team is notified, and an investigation into the issue is started. Once the analysis is complete, the development team implements a solution, and then the next release will contain a fix for the identified problem. 

In the case of the log4j CVE-2021-44228 vulnerability, the security tool identified the problem as soon as the issue was found. Once the problem was found, the FileCatalyst team quickly began investigating the log4j references within the codebase. During this investigation, the team determined which CVE-2021-44228 vulnerability impacted applications and how the exposure might be addressed. While no work is currently needed to address the vulnerability, the FileCatalyst team is looking into updating the log4j implementation to the most recent version of the library. Performing this upgrade will bring in all the security fixes that log4j has implemented since the release. It will also bring in the major fix required for the CVE-2021-44228 security vulnerability to be addressed. 

FileCatalyst is always seeking to provide secure, safe file transfers to every company worldwide, and we actively try to address security concerns as quickly as possible. We appreciate your patience with this log4j issue and ensure that we are taking adequate steps to ensure that customers who use FileCatalyst applications are not put at risk. 

Is FileCatalyst exposed to the new CVE-2021-45046 vulnerability that was recently found?

CVE-2021-45046 is a security vulnerability that was created as a by-product of the solution that was implemented for CVE-2021-44258. In CVE-2021-45046, it was found that the fix to address the previous issue would allow attackers with control over the thread context map to craft malicious input data by using a JNDI lookup. This JNDI lookup would lead to information leaks, remote code execution in some environments, or local code execution in all environments. The CVE-2021-45046 security vulnerability meets all of the conditions for CVE-2021-44258, and it is currently present in all log4j versions between 2.0.0 and 2.16.0.

When it comes to the CVE-2021-45046 vulnerability, FileCatalyst applications are not exposed and are not subject to any issues contained within the vulnerability. Similar to the previous issue (CVE-2021-44258) CVE-2021-45046 requires that the application must be using a 2.x implementation of log4j to be impacted. Currently, FileCatalyst applications only reference a log4j instance that is version 1.2.17. This older log4j version falls outside of the impact version list, and thus, the FileCatalyst applications are not impacted by CVE-2021-45046.

Is FileCatalyst exposed to the new CVE-2021-45105 vulnerability that was recently found?

CVE-2021-45105 is a new security vulnerability that was created as part of the investigation into log4j. This vulnerability states that Apache Log4j versions 2.0.0 through 2.16.0 did not protect from uncontrolled recursion during self-referential lookups. This omission allows attackers with control over the thread context map data to cause a denial of service attacks when particularly crafted strings are interpreted by the log4j implementation.

When it comes to this vulnerability, FileCatalyst applications are not exposed and are not subject to the vulnerability. In order to expose this vulnerability to users, applications must use a 2.x release of log4j within their application distributable. Currently, FileCatalyst applications do not reference any 2.x release of log4j within their distributable. While there is a reference to a log4j implementation, the version of the implementation is 1.2.17, and as such, is not vulnerable to the CVE-2021-45105.