Real-time collaboration for Jupyter Notebooks, Linux Terminals, LaTeX, VS Code, R IDE, and more,
all in one place.
Real-time collaboration for Jupyter Notebooks, Linux Terminals, LaTeX, VS Code, R IDE, and more,
all in one place.
Path: blob/master/documentation/modules/auxiliary/scanner/scada/moxa_discover.md
Views: 11789
Vulnerable Application
The Moxa protocol listens on 4800/UDP and will respond to broadcast or direct traffic. The service is known to be used on Moxa devices in the NPort, OnCell, and MGate product lines.
A discovery packet compels a Moxa device to respond to the sender with some basic device information that is needed for more advanced functions. The discovery data is 8 bytes in length and is the most basic example of the Moxa protocol. It may be sent out as a broadcast (destination 255.255.255.255) or to an individual device.
Devices that respond to this query may be vulnerable to serious information disclosure vulnerabilities, such as CVE-2016-9361.
The module is the work of Patrick DeSantis of Cisco Talos and is derived from original work by K. Reid Wightman. Tested and validated on a Moxa NPort 6250 with firmware versions 1.13 and 1.15.
The discovery request contains the bytes:
\x01\x00\x00\x08\x00\x00\x00\x00
Where the function code (first byte) 0x01 is Moxa discovery/identify and the fourth byte is the length of the full data payload.
The first byte of a response will always be the func code + 0x80 (the most significant bit of the byte is set to 1, so 0b00000001 becomes 0b10000001, or 0x81).
A valid response is 24 bytes, starts with 0x81, and contains the values 0x00, 0x90, 0xe8 (the Moxa OIU) in bytes 14, 15, and 16.
Verification Steps
Start msfconsole
Do:
use auxiliary/scanner/scada/moxa_discover
Do:
set RHOSTS
Do:
run
Devices running the Moxa service should respond
Options
RHOSTS
Target(s) to scan; can be single target, a range, or broadcast.