Claroty Finds Critical Flaws in OPC Protocol Implementations
By Uri Katz | January 25, 2021
The Open Platform Communications (OPC) network protocol is the middleman of operational technology (OT) networks, ensuring operability between industrial control systems (ICS) and proprietary devices, such as programmable logic controllers (PLCs) responsible for the correct operation of field devices. Having standardized communication protocols such as OPC and its specifications (OPC DA, AE, HDA, XML DA, DX, and OPC UA) guarantees that management and oversight of devices and processes can happen from a centralized server.
The Claroty Research Team decided that due to its popularity as an embedded protocol operating in devices across the ICS domain, OPC was worthy of analysis for security vulnerabilities and implementation issues. In the coming weeks, we will publish an in-depth report about OPC and its various flavors, but for today, we want to share some details about a number of vulnerabilities that emerged from our intensive investigation of the protocol.
Throughout 2020, Claroty privately disclosed critical flaws in several vendor implementations of the OPC protocol. Organizations that use these vendors’ products built on OPC are exposed to attacks that could result in denial-of-service conditions on devices, remote code execution, and information leaks of sensitive device data.
Three vendors—Softing Industrial Automation GmbH, Kepware PTC, and Matrikon Honeywell—have provided fixes for their respective products. Users of affected products are urged to determine whether they are vulnerable and update immediately to the latest versions. The Industrial Control System Cyber Emergency Response Team (ICS-CERT) has also published advisories, warning users of the affected products about the risks. Update and mitigation information is also available in the advisories.
Here are the ICS-CERT advisories for each of the affected vendors:
The following sections provide some details on vulnerabilities uncovered by The Claroty Research Team in Softing’s Industrial Automation OPC library, Kepware PTC’s ThingWorx Kepware Edge and KEPServerEX OPC servers, and Matrikon’s Matrikon OPC Tunneller.
These three products are integrated into many other vendors’ offerings as a third-party component. For example, Softing’s OPC library is being used as a third-party OPC protocol stack by some vendors, and the KEPServerEX OPC Server is being used as an OEM shelf solution by other well-known vendors, including Rockwell Automation and GE, both of which have published advisories informing their users of these security issues. We believe these vulnerabilities may affect multiple other products sold by vendors across all ICS vertical markets.
Here is a brief summary of each vulnerability uncovered by Claroty:
All versions prior to the latest build, 4.47.0, are vulnerable.
Claroty discovered two vulnerabilities in the Softing OPC DA XML library’s handling of OPC DA XML. One vulnerability was found in its transport layer—specifically the HTTP SOAP server—while the other flaw targets XML data. Both are trivial to exploit and lead to denial-of-service conditions. All versions prior to the latest build of the library, version 4.47.0, are vulnerable.
The first is a heap-based buffer overflow vulnerability in the Softing OPC DA XML library that may allow an attacker to crash the Softing server and possibly execute code. ICS-CERT assigned this flaw a CVSS score of 9.8.
The issue lies in the fact that the Softing web server fails to limit SOAP header lengths, nor does it sanitize the values of SOAP headers as it parses them as OPC DA XML over SOAP.
Exceptionally long headers will cause the server to endlessly allocate memory; memory allocation does eventually fail because of resource consumption of heap memory. But the web server does not check the return code of the memory allocation and tries to copy our data to the returned pointer. But since the returned pointer is NULL, an attacker’s data is copied to uninitialized memory, eventually causing an access violation exception and a crash of the server.
The second flaw is a resource consumption bug, which occurs when an invalid value is used within certain parameters. That value will create a loop that runs indefinitely to cause high memory consumption and denial-of-service conditions.
KEPServerEX v6.0 to v6.9 is vulnerable, as are ThingWorx Kepware Server v6.8 and v6.9 and all versions of ThingWorx Industrial Connectivity and OPC-Aggregator.
Claroty uncovered OPC UA vulnerabilities in Kepware PTC’s ThingWorx Edge and KEPServerEX servers that lead to denial-of-service conditions, sensitive data leaks, and potentially, code execution. Kepware’s OPC protocol stack is embedded as a third-party component in many products across different industries.
The stack-based overflow vulnerability was found in the ThingWorx Edge Server. Attackers could crash, and under certain conditions, potentially execute code on a vulnerable server remotely and without authentication. Claroty researchers found the flaw in the logic for decoding OPC strings that allows an attacker to copy a string longer than 1024 bytes without allocating more memory. This flaw can be triggered pre-authentication and will allow for data on the stack after the first 1024 bytes to be overwritten.
Claroty researchers also found an information leak resulting from a heap out-of-bounds read, also in the ThingWorx Edge Server’s string decoding flow. This bug affects Windows and Linux versions of the server and could also crash the machine.
The use-after-free flaw, another pre-authentication flaw, was found in the Kepware KEPServerEX Edge Server transport layer. Claroty researchers used a simple fuzzer and Valgrind to investigate the server, and they discovered a race condition leading to a use-after-free condition. We investigated the trace and determined that an event for the connection is raised after the connection is closed, and when the program tries to use the freed connection object, it crashes.
All versions prior to 220.127.116.1133 of the Matrikon OPC UA Tunneller are vulnerable. The vendor recommends updating to version 18.104.22.16833
Claroty found multiple vulnerabilities in different Matrikon OPC Tunneller components, including a critical (9.8 CVSS) heap overflow flaw that could allow for remote code execution on affected machines. In addition, other conditions could be exploited that would result in denial-of-service attacks on devices because of excessive resource consumption or improper checks.
Claroty also found heap out-of-bounds (OOB) vulnerabilities in the Matrikon OPC Tunneller where an attacker could force a memory leak. The leak could enable an advanced attacker to carry out other exploits on the network.
By exploiting these vulnerabilities, attackers can control the overwritten memory space outside the targeted buffer and can redirect a function pointer to their malicious code. In other words, attackers that exploit those vulnerabilities could also achieve remote code execution and take over the OPC server.
Two other denial-of-service vulnerabilities were also discovered, both with CVSS scores of 7.5.
Users should upgrade to the latest version of each of these products to close down these vulnerabilities. In the meantime, it’s important to continue to research and address vulnerabilities in OT communications protocols, such as OPC.
OPC is the communication hub of an OT network, centrally supporting communication between proprietary devices that otherwise could not exchange information. It’s deeply embedded in many product configurations and OPC-centered development and usage figures to continue. Claroty’s findings likely affect many other products because it’s often impractical to implement OPC as a standalone component, and vendors will opt instead to implement third-party libraries (e.g. Softing’s OPC library) or white label off-the-shelf products (e.g. PTC Kepware OPC server)
Also contributing to the expansive use of OPC is the fact that many vendors are already connecting parts of their networks that communicate using OPC to the cloud. This introduces industrial IOT devices into the equation, those that both receive and exchange device and process information.
Attack surfaces, therefore, will expand, and organizations must examine their respective implementations for weaknesses. Meanwhile, the community must also support enhanced security and research into undiscovered vulnerabilities and protocol shortcomings.