Log4j zero-day vulnerability

Last Updated: Dec 20, 2021 9:30AM

At Constella we take information security and privacy very seriously.  We are aware of the log4j zero-day vulnerabilities.  Some of the applications used by Constella as well as toolset we use could be vulnerable. The Log4j vulnerabilities are part of the Log4j development libraries that facilitates application logging, these vulnerabilities could allow an attacker to gain unauthorized access. We have taken step to mitigate the risk of attack are actively working to remediate the vulnerability within our product offering. All Constella SaaS products require multi factor authentication and only authorized users can access any and all of the functionality, with no anonymous access allowed.  In addition, Constella also deploys each product and micro-service with zero-trust network segmentation that further restricts any data access from each node.

Intelligence API Services

Not Vulnerable; Intelligence API Services product is not based on Java Stack, hence the product itself is not vulnerable to the Log4j CVE-2021-44228. ID Services uses Elastic Search and Kibana internally as part of the underlying infrastructure.

Dec 20, 2021 update:

In an abundance of caution, we are implementing all measures recommended by elastic search, and it is tested in the QA Environment and updated in the preprod/integration environment. We plan to roll out the updates to production on Wednesday.

In addition, all calls to the API Services are whitelisted to be allowed from trusted IP addresses only.  We have observed that any attempts to access the vulnerability through our API are being rejected by the API gateway.

Continued Monitoring. Available monitoring in place appears to be sufficient for this vulnerability, and we continue to monitor the situations and our access logs as the situation evolves.

Dome

Log4j Vulnerabilities addressed. As a response to the CVE-2021-44228, all Dome instances have been patched to Log4j 2.15 as of Dec 14th.  Subsequently, Dome was updated to Log4j 2.16 on Dec 16th in response to CVE-2021-45046.

In response to CVE-2021-45105, on Dec 20th all Dome instances have been patched to Log4j 2.17

No impact to customer data. We have both internal and external tools monitoring our infrastructure, including POC environments.  Based on our analysis and the notifications we have received through these tools, we concluded that there is no impact to any of our customer data.

Continued Monitoring. Available monitoring in place appears to be sufficient for this vulnerability, and we continue to monitor the situations and our access logs as the situation evolves.

Analyzer

Log4j Vulnerabilities addressed. As a response to the Log4J CVE-2021-44228, all instances were patched to Log4j v2.15 on Dec 14th.  All instances are patched again on Dec 15th in response to CVE-2021-45046.  

In response to CVE-2021-45105, on Dec 20th all Dome instances have been patched to Log4j 2.17

 

3rd party products

All third-party services used by Analyzer (such as Elastic Search) are also being assessed to determine if vulnerable and will be updating them once patches are available and tested.

All calls to internal services have strict firewall rules in place and not accessible from the internet.

Tracker

A few internal modules of Tracker are using the impacted version of the Log4j.  A patch (3.0.36) with an update to Log4j 2.15 was created on Dec 14 to address the initial Log4j vulnerability (CVE-2021-44228). 

On Dec 20 we made available a patch 3.0.37 for all Tracker customers that addresses the Log4j CVE-2021-45046 and CVE-2021-45105 and applied to all environments that were accessible to our operations team.

 

Hunter

Not Vulnerable; Hunter and reliant components are not Java.  We have also ensured no internal or third-party modules are able to exploit this vulnerability.

On Dec 20 we made available a patch 3.0.37 for all Tracker customers that addresses the Log4j CVE-2021-45046 and CVE-2021-45105 and applied to all environments that were accessible to our operations team.  

MXP / Domain Exposure Monitoring

Not Vulnerable; The MxP Portal and reliant components are not Java based and do not use Log4J.  We have ensured no internal or third-party modules are impacted by the vulnerability.