Update 16 December 2021@11:20
Cisco have now completed their assessment of their hardware/software products and the full list confirming which are vulnerable/not can be found here, however there is still a large portion of their cloud offerings under review: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd.
Extreme still have 3 products under investigation but of all the others completed, only one is vulnerable (Extreme): https://extremeportal.force.com/ExtrArticleDetail?an=000100806&_ga=2.8924661.1942628706.1639384902-1261081976.1634634957
Links for the second vulnerability in Log4j:
Mitre CVE Details: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046
Update 15 December 2021 @ 11:04
The Cybit team assembled to tackle the Log4j threat is continuing its work. As updates are coming in from vendors, it appears that less and less of the vendors Cybit work with have vulnerable products and many of those that are limited in risk. AWS have completed patching of all of their services where the responsibility sits with them (generally PaaS and SaaS services) but are also looking to provide mitigations on services where customers can deploye vulnerable packages.
A second vulnerability has been discovered in the Log4j library, though it has a significantly lower severity score (3.7), details can be found at: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046
Update 14 December 2021 @ 12:06
A serious threat (‘Log4Shell’) has been identified in software component called Log4j which is used by Java-based applications (this is different to JavaScript). This vulnerability has a rare classification of 10 out of 10 in terms of severity.
NSCE Response: https://www.ncsc.gov.uk/news/apache-log4j-vulnerability
Mitre CVE Details: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228
Cybit has been constantly working on and revising data around vulnerable systems as vendors release updates. Our task force is prioritising exposed and critical systems first as we apply vendor mitigations and updates to supported systems.
Unfortunately, the scope of potentially affected devices is huge because the Apache webserver is used on everything from large corporate webservers to small IoT devices and everything in between, it can be deployed on Linux, Windows and Unix based systems. Additionally, one of the most common interfaces for these devices (or in the case of a web server, its primary function) is via web pages which are served via a web server. If the application running on this device uses Java, there is a high probability it uses the Log4j library and so poses a risk.
Affected Log4j versions
Nearly all versions of log4j version 2 are affected:
2.0-beta9 <= Apache log4j <= 2.14.1
Version 1 of log4j is vulnerable to other RCE attacks, and if you’re using it you need to migrate to 2.15.0.
The impact of this exploit is severe as it allows an attacer Remote Code Execution (RCE) which can be used to gain access, exfiltrate data or cause interference/damage.
OpsView
The monitoring platform used by Cybit included the vulnerability though access to the tool is heavily restricted, the systems have been patched and there are no indications of a breach.
Datto
In addition to the key vendor responses in below, Cybit have worked with Datto, the vendor for some of our internal tooling. Datto have been extremely thorough and provided timely and detailed responses to the emerging threat, the details of which can be found here
Datto have also created tooling which Cybit are using to help identify threats on supported systems, further information on it can be found here
AWS
The AWS shared responsibility model means that AWS are responsible for updating and/or mitigating these vulnerabilities on SaaS services (Software as a Service) and PaaS services (Platform as a Service) and closed IaaS devices (Infrastructure as a Service) such as API Gateways, Load Balancers, etc. Other AWS services such as servers are the responsibility of the customer, though these are likely only vulnerable if the customer has deployed an application which uses Log4j and so introduced the vulnerability.
The full update from AWS can be found here:
https://aws.amazon.com/security/security-bulletins/AWS-2021-006/
Review your AWS estate and applications for any deployments with Java installed, work with the developers/vendors to identify the Logj4 library (advice on this can be found here). Devices which cannot be updated should have follow the mitigation steps provided by the NCSC here.
Microsoft Azure
Microsoft’s Security Response Center has provided an update addressing the vulnerability, this initial post suggests no Microsoft Azure services or products ship with Logj4, stating that “we have not found any evidence that these services are vulnerable however customer applications running behind these services might be vulnerable to this exploit”
https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/
Review your Azure estate and applications for any deployments with Java installed, work with the developers/vendors to identify the Logj4 library (advice on this can be found here). Devices which cannot be updated should have follow the mitigation steps provided by the NCSC here.
Sophos
Sophos are currently investigating their products to identify any that might be susceptible to the Log4j vulnerability and are maintaining a list of the result here:
https://www.sophos.com/en-us/security-advisories/sophos-sa-20211210-log4j-rce
At the time of writing, only two products are affected “Cloud Optix” a hosted service which has been patched and “Sophos Mobile EAS Proxy” which requires customers to update to version 9.7.2.
Check the list of effected devices regularly, update publicly accessible affected devices first (including devices not directly accessible but which may log activity for accessible devices), update remaining devices next. Devices which cannot be updated should have follow the mitigation steps provided by the NCSC here.
Extreme Networks
Extreme Networks are currently investigating their products to identify any that might be susceptible to the Log4j vulnerability and are maintaining a list of the result here:
At the time of writing, the vast majority were still being investigated but all the products completed were found to be not vulnerable.
Check the list of effected devices regularly, update publicly accessible affected devices first (including devices not directly accessible but which may log activity for accessible devices), update remaining devices next. Devices which cannot be updated should have follow the mitigation steps provided by the NCSC here.
Cisco
Cisco are currently investigating their full support product range to determine which devices are affected by the vulnerability and are updating the results here:
https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-apache-log4j-qRuKNEbd
Check the list of effected devices regularly, update publicly accessible affected devices first (including devices not directly accessible but which may log activity for accessible devices), update remaining devices next. Devices which cannot be updated should have follow the mitigation steps provided by the NCSC here.
Alteryx
Alteryx have confirmed that their products are not susceptible to the Log4Shell vulnerability, stating: “Log4j Vulnerability Log4Shell: We can confirm that our Designer, Designer Cloud, Server and Alteryx Machine Learning products do not use log4j.”
Qlik
Qlik are currently investigating their full support product range to determine which devices are affected by the vulnerability and are updating the results here:
Qlik also state that customer should “keep in mind that Qlik’s on-premises (or client-managed) products are intended to only be accessed on a internal network; therefore any potential impacts of CVE-2021-44228 should be mitigated by your internal network and access controls”.
Ensure access to Qlik systems is restricted to internal only users and only those requiring access (“Least Privilege”), if you are using products not yet evaluated, check back regularly for updates on next actions from Qlik.
Ubiquiti
Ubiquiti confirmed that their UniFi Network Application used a vulnerable version of the Logj4 library and released an updated version fixing the issue on the 10th December 2021, other products in the UniFi range are unaffected:
Apply the update, follow using uusal Ubiquiti guidelines.
Citrix
Citrix are currently investigating their products to identify any that might be susceptible to the Log4j vulnerability, at present none of the products upon which they have completed the investigation have been vulnerable. Citrix are maintaining a list of the results here:
https://support.citrix.com/article/CTX335705
Ruckus
Ruckus have now provided an update addressing the impact of Log4j at the moment and have listed multiple products as being vulnerable with links to firmware updates where available:
https://support.ruckuswireless.com/security_bulletins/313
PaperCut
PaperCut have confirmed that some versions of their Print Management software use the Log4j library, they have provided a configuration workaround and a software update here:
https://www.papercut.com/support/known-issues/?id=PO-684#ng
DrayTek
DrayTek have confirmed that none of their devices are vulnerable:
https://www.draytek.com/about/security-advisory/log4shell-vulnerability-(cve-2021-44228)/
We understand there are many options to choose from and you want to make sure the tool you adopt is the right one for you.
"*" indicates required fields
Construction in Crisis! Written by Chrissie McAnelly, Cybit Data & Analytics Consultant – Construction Sector The construction sector is
Read articleBy Asiel Esgair – Cybit Data & Analytics Consultant – Public Sector & Local Authority In our
Read article
