Last week, a CISA advisory was issued for vulnerabilities present in Rockwell Automation EDS Subsystem versions 28.0.1 and prior, which were discovered by Claroty VP of Research Amir Preminger and Principal Vulnerability Researcher Sharon Brizinov.
Affected Rockwell Automation products include FactoryTalk Linx software versions 6.00, 6.10, and 6.11; RSLinx Classic 4.11.00 and prior; RSNetWorx versions 28.00.00 and prior; and Studio 5000 Logix Designer version 32 and prior. While not known to have been weaponized in the wild, successful exploitation of these vulnerabilities could lead to an arbitrary file write and/or denial-of-service condition.
The discovered vulnerabilities involve a flaw in how the EDS Subsystem parses and stores the content of EDS files. As part of Claroty's ongoing white-hat OT security research, Preminger and Brizinov were able to create a malicious EDS file that writes a Windows batch file onto an arbitrary path (which may include the startup directory) when parsed by Rockwell Automation software. Preminger and Brizinov then presented the malicious EDS file to the EDS Subsystem by emulating an in-network device—an attack strategy sometimes known as a reverse honeypot. Upon restart, the malicious code was executed on the targeted devices.
EDS files are simple text files used by network configuration tools to help identify products and easily commission them on a network. When Rockwell Automation software (e.g. RSLinx) connects to a new type of device, it will read and parse the device's EDS to determine the type of the device and other properties, thus allowing the software to communicate appropriately with the device.
The discovered vulnerabilities can be exploited remotely, but only from within the local network. By connecting their own device or emulating a device via Python to the shop-floor network and successfully impersonating a new, in-network device, an adversary could present a malicious EDS file to discovery software within a targeted network.
In this case, Rockwell Automation's network discovery tools could encounter an attacker's fake device and ask for its malicious EDS file. Upon reading and parsing the EDS file, the vulnerability will be triggered, and a new file will be written to the disk of Rockwell Automation engineering workstations or HMIs. In doing so, the attack would expand their foothold within the victim's network to Rockwell Automation equipment.
The following CVEs were assigned for the vulnerabilities in Rockwell Automation EDS Subsystem recently discovered by Preminger and Brizinov:
Improper restriction of operations within the bounds of a memory buffer (CVE-2020-12038): A memory corruption vulnerability in the algorithm that matches square brackets in the EDS subsystem may allow an attacker to craft specialized EDS files to crash the EDSParser COM object, leading to denial-of-service conditions.
Improper neutralization of special elements in an SQL command — 'SQL Injection' (CVE-2020-12034): Since the EDS subsystem does not provide adequate input sanitization, an attacker may be allowed to craft specialized EDS files to inject SQL queries and manipulate the database storing the EDS files. As a result, the attacker may be able to carry out a denial-of-service attack or manipulate the SQL engine to write or modify files on the system.
These vulnerabilities underscore why it's essential for security teams to be able to monitor OT networks and identify new devices and other potential threats in real time, thus preventing the abuse of automated discovery features that so many vendors offer.
In terms of mitigating these specific vulnerabilities, Rockwell Automation recommends applying the available patch by following the instructions in knowledge base article RAid 1125928 (login required). As a network-based vulnerability mitigation, users are recommended to block all traffic to EtherNet/IP or other CIP protocol-based devices from outside the manufacturing zone by blocking or restricting access to TCP Ports 2222, 7153 and UDP Port 44818 using proper network infrastructure controls, such as firewalls, UTM devices, or other security appliances.
In addition, CISA recommends two other general recommendations:
Locate control system networks and devices behind firewalls, and isolate them from the business network.
When remote access is required, use secure methods, such as VPNs updated to the most current version available. However, keep in mind that a VPN is only as secure as the devices it's connected to.
To learn more about how Claroty can help your team discover and mitigate vulnerabilities within your OT environment, request a demo.
CWE-345 INSUFFICIENT VERIFICATION OF DATA AUTHENTICITY:
In 2N Access Commander versions 3.1.1.2 and prior, a local attacker can escalate their privileges in the system which could allow for arbitrary code execution with root permissions.
Update to Access Commander version 3.2.
CVSS v3: 4.7
CWE-345 INSUFFICIENT VERIFICATION OF DATA AUTHENTICITY:
In 2N Access Commander versions 3.1.1.2 and prior, an Insufficient Verification of Data Authenticity vulnerability could allow an attacker to escalate their privileges and gain root access to the system.
Update to Access Commander version 3.2.
CVSS v3: 6.3
CWE-22 IMPROPER LIMITATION OF A PATHNAME TO A RESTRICTED DIRECTORY ('PATH TRAVERSAL'):
In 2N Access Commander versions 3.1.1.2 and prior, a Path Traversal vulnerability could allow an attacker to write files on the filesystem to achieve arbitrary remote code execution.
Update to Access Commander version 3.2.
CVSS v3: 7.2
CWE-290: AUTHENTICATION BYPASS BY SPOOFING
Snap One OVRC cloud uses the MAC address as an identifier to provide information when requested. An attacker can impersonate other devices by supplying enumerated MAC addresses and receive sensitive information about the device.
Read more: "The Problem with IoT Cloud Connectivity and How it Exposed All OvrC Devices to Hijacking"
CVSS v3: 7.5
CWE-306: MISSING AUTHENTICATION FOR CRITICAL FUNCTION
A vulnerability exists in Snap One OVRC cloud where an attacker can impersonate a Hub device and send requests to claim and unclaimed devices. The attacker only needs to provide the MAC address of the targeted device and can make a request to unclaim it from its original connection and make a request to claim it.
OvrC Pro: All versions prior to 7.3 are affected.
Read more: "The Problem with IoT Cloud Connectivity and How it Exposed All OvrC Devices to Hijacking"
CVSS v3: 9.1