Ethernet Vulnerabilities in Safety Instrumented Systems (SIS): A ‘Key’ Difference

Ethernet Vulnerabilities in Safety Instrumented Systems (SIS): A ‘Key’ Difference

Dragos reported issues to Schneider Electric concerning security defects in the Triconex Safety Instrumented System (SIS) network communication module. These modules, sold under the name Tricon Communication Module (TCM), are used to connect the SIS to Ethernet networks. The defects can be used to deny service to the SIS or to pre-stage future logic attacks. End-users should note that defects in these modules may be exploited even while the SIS key switch is in “Run” mode, which is widely reported as advice to prevent manipulation of the SIS. The Triconex SIS is not unique in this regard, and other safety controllers that utilize add-on Ethernet modules are likely to be vulnerable to similar attacks, even when their key switch is engaged or other logic write protections are enabled. End users should take steps to defend their SIS by ensuring that firewalls are configured to block access to undocumented services, even from the SIS engineering workstation.

Dragos uncovered issues in the SIS, which had been fixed by the vendor previously and were never documented. These issues were never previously given CVE identifiers by the vendor, but have since been given such identifiers. Schneider Electric also produced a public advisory. Note that Dragos reported additional issues in the platform focused specifically on two vulnerabilities in the advisory: CVE-2020-7486 and CVE-2020-7491.

Background on the Triconex SIS

The Triconex SIS is architected like a typical Programmable Logic Controller (PLC) of its era. The logic processor, or MP module, communicates with other modules in the SIS via a backplane. Among the modules that can be included are TCMs. These modules present protocol access to the SIS so it can be managed via a variety of network types. The TCM allows communication with the outside world, both to data collection services and to engineering services.

The Vulnerabilities

Of the five vulnerabilities reported, two of them represent issues in Ethernet-based TCMs. The two issues identified include a denial of service (CVE-2020-7486), where the TCM module can be placed into a fault state, and a root style vulnerability that allows firmware modification of the TCM (CVE-2020-7491).

While the TCM is in the failure state due to the denial of service vulnerability, safety logic may continue to operate. It is possible, even likely, that a safety engineer would instead decide to initiate some safety action in this case. External systems would not interact with the SIS via the TCM, regardless of the safety programming. For example, if the SIS is operating as a hybrid control system that executes non-safety logic, some Human Machine Interface (HMI) operations may fail to materialize.

The root vulnerability allows the attacker to gain privileged access to the TCM operating system. This allows an attacker to override the TCM firmware and cause the TCM to run code of the attacker’s choosing. The actual outcomes of such an attack were previously researched in Leveraging Ethernet Card Vulnerabilities in Field Devices. Both of these attacks are issues in the TCM itself. They require no message pass-through ability to the processor modules.

Because of this, both vulnerabilities affect the SIS even when the key is flipped to “Run,” which usually prevents changes to the SIS.

The root vulnerability on the TCM is particularly dangerous. An attacker wishing target a SIS that follows the keyswitch best practice may stage a payload such as TRISIS on the TCM card. From there, the payload may simply monitor the MP modules. Once the keyswitch is moved to the ‘Remote’ or ‘Program’ settings, the TCM malware may activate and load the TRISIS payload into the MP module. Because of the TCM module’s unique position in the SIS architecture, the TCM itself could be used to not only inject malicious logic into the SIS, but also to hide logic and other modifications from both the TriStation software, data historians, HMI systems, and other monitoring systems.

Mitigation Advice

To prevent access to these vulnerabilities, it is crucial to restrict access to the SIS. Only allow the engineering workstation to connect to the Triconex using the documented protocols and block access to all other services that the TCM exposes. The keyswitch will do nothing to prevent the exploitation of these issues, one of which may be used to stage malware on the SIS.

From a monitoring perspective, both TCM vulnerabilities exist in services that are not documented in the Triconex literature. Flagging all unexpected and undocumented communications attempts to the SIS should be a part of an end user’s monitoring strategy.