Executive Summary

Industrial networking company Moxa has alerted customers to a critical vulnerability in the firmware of two of its industrial Ethernet switch product lines. The flaw, tracked as CVE-2023-38408, exists in the OpenSSH component and could allow an unauthenticated, remote attacker to achieve remote code execution (RCE). The affected products, the EDS-G4000 and RKS-G4000 series switches, are specifically designed for harsh environments and are widely deployed in industrial control systems (ICS) and critical infrastructure sectors like energy, transportation, and manufacturing. A successful exploit could lead to a complete compromise of the network device, enabling an attacker to disrupt industrial processes or pivot deeper into the operational technology (OT) network. The Canadian Centre for Cyber Security has also issued an alert, amplifying the urgency for administrators to apply the available patches.

Vulnerability Details

• CVE ID: CVE-2023-38408
• Severity: Critical (CVSS score is not specified in the articles but the flaw type in OpenSSH often scores 9.8)
• Component: OpenSSH service in device firmware.
• Impact: Remote Code Execution (RCE).
• Description: The vulnerability allows a remote attacker to execute arbitrary code by targeting the SSH service on the device. CVE-2023-38408 specifically refers to a flaw where a malicious SSH client or server could trick the other into loading code from pkcs11.so and executing it, if certain libraries are forwarded. This could lead to a full takeover of the switch.

Affected Systems

The vulnerability affects the following Moxa industrial switch series:

• Moxa EDS-G4000 Series: Firmware versions v4.1 and prior.
• Moxa RKS-G4000 Series: Firmware versions v5.0 and prior.

These devices are ruggedized switches intended for deployment in factory floors, power substations, railway systems, and other critical infrastructure environments.

Impact Assessment

• ICS/OT Network Compromise: A compromised network switch is a critical failure in any network, but in an ICS environment, the impact is magnified. An attacker can manipulate, block, or redirect network traffic, disrupting physical industrial processes.
• Loss of View and Loss of Control: Attackers could isolate the switch from the management network, preventing operators from monitoring or controlling the industrial process (Loss of View). They could also send malicious commands to PLCs or other controllers connected to the switch (Loss of Control).
• Pivot Point into OT Environment: The compromised switch provides an ideal foothold for an attacker to launch further attacks against other sensitive devices on the OT network segment.
• System Sabotage: An attacker with RCE on the switch could wipe its configuration, rendering it inoperable and causing a network outage that halts industrial operations.

Cyber Observables for Detection

Detection Methods

• Asset and Firmware Inventory: The first step is to identify all Moxa EDS-G4000 and RKS-G4000 series switches in the environment and check their firmware versions against the advisory. This is critical for OT asset management.
• Network Access Monitoring: Monitor all SSH (port 22) access attempts to the switches. Alert on any connections originating from outside the designated management network or from unauthorized administrator workstations. This is a form of D3FEND Inbound Traffic Filtering (D3-ITF).
• Configuration Change Detection: Use network configuration management tools to detect any unauthorized changes to the switch's running configuration, which could be a sign of compromise.

Remediation Steps

1. Apply Firmware Updates: Moxa has released patched firmware versions for the affected products. Administrators must download and apply these updates as the primary means of remediation. This is a direct application of D3FEND Software Update (D3-SU).
2. Network Segmentation and Hardening: As a critical best practice in all ICS environments, ensure that the management interfaces of switches and other control system devices are on a separate, isolated network. Access to this management network should be strictly controlled via firewalls and jump boxes.
3. Disable SSH if Unused: If SSH is not required for the management of the switch, it should be disabled to completely remove this attack vector.
4. Use Access Control Lists (ACLs): If SSH must be enabled, configure ACLs on the switch itself or on an upstream firewall to restrict SSH access to only a small list of authorized IP addresses.