| CVE |
Vendors |
Products |
Updated |
CVSS v3.1 |
|
A vulnerability exists in the Relion update package signature validation. A tampered update package could cause the IED to restart. After restart the device is back to normal operation.
An attacker could exploit the vulnerability by first gaining access to
the system with security privileges and attempt to update the IED
with a malicious update package. Successful exploitation of this
vulnerability will cause the IED to restart, causing a temporary Denial of Service.
|
| Patlite NH-FB v1.46 and below was discovered to contain insufficient firmware validation during the upgrade firmware file upload process. This vulnerability allows authenticated attackers to create and upload their own custom-built firmware and inject malicious code. NOTE: the vendor's position is that this is a design choice, not a vulnerability |
| The recovery module has a vulnerability of bypassing the verification of an update package before use. Successful exploitation of this vulnerability may affect system stability. |
| A vulnerability has been identified in LOGO! 8 BM (incl. SIPLUS variants) (All versions < V8.3). Affected devices load firmware updates without checking the authenticity. Furthermore the integrity of the unencrypted firmware is only verified by a non-cryptographic method. This could allow an attacker to manipulate a firmware update and flash it to the device. |
| HashiCorp Boundary up to 0.10.1 did not properly perform data integrity checks to ensure the resources were associated with the correct scopes, allowing potential privilege escalation for authorized users of another scope. Fixed in Boundary 0.10.2. |
| GnuPG through 2.3.6, in unusual situations where an attacker possesses any secret-key information from a victim's keyring and other constraints (e.g., use of GPGME) are met, allows signature forgery via injection into the status line. |
| A CWE-345: Insufficient Verification of Data Authenticity vulnerability exists that could cause loading of unauthorized firmware images due to improper verification of the firmware signature. Affected Products: X80 advanced RTU Communication Module (BMENOR2200H) (V2.01 and later), OPC UA Modicon Communication Module (BMENUA0100) (V1.10 and prior) |
| A vulnerability has been identified in SINEMA Remote Connect Server (All versions < V3.1). The application does not perform the integrity check of the update packages. Without validation, an admin user might be tricked to install a malicious package, granting root privileges to an attacker. |
| An unauthenticated, remote attacker could upload malicious logic to the devices based on ProConOS/ProConOS eCLR in order to gain full control over the device. |
| An unauthenticated, remote attacker could upload malicious logic to devices based on ProConOS/ProConOS eCLR in order to gain full control over the device. |
| Due to insufficient input validation, SAP Business Objects - version 420, allows an authenticated attacker to submit a malicious request through an allowed operation. On successful exploitation, an attacker can view or modify information causing a limited impact on confidentiality and integrity of the application. |
| The Omron SYSMAC Cx product family PLCs (CS series, CJ series, and CP series) through 2022-05-18 lack cryptographic authentication. They utilize the Omron FINS (9600/TCP) protocol for engineering purposes, including downloading projects and control logic to the PLC. This protocol has authentication flaws as reported in FSCT-2022-0057. Control logic is downloaded to PLC volatile memory using the FINS Program Area Read and Program Area Write commands or to non-volatile memory using other commands from where it can be loaded into volatile memory for execution. The logic that is loaded into and executed from the user program area exists in compiled object code form. Upon execution, these object codes are first passed to a dedicated ASIC that determines whether the object code is to be executed by the ASIC or the microprocessor. In the former case, the object code is interpreted by the ASIC whereas in the latter case the object code is passed to the microprocessor for object code interpretation by a ROM interpreter. In the abnormal case where the object code cannot be handled by either, an abnormal condition is triggered and the PLC is halted. The logic that is downloaded to the PLC does not seem to be cryptographically authenticated, thus allowing an attacker to manipulate transmitted object code to the PLC and either execute arbitrary object code commands on the ASIC or on the microprocessor interpreter. |
| The Omron SYSMAC Nx product family PLCs (NJ series, NY series, NX series, and PMAC series) through 2022-005-18 lack cryptographic authentication. These PLCs are programmed using the SYMAC Studio engineering software (which compiles IEC 61131-3 conformant POU code to native machine code for execution by the PLC's runtime). The resulting machine code is executed by a runtime, typically controlled by a real-time operating system. The logic that is downloaded to the PLC does not seem to be cryptographically authenticated, allowing an attacker to manipulate transmitted object code to the PLC and execute arbitrary machine code on the processor of the PLC's CPU module in the context of the runtime. In the case of at least the NJ series, an RTOS and hardware combination is used that would potentially allow for memory protection and privilege separation and thus limit the impact of code execution. However, it was not confirmed whether these sufficiently segment the runtime from the rest of the RTOS. |
| Honeywell Experion PKS Safety Manager (SM and FSC) through 2022-05-06 has Insufficient Verification of Data Authenticity. According to FSCT-2022-0053, there is a Honeywell Experion PKS Safety Manager insufficient logic security controls issue. The affected components are characterized as: Honeywell FSC runtime (FSC-CPU, QPP), Honeywell Safety Builder. The potential impact is: Remote Code Execution, Denial of Service. The Honeywell Experion PKS Safety Manager family of safety controllers utilize the unauthenticated Safety Builder protocol (FSCT-2022-0051) for engineering purposes, including downloading projects and control logic to the controller. Control logic is downloaded to the controller on a block-by-block basis. The logic that is downloaded consists of FLD code compiled to native machine code for the CPU module (which applies to both the Safety Manager and FSC families). Since this logic does not seem to be cryptographically authenticated, it allows an attacker capable of triggering a logic download to execute arbitrary machine code on the controller's CPU module in the context of the runtime. While the researchers could not verify this in detail, the researchers believe that the microprocessor underpinning the FSC and Safety Manager CPU modules is incapable of offering memory protection or privilege separation capabilities which would give an attacker full control of the CPU module. There is no authentication on control logic downloaded to the controller. Memory protection and privilege separation capabilities for the runtime are possibly lacking. The researchers confirmed the issues in question on Safety Manager R145.1 and R152.2 but suspect the issue affects all FSC and SM controllers and associated Safety Builder versions regardless of software or firmware revision. An attacker who can communicate with a Safety Manager controller via the Safety Builder protocol can execute arbitrary code without restrictions on the CPU module, allowing for covert manipulation of control operations and implanting capabilities similar to the TRITON malware (MITRE ATT&CK software ID S1009). A mitigating factor with regards to some, but not all, of the above functionality is that these require the Safety Manager physical keyswitch to be in the right position. |
| The Motorola MDLC protocol through 2022-05-02 mishandles message integrity. It supports three security modes: Plain, Legacy Encryption, and New Encryption. In Legacy Encryption mode, traffic is encrypted via the Tiny Encryption Algorithm (TEA) block-cipher in ECB mode. This mode of operation does not offer message integrity and offers reduced confidentiality above the block level, as demonstrated by an ECB Penguin attack against any block ciphers. |
| The Motorola ACE1000 RTU through 2022-05-02 mishandles firmware integrity. It utilizes either the STS software suite or ACE1000 Easy Configurator for performing firmware updates. In case of the Easy Configurator, firmware updates are performed through access to the Web UI where file system, kernel, package, bundle, or application images can be installed. Firmware updates for the Front End Processor (FEP) module are performed via access to the SSH interface (22/TCP), where a .hex file image is transferred and a bootloader script invoked. File system, kernel, package, and bundle updates are supplied as RPM (RPM Package Manager) files while FEP updates are supplied as S-rec files. In all cases, firmware images were found to have no authentication (in the form of firmware signing) and only relied on insecure checksums for regular integrity checks. |
| Motorola ACE1000 RTUs through 2022-05-02 mishandle application integrity. They allow for custom application installation via either STS software, the C toolkit, or the ACE1000 Easy Configurator. In the case of the Easy Configurator, application images (as PLX/DAT/APP/CRC files) are uploaded via the Web UI. In case of the C toolkit, they are transferred and installed using SFTP/SSH. In each case, application images were found to have no authentication (in the form of firmware signing) and only relied on insecure checksums for regular integrity checks. |
| The Emerson ROC and FloBoss RTU product lines through 2022-05-02 perform insecure filesystem operations. They utilize the ROC protocol (4000/TCP, 5000/TCP) for communications between a master terminal and RTUs. Opcode 203 of this protocol allows a master terminal to transfer files to and from the flash filesystem and carrying out arbitrary file and directory read, write, and delete operations. |
| The Emerson ControlWave 'Next Generation' RTUs through 2022-05-02 mishandle firmware integrity. They utilize the BSAP-IP protocol to transmit firmware updates. Firmware updates are supplied as CAB archive files containing a binary firmware image. In all cases, firmware images were found to have no authentication (in the form of firmware signing) and only relied on insecure checksums for regular integrity checks. |
| Emerson DeltaV Distributed Control System (DCS) has insufficient verification of firmware integrity (an inadequate checksum approach, and no signature). This affects versions before 14.3 of DeltaV M-series, DeltaV S-series, DeltaV P-series, DeltaV SIS, and DeltaV CIOC/EIOC/WIOC IO cards. |
