A List of Vulnerable Products to the Log4j Vulnerability
Details on What Vendor Products Are Impacted by This Flaw.
Two days ago, we wrote a post about the Log4j vulnerability that is currently wreaking havoc on the cyberthreat landscape. The flaw stands for an open-source Java logging library. By exploiting this vulnerability present in software apps and services worldwide, being part of the Apache Logging Service, hackers can perform remote code execution attacks (RCE).
What Is Log4j and How Has It Been Addressed?
The Log4Shell vulnerability is a JNDI injection exploit. The JNDI API provides discovery and lookup of resources by name and returns the result in the form of serialized Java objects. JNDI provides a Service Provider Interface (SPI) for flexible implementation of the backend naming and directory service protocols. To select the service provider, JNDI follows a URI format allowing provider and name to be specified during the request. (…) Exploiting the Remote Command Execution (RCE) is not as seamless compared to many known RCE that allow shell code to be injected directly into HTTP requests. An attacker will need to trigger log4j to query a remote service, which in turn will need to return the location of a malicious Java object that will result in command execution upon deserialization.
Following the exploitation of this vulnerability dubbed for the moment CVE-2021-44228, Apache released an emergency security update, the Log4j 2.15.0. The flaw can be also found under the names: Log4Shell or LogJam.
CISA Releases Guidance on Log4j Vulnerability
Jen Easterly, the CISA director, declared on Saturday’s statement that the agency is collaborating with private and public sector partners to find a solution for this issue.
We are taking urgent action to drive mitigation of this vulnerability and detect any associated threat activity. We have added this vulnerability to our catalog of known exploited vulnerabilities, which compels federal civilian agencies — and signals to non-federal partners — to urgently patch or remediate this vulnerability
Following this declaration, CISA released yesterday guidance on this matter. According to the agency, companies should immediately implement and prioritize the running of the available patches to address the Log4j vulnerability. Besides, if they cannot apply the patch, another method would be to set the log4j2.formatMsgNoLookups to true. This can be done by adding the string Dlog4j2.formatMsgNoLookups=True to the Java Virtual Machine command. It seems that this mitigation measure works only for 2.10 versions and later.
Vendors Advisories on Log4j Vulnerability
After the data about this vulnerability became public, vendors began an investigation to see if and which of their products are vulnerable. According to BleepingComputer, here is the list along with advice from every company:
Adobe identified that the product that is impacted by Log4Shell is ColdFusion 2021. In this sense, the company released on the 14th of December a security update. They also informed about a workaround in case if the patching of this flaw cannot be done.
What did Amazon was to update various products with a non-vulnerable Log4j version. Affected services, in this case, are OpenSearch, AWS Glue, S3, CloudFront, AWS Greengrass, and API Gateway for which the company published some updates here.
According to the company, no on-premise products are vulnerable when speaking of their default configuration. However, what may cause the risk or remote code execution in products like Jira Server & Data Center, Confluence Server & Data Center, Bamboo Server & Data Center, Crowd Server & Data Center, Fisheye, and Crucible is if the default logging configuration is modified and then the JMS Appender activated.
Many Symantec products impacted by this flaw were addressed by Broadcom, as the company published articles with knowledgebase and mitigations in this sense.
A list of Cisco products impacted by Log4j has been released by the company. You can find it here. Along with this list, it also published a calendar that indicated that some of the products will be patched starting yesterday.
Regarding Citrix, an investigation is ongoing currently, but no Citrix products have been listed as vulnerable to this bug at the present time.
A ConnectWise advisory said that third-party components of their cloud service named Perch were “potentially vulnerable”. According to the company, the impacted third party seems to be FortiGuard’s FortiSIEM used by the StratoZen solution.
As per a threat forum, in this case, only cPanel Solr plugin instances are impacted and are prone to local exploitation. A security update is now available for cpanel-dovecot-solr package for this flaw.
According to Debian’s advisory, Debian 9 (Stretch), 10 (Buster), 11 (Bullseye), and 12 (Bookworm) received the patched Log4j package.
The company is currently trying to update Log4j 2 in these images to have the latest version installed.
According to a company’s advisory, almost a dozen of their products are impacted. Fixes were deployed for 4 of these products.
The FortiGuard advisory is going to be updated with other future applied patches for FortiSIEM, FortiInsight, FortiMonitor, FortiPortal, FortiPolicy, and ShieldX products.
Log4Shell impacts various F-secure products that run either Windows or Linux versions. These are Policy Manager (only the Policy Manager Server component), Policy Manager Proxy, Endpoint Proxy, and Elements Connector.
A security patch was released by the company in this sense a guide for admins to implement it.
The tool was updated to version 10.1, effective to make the Log4j dependency non-vulnerable.
Only versions 9.0 and 8.5 of WebSphere Application Server were impacted by this flaw, according to an advisory by IBM. The company addressed this matter.
According to Juniper, Log4Shell impacted 4 products: Paragon Active Assurance, Paragon Insights, Paragon Pathfinder, and Paragon Planner.
The assessment is however ongoing, but potential other impacted products could be: JSA Series, Junos Space Management Applications, Junos Space Network Management Platform, Network Director, Secure Analytics, and Security Director (not Security Director Insights).
McAfee is currently reviewing 12 products and the advisory is going to be updated.
MongoDB Atlas Search required a Log4Shell patch, according to an advisory by MongoDB, however, no indicators of compromise or exploitation proof had been found before patching.
Okta addressed Okta RADIUS Server Agent and Okta On-Prem MFA Agent with these updates to mitigate the flaw’s risk.
The company published an advisory on Friday saying that Zed Attack Proxy (ZAP) versions below 2.11.1 are leveraging a Log4j component that is vulnerable.
Log4Shell is impacting various RedHat products components, as per the Friday declaration of the company, products like Red Hat OpenShift 4 and 3.11, OpenShift Logging, OpenStack Platform 13, CodeReady Studio 12, Data Grid 8, and Red Hat Fuse 7.
Various Siemens products are impacted. While some have been addressed, others are still undergoing some tests. The company published an advisory with mitigations and workarounds. Therefore, customers are advised to immediately follow this guideline or update the Siemens software to reflect the most recent version.
A vulnerable Apache Log4j version is being used by two SolarWinds products. These are Server & Application Monitor (SAM) and Database Performance Analyzer (DPA). However, the Java Development Kit (JDK) version these products use limits the risk.
The Log4j library is being used by a SonarQube ElasticSearch component. Mitigation is provided by the company.
Another thing to mention here is that SonarCloud was updated with a Log4j vulnerability version that is non-vulnerable.
Log4Shell impacts SonicWall’s Email Security version 10.x, as the result of the investigation says. The company is working on a fix. The enterprise also published an advisory, saying that it investigated 5 other products and asserting that the rest of the products are not impacted.
According to the company, Sophos Mobile EAS Proxy is the one vulnerable to this flaw. The issue can be addressed with version 9.72.
Sophos Email and Cloud Optix are already patched.
A table containing the on-premised and cloud product versions this bug affects has been published by the company. Some products already received fixes.
Only Vision One, Trend Micro Email Security & HES, TippingPoint Threat Management Center (TMC), Sandbox as a Service, and Cloud App Security were patched, as Log4Shell does not impact most of the TrendMicro products.
Various VMware products were fixed and there is a work in progress to address another 27 products with patches.
According to a company’s advisory, almost 40 VMware products are impacted.
The Log4j library is used by The UniFi Network Application which was updated.
According to the security advisory, the Log4j package was patched upstream.
ADAudit Plus component is vulnerable to this bug. Instructions to mitigate this issue were provided by Zoho.
The company patched Private Access (ZPA) services along with Zscaler Mobile Admin, and Support Mobile Admin components, drawing the conclusion that the problem is fixed in all products.
You can find the full list of products in the GitHub repository of the Dutch National Cyber Security Centrum.
We would like to remind our customers and business partners who use Heimdal™ web-based services that the log4j vulnerability has no influence on the quality of our service, data integrity, or the client’s privacy.