« All blog posts

Log4Shell Attack Exploit

16.12.2021


The original article was published on 13.12.2021. Several updates to the post have been made on 14.12.2021, 16.12.2021, 20.12.2021, 17.02.2022 and 16.03.2022.

An extremely severe Zero-day security issue CVE-2021-44228 was discovered on December 10 in the Java logging library, log4j v2.x.

Apache released log4j version 2.15.0 to fix the issue. They also published ways to mitigate the issue in earlier log4j versions, in case you cannot update them.

Software Release Chronology

UPDATE 16.03.2022: The final update has been made to Prosys OPC UA Simulation Server. In the newer version of the application the Log4j2 library has been updated to version 2.17.2.

Security updates are now available for the following products:

UPDATE 17.02.2022: After the log4shell updates Apache Foundation has released newer version of log4j2 that fixes some CVEs. We have released newer versions of our applications with log4j2 2.17.1, which fixes the issues.

We would recommend everyone to update to these versions. However, we also want to note that while we are affected by one of the CVEs, in practice it should have no impact per se. See https://logging.apache.org/log4j/2.x/security.html for more information about the CVEs.

Please note, the Prosys OPC UA Simulation Server will be updated on a later date. Ask for beta version of the application from Simulation Server Support Channel if needed.

For the CVE-2021-45105, the default logging configuration our apps make does not include MDC in the pattern, thus we should not be affected.

For the CVE-2021-44832, per apache’s page: “(previous versions) are vulnerable to a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file”. So the filesystem would have to be compromised for this to happen. In general our applications do not expect a hostile (local) environment. Typically this kind of vulnerability could be used for a privilege escalation attack, but with our apps basically the user running the application should also be the same to only have write permissions to the configuration files (as the apps made them when they first start up). Also in the case of “multi-user” applications like Browser and Monitor, each user will have their own configuration files. This means any attacker that would be able to use the CVE via the application would already have permissions to do everything without needing to “go through” our application. Thus, the CVE should have no impact. For Modbus Server portable or docker distribution flavor or if any permissions have been modified after might change the situation.

UPDATE(20.12.2021): Apache released log4j2 version 2.17.0. It fixes CVE-2021-45105, however, our own applications are NOT affected, since we do NOT use Context Lookups in our PatternLayout the application creates on first startup.

UPDATE(16.12.2021): Apache released log4j version 2.16.0 earlier this week to further limit the possibilities for additional vulnerabilities and finally another issue, CVE-2021-45046 was discovered on December 14. Turned out that log4j 2.16.0 also fixes this issue.

We have been identifying the vulnerability and how it affects our Java-based OPC UA products and released updates to them accordingly. Below you can more information about the products affected by the vulnerability.

Prosys OPC UA products affected

The vulnerability affects directly

The server applications log by default values that are client-controlled, thus are affected by the attack.

The vulnerability might affect

This is assuming they would connect to a specially crafted server that would send data that gets logged and triggers the vulnerability in the logger.

Not directly affected

Only affected if you have used log4j version 2.x (log4j2) as your logging library of choice. The SDK has used SLF4J since version 2.x. SLF4J can be directed to log4j2, but that configuration is done on the application level (as is done in our end-user products).

The SDK sample applications also use log4j1, which is compatible with Java 6.

The SDK version 1.x was using log4j version 1 (log4j1) directly.

Log4j1 is NOT affected by Log4Shell.

UPDATE(16.12.2021): Since here are other known vulnerabilities in log4j1, we recommend to update to the latest log4j2 wherever possible. Please, see more details about these in our forum.

For users of SDK 1.x we recommend to update to the latest version of the SDK (first to 3.x and then to 4.x), if possible.

For users of SDK 1.x we recommend to update to the latest version of the SDK (first to 3.x and then to 4.x), if possible.

Not affected

UPDATE (14.12.2021): These products are not affected by the issue since they are not Java-based and therefore they don’t include log4j:

Fixed products

UPDATE (16.03.2022): Updated the list with the versions that include log4j version 2.17.2 (Prosys OPC UA Simulation Server only).

UPDATE (17.02.2022): Updated the list with the versions that include log4j version 2.17.1.

UPDATE (16.12.2021): Updated the list with the versions that include log4j version 2.16.0.

More security information

You can find the currently announced security issues in Prosys OPC products in our blog under the #Security tag.

You might also be interested in OPC UA Security Process of the OPC Foundation.

Tags: OPC UA, Security

comments powered by Disqus

About Prosys OPC Ltd

Prosys OPC is a leading provider of professional OPC software and services with over 20 years of experience in the field. OPC and OPC UA (Unified Architecture) are communications standards used especially by industrial and high-tech companies.

Read more about us »

Newest blog posts

OPC UA and Open Industry 4.0

Learn how OPC UA and Open Industry 4.0 complement each other.

OPC UA PubSub to Cloud via MQTT Demo at Hannover Messe 2022

Combining Raspberry Pi 4 and Prosys SDK for Java for Cloud Demo

OPC Day International 2022 - All Presentations

The whole program and all presentations of the largest OPC Day ever.

View all blog posts »

-->