Log4j vulnerability

As you may have seen in the news, a new zero-day exploit has been reported against the popular Log4J2 library which can allow an attacker to remotely execute code and potentially extract information. The vulnerability has been reported with CVE-2021-44228 against the log4j-core jar and has been fixed in Log4J v2.15.0.

 CyberQuest appliance uses several services which employ Log4J functionality.

 Possible affected services are:

 – ElasticSearch: 2.x (which is not affected), 7.X ElasticSearch 7.x (which is affected, see https://discuss.elastic.co/t/apache-log4j2-remote-code-execution-rce-vulnerability-cve-2021-44228-esa-2021-31/291476#elasticsearch-announcement-esa-2021-31-21).

– DataStorage < 2.20.12 and < 2.30.7 .

– Cerebro service

 None of the above CQ services are directly exposed on the network. ElasticSearch is used by Data Acquisition service and Web Application (not directly), Data Storage does NOT expose itself directly on the network and just listens for data and commands on the RabbitMQ cluster, hence the attack surface is really small.

 Nonetheless, customers should take the necessary steps to ensure remediation of this vulnerability so that  no potential data loss occurs:


Steps for remediation for Data Storage (on Debian 10 Buster):

 I. Ensure that the public update repository is installed in your enviroment:

1) log on to the virtual appliance through ssh  and superadmin user

2) verify that official CYBERQUEST repositories are installed. if not, add them:

  wget -qO – https://deb.cyberquest.cloud/public/public.key |  sudo apt-key add –

 echo “deb https://deb.cyberquest.cloud/public/ buster-prerelease main” |  sudo tee -a   /etc/apt/sources.list.d/cyberquest-cloud.list

 sudo apt-get update

 3) update the enviroment

sudo apt-get install datastorage=$(apt-cache policy datastorage|grep Installed|awk -F ‘ ‘ ‘{print $2}’|awk -F ‘.’ ‘{printf “%s.%s*”,$1,$2}’)


II. Steps for remediation for Vulberable ElasticSearch:

1) check ElasticSearch version:

 curl http://localhost:9200/

 Example response:


  “name” : “cyberquest”,

  “cluster_name” : “ES.20211214075804”,

  “cluster_uuid” : “FQZ4uU-7S5uFbgdZQ59Paw”,

  “version” : {

    “number” : “7.10.2”,

    “build_flavor” : “oss”,

    “build_type” : “deb”,

    “build_hash” : “747e1cc71def077253878a59143c1f785afa92b9”,

    “build_date” : “2021-01-13T00:42:12.435326Z”,

    “build_snapshot” : false,

    “lucene_version” : “8.7.0”,

    “minimum_wire_compatibility_version” : “6.8.0”,

    “minimum_index_compatibility_version” : “6.0.0-beta1”


  “tagline” : “You Know, for Search”


 If major version is 2, because it is using Log4J v1.x, that version is not vulnerable.

If major version is 7 you need to ensure that the the proper flags are set into the JVM on each node:

sudo sh -c ‘if [ $( grep -c “formatMsgNoLookups” /etc/elasticsearch/jvm.options ) -lt 1 ]; then echo “-Dlog4j2.formatMsgNoLookups=true”| tee -a /etc/elasticsearch/jvm.options; fi’

2) Do a cluster rolling restart (restart each node).

3) Ensure proper CQ operation


III. Remove the cerebro service

sudo apt-get remove cerebro


Check this page for new updates.