17 Dec 2021: Summary: You will be aware that there has been a widely reported vulnerability with Log4jJ, which has affected many internet properties. Log4j vulnerability was a low risk for the CustomerGauge product, and after investigation we have not found affected systems. We have already taken action to address this remaining risk.



Background: 


A critical flaw in widely used software has cybersecurity experts raising alarms and big companies racing to fix the issue. The vulnerability, which was reported late last week, is in Java-based software known as "Log4j" that large organizations use to configure their applications -- and it poses potential risks for much of the internet.



Summary of Actions:

Following last weekend’s breaking news story of a high severity vulnerability in the popular ‘Log4j’ java logging library, the CustomerGauge technical department has been performing a review of its service dependencies to check for Log4j related vulnerabilities.


The focus was on 3rd party dependencies as the CustomerGauge product doesn’t make use of any java code and so we were already confident that there were no direct Log4j connections.


Our search began on Amazon Web Services (AWS) as CustomerGauge is a cloud native application that relies heavily on AWS services.   AWS have been very transparent and responsive since the vulnerability was first announced and we used their official security bulletin status page for reference. https://aws.amazon.com/security/security-bulletins/AWS-2021-006/


CustomerGauge has a strategy of using AWS Managed Services wherever possible.  Amazon, acting at huge scale, take responsibility for the security and continuity of the service they provide.   All the AWS managed services relevant to CustomerGauge were confirmed as not vulnerable or already patched over the weekend of 11-12 December.


However, there were two third party services CustomerGauge was running in the AWS cloud that were not managed by AWS:  ElasticSearch and Logstash, both of which were declared as potentially vulnerable.  


Our initial risk assessment was that the usage of these components in the CustomerGauge context presented only a low risk.   But we performed the following analysis and actions:

  • Elasticsearch:   Was judged as low risk as it ran in its own private account so had a limited blast radius. Although officially an AWS managed service, the advice was to run a manual upgrade using update R20211203-P2.  This was run on our ElasticSearch v7.9 cluster on 15/12/21.    
  • Logstash: Was running in a production account, but it did not use Log4j to record CustomerGauge logs; it only used Log4j for its own error logs.  It was hence judged as low risk  as an attacker would not only need to find a way to inject a malicious string, it would also need to inject it in a way that caused the application logging system to fail and then go on to output the malicious string as an error message.   

We also addressed the Logstash vulnerability on 15/12/21.  We did this by removing the jndi  java component from the Logstash container instances and services.  We ran before and after tests that proved that this successfully neutralised the vulnerability.  


CustomerGauge is aware that major vulnerability reports like this one are often followed by ‘after-shock’ reports due to the intense scrutiny the original report causes.  We will continue to be vigilant and keep you informed of any new developments. 

 

If you have more questions, do contact us through the support site and reference Log4j. 


CustomerGauge Security Team