Submit #990050: Netis Systems (Netcore Group) EAP930 (AX3000 Wireless Gigabit Ceiling Mount Access Point) V0.1.250905.115454 (CWE-912, CWE-798-adjacentm CWE-256/522)

Description:

There's a CGI endpoint at /cgi-bin/debug that isn't linked from anywhere in
the admin UI. No cookie or ubus session check - none of the auth logic
every other admin-facing script on the device uses. Instead it's gated by
a signature:

DeviceRole=$(uci get wificfg.2G.DeviceRole)
if [ "$DeviceRole" = "1" ]; then
exit
fi

SIGNATURE=$(mktemp)
cat | head -c 4096 > "$SIGNATURE"

MSG_FILE=$(mktemp)
ifconfig br-lan | grep HWaddr | awk '{print $5}' | head -c 17 | tr "A-Z" "a-z" > "$MSG_FILE"

PUBLICKEY=$(mktemp)
write_public_key > "$PUBLICKEY"

usign -V -p "$PUBLICKEY" -m "$MSG_FILE" -x "$SIGNATURE"
errcode=200

The message being signed is the device's own LAN MAC, lowercased. The
public key is hardcoded (comment: "untrusted comment: public key
a27b557e0eaaa926") and separate from the key already on the device for
opkg verification - this one exists just for this endpoint. POST a
signature over the LAN MAC, signed with the matching private key, and the
response (via an EXIT trap once errcode is 200) is:

return200()
{
cat <<- EOF
Status: 200 OK
Content-type: text/html

$(uci get system.@system[0].admin)
$(uci get system.@system[0].passwd)
EOF
}

Admin username and password, plain text, out of UCI. Which means the
password sits in UCI in recoverable form to begin with - not hashed.

DeviceRole is the only thing that could block this, so I checked what it's
actually set to rather than assume. etc/uci-defaults/60-wificfg defaults it
to '0'. Went through the OEM customization layer too
(etc/customer.sh, etc/config/customer, both in this firmware's overlay
squashfs, applied on first boot) - nothing there touches
wificfg.*.DeviceRole. Not blocked on a standard unit.

Also checked whether the default admin password itself is derivable from
public info, since the provisioning script pulls it from `impd
system_key`, and impd's other subcommands (24g_key, 5g_key) are MAC-derived
Wi-Fi passwords. Disassembled impd - a stripped ARM64 binary with no
section headers at all, so the usual section-table approach doesn't work;
had to pull symbols and relocations straight out of PT_DYNAMIC. The
function handling system_key isn't a hash or derivation - it's a loop
checking a buffer for a 0xFF byte, the standard check for whether flash
still holds its erased pattern. So the password looks like a genuine
per-device factory secret in NVRAM, not computable from the MAC.

Proof of Concept:

Same firmware as the previous report. Generated an Ed25519 test keypair
with the real usign binary from this firmware (not Netis's key - I don't
have that), substituted the test public key into a copy of the script in
place of the embedded one, and ran it - real busybox ash, real usign, real
uci reading a test config - under qemu-user with binfmt_misc registered so
the chained usign/uci calls actually execute.

Garbage signature:

Status: 403 Forbidden
Content-type: text/html

<h1>403 Forbidden</h1>

Valid signature (test key, fake MAC, script's embedded key swapped for the
test public key, UCI test config carrying admin/TestPlaintextPassword123):

Status: 200 OK
Content-type: text/html

admin
TestPlaintextPassword123

Both match what the set -e / trap EXIT / errcode control flow predicts, run
against the actual shipped script logic.

Impact:

Not exploitable by an arbitrary attacker today - requires the private half
of the key behind a27b557e0eaaa926, which as far as I can tell only Netis
holds. Regardless of who currently has it, this is undocumented backdoor
functionality in production firmware, gated by one static key, disclosing
plaintext admin credentials with no audit trail and no session requirement.
Signing-key leaks at router vendors aren't hypothetical. If this key ever
leaks, every device carrying this public key becomes a one-request
credential dump given nothing but its LAN MAC.

Vendor contact:

Same note as the previous submission - sent to [email protected] on
2026-09-08, no security contact found published anywhere, no reply as of
this submission.

• Benutzer: arpe1618 (UID 101090)
• Einreichung: 18.09.2026 07:52 (vor 1 Monat)
• Moderieren: 19.10.2026 16:52 (1 month later)
• Status: Akzeptiert
• VulDB Eintrag: 422394 [Netis EAP930 1.250905.115454 CGI Endpoint /cgi-bin/debug return200 SIGNATURE erweiterte Rechte]
• Punkte: 17