Asana’s Response to CVE-2021-44228
Asana Security has determined that while Asana’s codebase is not vulnerable to CVE-2021-44228 (also known as Log4Shell), some of our subprocessors or third-party vendors are affected. We are working with them to understand how they are affected, patch when we are able to, or disable their services if necessary.
We do not use log4j2 in our codebase, and our code dependencies likewise do not use it. One of our dependencies used log4j1, which has a vulnerable non-default configuration, but we did not use that configuration. As a precaution, we removed log4j1, as it was unused. In our Jira integration, we use log4j1 in a non-vulnerable configuration, and customers do not need to update it.
We are currently working with our subprocessors and other vendors to determine their susceptibility to CVE-2021-44228. Some of our vendors have told us that they were susceptible to CVE-2021-44228, and we will continue to talk to them to understand the impact to them and to Asana.
We identified some IT infrastructure components that needed to be updated (such as Jamf), and we updated those components. We are now looking at all of the software deployed to our endpoints to confirm that they have been updated or that they are not affected.
To confirm that the Asana codebase and IT infrastructure were not affected, we searched our logs for any indications of successful attacks, and were not able to find any. We will continue to monitor this situation as it develops.
We will continue to update you as we continue our incident response.
What you should do
You should check to see if your code is vulnerable to CVE-2021-44228 (also known as Log4Shell). Log4j 2 version < 2.15 are vulnerable. Log4j 1 is vulnerable in certain non-default configurations. All developers should update to 2.15 or 2.16.
For those who cannot upgrade to 2.15.0 or newer, in releases >=2.10, this behavior can be mitigated by setting either the system property log4j2.formatMsgNoLookups or the environment variable LOG4J_FORMAT_MSG_NO_LOOKUPS to true. For releases >=2.7 and <=2.14.1, all PatternLayout patterns can be modified to specify the message converter as %m{nolookups} instead of just %m. For releases >=2.0-beta9 and <=2.10.0, the mitigation is to remove the JndiLookup class from the classpath: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class.
