Industrial networks rely on robust and trustworthy equipment to keep automation and operations running safely. However, sometimes vulnerabilities in network devices themselves can undermine even the best firewall and segmentation practices. CVE-2024-0387 reveals a critical issue in the Moxa EDS-400/G400 Series Industrial Ethernet Switches: a built-in IP forwarding feature, active by default and impossible for users to disable, which can create an unexpected and dangerous backdoor for attackers.
In this long read, we’ll break down how this flaw works, what the risks are, and how an attacker can use it. We’ll also provide example code, suggested mitigations, and direct you to official resources for further reading.
Vulnerability Overview
Affected devices:
Moxa EDS-400/G400 Series Ethernet Switches, firmware versions prior to 3.2
Vulnerability:
The devices have an IP forwarding feature that cannot be deactivated. This allows network requests sent to the device to be forwarded to other hosts. This built-in “router” feature can be abused by attackers, who might send malicious requests to the switch and have them forwarded deeper into the internal network.
Common Vulnerabilities and Exposures (CVE):
CVE-2024-0387 – "The EDS-400/G400 Series prior to version 3.2 includes IP forwarding capabilities that users cannot deactivate. An attacker may be able to send requests to the product and have it forwarded to the target. An attacker can bypass access controls or hide the source of malicious requests."
Attack Scenario: How Does It Work?
Normally, switches operate at Layer 2 of the OSI model (the data link layer), forwarding Ethernet frames based on MAC addresses. However, these Moxa devices include a built-in Layer 3 forwarding capability — they can forward IP packets between subnets.
Forwarding is Always Enabled: Users can't disable IP forwarding due to firmware limitations.
- Attackers Can Bypass Firewalls: A network that trusts Moxa switches might have rules blocking external access to some devices, but attackers can send packets to the switch, which forwards them on.
- Source Obfuscation: Malicious requests will appear as if they're coming from the EDS switch rather than the real attacker — defeating IP-based access controls.
Let’s imagine a typical industrial setup
- Network A: 192.168.10./24 (production/secure network)
- Network B: 10.../24 (less secure network, maybe engineering laptops, etc.)
The Moxa device has an interface in both subnets and its firmware version is below 3.2.
Suppose Host X on Network B can’t directly reach servers in Network A, because firewall rules or router ACLs block such access. But Host X can talk to the Moxa switch. The switch, due to CVE-2024-0387, will forward packets between the networks.
Diagram
[Attacker PC]--(10...x)---+
| [EDS-400/G400 Switch]
----+---(192.168.10.x)----
|
[Protected PLC] (192.168.10.100)
Exploit Example: Port Scanning via IP Forwarding
Goal: Attacker wants to scan or access services on 192.168.10.100 from 10...x.
How is this possible?
If the switch is forwarding packets between its interfaces, all the attacker has to do is set their own default gateway to the Moxa device’s IP on their network (e.g., 10...1).
Let's say
- On 10.../24: 10...1
- On 192.168.10./24: 192.168.10.1
Configure attacker's route
On the attacker’s machine (10...x), set the Moxa's IP as the default gateway or add a static route for the target network.
Example on Linux. Replacewith your network adapter
sudo ip route add 192.168.10./24 via 10...1 dev
`
The traffic will traverse the Moxa switch, which will (because of the bug) forward it to the 192.168.10.x network.
Bypassing Access Controls
If the firewall or access controls only trust packets from the Moxa switch’s IP (192.168.10.1), attackers can spoof the source or simply communicate via the switch, making it look “trusted.”
Simple Exploit Script
Here’s a Python example using scapy to send crafted packets through the Moxa switch. This would let you see if the target's HTTP port is reachable.
from scapy.all import IP, TCP, sr1
# EDS-400 IP in attacker's network
MOXA_IP = "10...1"
# Target device in protected network
TARGET_IP = "192.168.10.100"
# Create IP packet destined to the target, routed via the switch
packet = IP(dst=TARGET_IP) / TCP(dport=80, flags="S")
# Send, spoofing route via Moxa
resp = sr1(packet, timeout=2)
if resp:
print("Port 80 open on", TARGET_IP)
else:
print("Port 80 closed or filtered")
# Make sure Moxa is your gateway, or add route as above
Impact
- Network Segmentation Broken: If your security assumes Moxa switches won’t forward IP between subnets, this bug breaks your design.
- Access Controls Bypassed: Hosts trusting connections from the switch, or with IP allowlists, can be fooled.
Attack Stealth: Logs may show the Moxa switch as the source, not the real attacker.
- OT/ICS Risk: Industrial control systems relying on these devices may be at risk for remote exploitation.
Mitigation & Workarounds
- Upgrade Firmware: Only version 3.2 or greater fixes this. Get latest firmware here.
- Restrict Management Access: Put management interfaces on isolated VLANs; avoid multi-homed switches where possible.
- Network ACLs: Apply network ACLs upstream of the Moxa switch that block unintended inter-VLAN/IP communication.
- Monitor for Unexpected Flows: Use NetFlow/sflow monitoring to alert on traffic traversing the switch in suspicious ways.
References & Further Reading
- ⚡ Moxa Security Advisory – EDS-400/G400 Series
- ⚡ NVD – CVE-2024-0387
- ⚡ Industrial Control System CERT Alert ICSMA-24-038-01
Conclusion
CVE-2024-0387 is a critical and easily overlooked weakness in the Moxa EDS-400/G400 switch series. Because the vulnerability is a *default*, built-in part of the firmware, and can’t be disabled pre-3.2, any network segments connected by affected devices should be assumed to be routable — even if that breaks your design or expectations.
Monitor for unknown or suspicious routed flows.
Network security starts from the ground up — don’t let a simple feature like “IP forwarding” undo all your hard work.
*Written exclusive for your security learning. Stay safe!*
Timeline
Published on: 02/26/2024 16:27:49 UTC
Last modified on: 02/26/2024 16:32:25 UTC