TID-307: Device Code Representations Inconsistent

Threat Description

Many devices that allow the execution of custom application programs, such as IEC 61131 based programs, also support “program uploads” to extract the running code from the device for various diagnostic functions. To support the program upload function, the device must provide the IDE with machine readable and human-presentable source code, rather than the executable compiled code. Therefore, the device must store two copies of the code, the source code (used to inform program upload function) and the executed compiled code. If a threat actor can modify the source code in memory, it will prevent the program upload function from accurately uploading/reporting the actual code executing on the device and allow any later downloaded malicious code to stay undetected.

Threat Maturity and Evidence

Proof of Concept
The Old Switcheroo: Hiding Code on Rockwell Automation PLCs
Claroty researchers were able to edit the code representation that gets uploaded to the EWS during a program upload without having their malicious machine-code also getting uploaded. This resulted in operators seeing code after the program upload that wasn’t the actual code on the machine, which was the Claroty malicious machine code.

CWE

CWE-829: Inclusion of Functionality from Untrusted Control Sphere
“The product imports, requires, or includes executable functionality (such as a library) from a source that is outside of the intended control sphere.”

CVE

CVE-2022-1161
“An attacker with the ability to modify a user program may change user program code on some ControlLogix, CompactLogix, and GuardLogix Control systems. Studio 5000 Logix Designer writes user-readable program code to a separate location than the executed compiled code allowing an attacker to change one and not the other.”