SSH service banner probe reboots Moxa switch (diffie-hellman-group1-sha1)
2 posts
Hello SoftPerfect team,
I'd like to report a protocol bug in the SSH probe used by "Grab service banners" (Options → Additional) in SoftPerfect Network Scanner. It reliably reboots a Moxa EDS-518A-MM-SC industrial switch on our network.
Environment
- Network Scanner version: tried with 26.5 and 26.9
- OS: Windows 11
- Target: Moxa EDS-518A-MM-SC, firmware V2.6 & V3.10, SSH banner "SSH-2.0-moxa_1.0"
Steps to reproduce
- Enable Options → Additional → Grab service banners (SSH included in Select Services).
- Scan a device whose SSH server only supports diffie-hellman-group1-sha1.
What happens (from a Wireshark capture, which I can provide)
- The scanner's KEXINIT offers: diffie-hellman-group-exchange-sha256, diffie-hellman-group14-sha256, diffie-hellman-group14-sha1, diffie-hellman-group1-sha1.
- The device's KEXINIT offers only diffie-hellman-group1-sha1, so group1 (1024-bit Oakley Group 2) is negotiated.
- The scanner then sends SSH_MSG_KEXDH_INIT (type 30) with an mpint e of 256 bytes (2048 bits). For group1, e must be in the range 1 < e < p-1 with a 1024-bit p, i.e. at most 128 bytes (129 with a leading zero). It looks as if e is generated for group14 regardless of the negotiated group.
- The switch stops responding within about 2 ms of receiving this packet. It never ACKs it, stops answering on all ports, and reboots via its watchdog.
The same KEXDH_INIT packet was retransmitted four times, and the behaviour is 100% reproducible. Disabling Grab service banners, or only the SSH service within it, stops the reboots. HTTP, HTTPS and SNMP probes to the same device are handled normally.
Expected behaviour
The KEXDH_INIT value should be generated for the negotiated group (1024-bit for diffie-hellman-group1-sha1), as required by RFC 4253 section 8.
The Moxa firmware should of course reject an out-of-range value rather than crash, and I'm raising that with Moxa separately. However, the malformed packet from the scanner is what triggers it, and it probably affects other legacy embedded devices that only support group1. This matters in OT/industrial networks, where an unexpected reboot of a switch can interrupt production.
I can share the packet capture on request.
It's our bug, and thank you for such a thorough investigation, your analysis is spot on. The SSH probe advertises diffie-hellman-group1-sha1 but always computes the key with the 2048-bit group 14 prime, so a group1-only server receives an out-of-range value. Still, it's quite unexpected that one malformed packet takes the whole switch down with it.
We are working on a new release of Network Scanner with a rewritten SSH probe where this is already resolved. It no longer offers group1 at all, only group 14, 16, 18 and group exchange, so with a group1-only device like this Moxa the negotiation simply ends without any key exchange packet being sent.
Until then, add the switches to Options → Ignored IP Addresses. Network Scanner never scans the addresses listed there, so no probes of any kind reach them. Wildcards are allowed, e.g. 10.0.0.*, if they sit in their own range.