Following the recent critical CVE issue with Log4j (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228) a second, lower severity CVE was made public December 14, 2021 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046). This second CVE is not mitigated by the previously provided mitigation script, however it is important to note that this is a separate issue to the one initially disclosed and has a much lower severity rating at the current moment.
Current advice from Elasticsearch (ES) regarding this new CVE and the mitigation previously provided indicates that it will still protect users against information leaks:
“Update 15 December: A further vulnerability (CVE-2021-45046) was disclosed on December 14th after it was found that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations. Our guidance for Elasticsearch and Logstash are unchanged by this new vulnerability and we are currently working to assess other products in order to provide a clear statement.”
It is also worth noting that:
Details on Elasticsearch information leakage
The information leakage vulnerability in Log4j enables an attacker to exfiltrate certain environmental data via DNS – it does not permit access to data within the Elasticsearch cluster. The data that can be leaked is limited to those available via Log4j “lookups”, which includes system environment variables and a limited set of environmental data from other sources.
The threat from the Denial of Service (DoS) that this new CVE presents can’t yet be fully dismissed. However early reports of testing this attack vector have indicated that it has a lower impact and is considered a limited DoS:
“However, in our testing we did not find this DOS to be resource consuming as it seemed that the infinite loop created by recursively resolving ${ctx:apiversion} was identified by the program and errored out.” – https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046/
Here at VQ Communications we are actively monitoring the situation and incoming CVEs. As many security analysts are predicting that this situation is far from finished developing we continue to advise caution in exposing of your VQCM virtual machines and APIs to the public internet. There is every chance that more details regarding these CVEs and as yet undisclosed issues will surface in the coming days or weeks. We advise a defensive posture until such point as customers can upgrade to the 3.9 release of VQCM (due January 17, 2022).
The following posts provided additional background information:
https://www.lunasec.io/docs/blog/log4j-zero-day-update-on-cve-2021-45046/
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
Summary:
1. The guidance from Elastic remains that the mitigation outlined in our mail yesterday still holds for the information leak. Apply the mitigation script if you haven’t already. When VQCM 3.9 becomes available in January (target Jan 17, 2022), update to VQCM 3.9.
2. Minimize public internet exposure wherever possible. If you do need to expose a public service, ensure only HTTPS ports are open and use a reverse proxy or equivalent.
We have added a link on the home page of vqcomms.com; it links to the latest status and all of our posts related to this CVE.
The Mitigation Script and guidance to using it can be found here:
- Navigate to the https://www.vqcomms.com/resources/ page, log in and download the “log4j2-cve.zip” file from the “CVE-2021-44228 Mitigation Script” category. A User Guide can also be downloaded.
regards
The VQ Team