CVE-2021-44228 (Log4J Zero Day) Exploit

Is OpenSpecimen vulnerable to CVE-2021-44228 (Log4J Zero Day) exploit?

The answer is No.

OpenSpecimen uses Log4j 1x framework for logging purpose. To be precise - 1.2.16. This framework is devoid of all the bells and whistles present in Log4j 2x framework that are not required for OpenSpecimen’s simple logging requirement.

The Log4J versions that are affected by this exploit are - all versions from 2.0-beta9 to 2.14.1

The exploit is primarily because of the JNDI lookup feature added in Log4J 2x, which allows malicious users to remotely execute malicious programs (RCE).

For your assurance/confirmation, you can check there is no JNDI lookup related feature in the Log4J framework used by OpenSpecimen:

TOMCAT_HOME: Absolute path of the directory housing the Tomcat container.

But OpenSpecimen is using Log4J 1x, which has reached EOL? Any upgrade plans?

Log4J 1x, to our knowledge, has no security vulnerabilities at the time of this writing (Dec 11, 2021). To mitigate the future security risks, we are proactively working to use the latest Log4J 2x framework (Log4J 2.15.x) starting from v8.2.x builds, slated for release in the last week of 2021 or early weeks of 2022. The ticket to track the upgrade can be found here - https://openspecimen.atlassian.net/browse/OPSMN-5768

Log4J 1x has other RCE vulnerabilities (CVE-2021-4104). Is OpenSpecimen impacted by these vulnerabilities?

There is no threat as long as OpenSpecimen logging is configured to use only file based appenders. The server is prone to RCE security exploits when the logger is configured to use JMSAppender or SocketAppender.

By default, OpenSpecimen logging is configured to use rolling file based appender, which, to the best of our knowledge, is devoid of any RCE vulnerabilities.

However, to mitigate or rule out the slightest of the possibilities, follow the given steps:

1. Login to the OpenSpecimen VM

2. Navigate to $TOMCAT_HOME/webapps/openspecimen/WEB-INF/lib

3. Execute the following command to confirm the presence of vulnerable classes
   $ unzip -l log4j-1.2.16.jar | egrep 'net/JMSAppender.class|net/SocketServer.class'

4. Remove the vulnerable classes from the Log4J package
   $ zip -d log4j-1.2.16.jar org/apache/log4j/net/JMSAppender.class org/apache/log4j/net/SocketServer.class

5. Rerun the command given in step #3 to confirm the classes are removed from the package.

6. Restart OpenSpecimen.

Best Practices

Irrespective of Log4J 1x or 2x, as a best practice, the OpenSpecimen VM should be restricted from making outbound connections. If it has to make connections to the external systems like email server then those system IP addresses or hostnames should be in the whitelist. All other outbound traffic should be summarily rejected by the firewall rules. This will ensure there are no connections to the malicious servers and therefore no malicious programs on the VM.