Edimax BR-6478AC firmware v2.20 – authenticated command injection
Title: Edimax BR-6478AC firmware v2.20 - authenticated command injection Author: 0day Rubbish Research Team Contact: disclosure@0day-rubbish.com Type: remote Platform: Hardware CVE: pending Description: Edimax BR-6478AC firmware image BR6478AC_v2.20.bin, the closed-source dual-band AC1750 SOHO wireless router from Edimax Technology Co., Ltd. (Taiwan), whose SquashFS root filesystem of roughly 2.3 MB targets MIPS 32-bit big-endian MIPS-I with a uClibc C library and carries an internal build timestamp from 2015, contains an OS command injection (CWE-78) in the WAN-configuration form handler of bin/webs, the embedded GoAhead-style HTTP server serving the management interface on TCP port 80. That binary is ELF 32-bit MSB MIPS, 762904 bytes, SHA256 ec39c0f9332361e37ab92f1999ac5f00f5742dd6db75f7cb26c0652cfedb32a1, reads etc/boa/boa.conf, writes /var/run/webs.pid and is kept alive by the boot path cleanlog.sh:131 invoked from init.sh:1115. The registration websFormDefine("setWAN", ...) at 0x478484, handler at 0x441cec, name string at 0x4a6250, publishes POST /goform/setWAN. Inside the handler the WAN mode is taken from the request and dispatched: websGetVar(wp, "wanMode", "") at 0x441d3c, atoi at 0x441d44, apmib_set(0x102, &wanMode) at 0x441d54, then addiu v1, zero, 2 at 0x441d60 and beq v0, v1, 0x441e74 at 0x441d6c. On the PPP branch, wanMode 2, the username field is read by websGetVar for pppUserName, name string at 0x4953f4, copied with strcpy at 0x441e94 into a fixed stack buffer, measured with strlen at 0x441ea8 and then scanned by an inline byte loop between 0x441ebc and 0x441ee4 whose only comparison is addiu a0, zero, 0x3b, a semicolon; finding one, the loop writes a NUL and stops. That single-character scan is the entire sanitisation on the path. The value is then formatted by sprintf at 0x441ee8 with the format string at 0x49a510, echo %s > /tmp/UserName, and passed to system(buf2) at 0x441f1c through the PLT slot at 0x4c6d60, which hands the line to /bin/sh -c. A pipe, an ampersand, a backtick, a dollar sign with parentheses and an embedded newline are never inspected, so a username containing no semicolon reaches the shell untouched: the payload |id > /tmp/marker # builds the command line "echo |id > /tmp/marker # > /tmp/UserName", in which the shell treats the hash as a comment swallowing the sink's own redirect and runs id as the right-hand side of a pipeline. An escape loop replacing a hash with a backslash-escaped hash does exist between 0x441f4c and 0x441fb0, but the instruction order places it after system() at 0x441f1c with no branch back to it, and it writes the configuration buffer at sp+0x18 that apmib_set(0x6d, ...) stores at 0x44200c rather than the buffer handed to the shell, so the hash character is escaped for storage and for nowhere near execution. Between websGetVar and system there is no regex call, no inet_aton, no isdigit, no isalnum, no strchr, no strcspn, no vendor validation helper and no custom validator; the inet_aton calls that do exist in the function, at 0x441dd0 and 0x441e14, belong to the static-IP branch, wanMode 1, reached via the branch at 0x441d8c, which the wanMode 2 comparison never enters, so a quick read of the decompilation misleads a reviewer into thinking this function validates addresses. The same construction appears three times in this handler and one root cause yields three reachable parameters: pppUserName on wanMode 2 with sink region 0x441e74 to 0x441f1c and configuration object 0x6d written after the sink, pptpUserName on wanMode 3 from 0x4420d0 onward with configuration object 0xf3, and L2TPUserName on wanMode 6 from 0x44246c onward with configuration object 0x128, each selected by a value the request supplies and each using the same immediate-0x3b scan, the same echo format string and the same system() call shape, so a patch confined to the PPP path leaves the PPTP and L2TP paths injectable. Reaching the handler requires a valid administrative session: the gate auth_authorize at 0x404d00 reads configuration object 0x1bc, the setup-wizard flag, through apmib_get, and once past setup the security store at 0x4c7004, a single / entry of type Basic registered from the directive Auth / /etc/boa/boa.passwd, covers every /goform/ path with HTTP Basic authentication. The product has no second lower-privileged role, so Privileges Required is High: one realm entry, one password file, one account, an Allow directive handler at 0x407688 that is a stub answering "This version of Boa doesn't support access controls", a type-None string at 0x49070c never passed to auth_add, and a shipped configuration carrying one Auth directive and no Allow directive. The route is not one of the four carrying a post-boot uptime gate, /mp.asp, /goform/mp, /advanced_management.asp and /goform/formAdvManagement, which redirect to /index.asp once /proc/uptime exceeds 600 seconds, so it is reachable at any time the device is up. The calling process is root because etc/boa/boa.conf declares User root, the server performs no setuid, chroot, namespace or capability drop and writes /var/run/webs.pid, which requires root on this filesystem, so the landing identity is uid=0(root) with no escalation step in the chain. This handler is one instance of a broad construction: a count of the shipped registration table found 91 /goform/form* handlers of which roughly 85 reach a system() or popen() call. Two adjacent observations are reported without a score: the strcpy at 0x441e94 copies attacker-controlled bytes with no length argument into a fixed stack buffer, for which no overflow was developed and no exploitability claim is made, and because the semicolon scan writes a NUL at the first semicolon a legitimate username containing one is silently truncated before storage, a correctness defect independent of the injection. The firmware image ships a populated /etc/boa/boa.passwd for the single realm and the model's published factory login is admin:1234; that is reported separately as CWE-798, carries no score, is never described as the vector for this injection, and no cryptographic match against the shipped MD5-crypt digest is claimed because the digest string captured during analysis was recorded incompletely. One detail is left unresolved rather than smoothed over: the single account entry in the image is recorded under the name root while the model's published management login is admin, and because no device was ever authenticated against, which user name the realm accepts was not established. Absence of privilege separation is likewise reported separately as CWE-250. A static comparison against a second firmware image, BR-6208AC_V2_1.03, whose webs is a different build, ELF 32-bit MSB MIPS-I, 816568 bytes, SHA256 3ad10a41d11c8cd59185eab6c9ce67b18cd2118942eb2201f48540d7846a0328, found a setWAN implementation matching instruction for instruction, handler at 0x448710, websGetVar for pppUserName at 0x4488b8, strcpy at 0x4488bc, the same inline immediate-0x3b scan at 0x4488dc to 0x4488fc, the same sprintf at 0x448920 with format string 0x4a6954, system() at 0x448940, the same three parameters on the same three wanMode values and the same single-realm Basic authentication behind the same configuration flag, which points to a shared source component in the vendor's router software base; that model was not tested, nothing was executed from that image, no score covers it and it is not an exploited finding on it. A second independent command injection on the same image, in the formWlanMP manufacturing-test handler reaching sprintf at 0x462fd0 and system() at 0x46308c through POST /goform/formWlanMP with no sanitisation across thirty radio-calibration fields, is published as a companion advisory; it is a different handler, format string, sink address and sanitiser, so one patch point does not close both. No prior public record was found whose root cause is command injection in this setWAN handler. CVSS: 7.2 High (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H) is the single score published for this finding, from ISS = 1 - 0.44^3 = 0.914816, Impact at S:U = 6.42 x 0.914816 = 5.873119, Exploitability = 8.22 x 0.85 x 0.77 x 0.27 x 0.85 = 1.234708 and Base = Roundup(5.873119 + 1.234708) = Roundup(7.107826) = 7.2. The provenance of that figure is disclosed because it is a correction: the research notes carried 8.8 next to a PR:H vector, and 8.8 is the arithmetic of PR:L, so the score was recomputed from the vector and published at 7.2, lowering the researchers' own number by 1.6 points. Four further readings are printed with their arithmetic in the public analysis. Privileges Required Low is rejected at 8.8 High, Exploitability 2.835255 and Base Roundup(8.708373), because the product has no basic-user role. Scope Changed is rejected at 9.1 High, Impact at S:C 6.128026, Exploitability 2.286496 and Base Roundup(1.08 x 8.414522), because webs is root before the attack and root after it. Attack Complexity High is rejected at 6.6 High, Exploitability 0.705547 and Base Roundup(6.578666), because success depends on no condition outside the attacker's control, the only branch to satisfy, wanMode, being attacker-supplied. An adjacent-vector reading is published as a labelled alternative at 6.8 High, Exploitability 0.900610 and Base Roundup(6.773729), and is the honest description of a stock device whose WAN-side input policy drops new connections, the shipped firewall script dropping WAN-originated SYN at firewall.sh:180, installing a default DROP input policy at firewall.sh:187 and accepting input on other interfaces at firewall.sh:189; AV:N is retained because the service is bound to the device's own network stack and addressable over IP by every host on the segment the router serves, including guest wireless clients and anything bridged or compromised behind it, and because remote management on the WAN side or forwarding port 80 are ordinary documented features. Default internet exposure is not claimed. Two readings at 9.8 Critical, CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H from Exploitability 3.887043 and Base Roundup(9.760161), are published only as explicitly labelled conditionals and never as the headline: the first applies where a deployment still accepts the factory credential and is reasoned rather than demonstrated, since no device was authenticated against; the second applies to a device still in its pre-configuration setup state, where auth_authorize returns success without a challenge for paths outside /mp.asp, /index.asp and / at 0x4052d0 while /generate_204 answers 204, and that branch is structural inference only, read from the binary and never exercised, with three shipped artefacts identifying the state as the setup wizard rather than normal operation, namely formwizResetDefault at 0x44cdbc displaying Resettowizard, formWizSetup printing NO - LOGIN-WEB when the flag is 1, and pages such as web/inter_wan.asp:214 and web/admin_timezone.asp:95 reading the same flag. That conditional's Scope Changed variant computes to 10.0 and is deliberately not published, and if the setup window has to be contested rather than found open the reading is 8.1 High from Exploitability 2.221167 and Base 8.094286. No version range is claimed: only firmware BR6478AC_v2.20.bin was examined, and only the wanMode 2 path was replicated, so no claim is made for other BR6478AC builds, for the separately marketed BR-6478AC V2 hardware revision whose firmware line is a different little-endian MIPS-II build of webs, for the pptpUserName and L2TPUserName instances beyond the structural reading of the same handler, or for any other model. Impact: arbitrary operating-system command execution as root on the router from a single authenticated POST indistinguishable from a legitimate WAN settings submission, since the payload travels in the PPP username field of the form the product's own wan.asp page posts. Root on this device exposes every stored secret, including precisely the PPP, PPTP and L2TP credentials this handler writes into configuration objects 0x6d, 0xf3 and 0x128, so an attacker who reaches the device can read the ISP or VPN account details the owner entered, together with the administrator password file, wireless pre-shared keys and per-station key material, VPN parameters and any certificate or key on the filesystem. It grants control of the configuration and routing plane: firewall and NAT rules, the DNS resolver handed out to clients, DHCP leases and a malicious default gateway, port forwards, wireless SSIDs and the WAN uplink itself, including rewriting the WAN mode, which is exactly the configuration path this handler owns. It grants firmware-level persistence, since root can write the flash-backed configuration area and install a boot-time startup mechanism, so a compromise survives reboots and can survive a partial configuration reset, with recovery requiring a full reflash of a known-good image. It grants availability at will over wireless, routing, DHCP, DNS and the management service. There is no rate limit on the handler and no lockout in the Basic realm, so the route is repeatable and leaves no alert behind. Detection is poor by construction but this sink leaves one usable anomaly: a submitted WAN configuration produces ordinary behaviour and the sink's visible effect, a username written into /tmp/UserName and then into the configuration store, is what a legitimate submission does, so the indicator is the absence of the expected /tmp/UserName destination on a submission that should have created it. An injection also corrupts stored configuration in a way the owner may not notice, the semicolon scan truncating at the first semicolon and a pipe-and-hash payload storing a username the WAN link cannot authenticate with, a self-inflicted availability event that doubles as a fingerprint. One operational caution: the injection is not side-effect free. A successful submission overwrites the stored WAN username and can break the uplink, which is what the handler does on any successful submission, so any demonstration must record and restore the device's original WAN configuration. Verification boundary: no physical device was powered on and no end-to-end HTTP request was ever accepted by the product. The HTTP leg, being request parsing, the authentication gate, form registration, mode dispatch and PPP branch selection, is evidenced at instruction level from the shipped binary, its configuration and its boot scripts. The execution leg is evidenced dynamically by replication of the sink's semantics rather than by detonation, because a MIPS big-endian uClibc userspace with a board-specific bootloader could not be booted end to end in the research environment: the extracted binaries faulted with SIGBUS under the available user-mode translator and full-system emulation of the board was not brought up. The question under test is not the device but whether a shell evaluates a pipeline and honours a trailing comment in a string built by the vendor's own sprintf and handed to /bin/sh -c, which is a question about POSIX shell semantics that are architecture independent, combined with the exact format string read out of the binary. The string sprintf produces at 0x441ee8 was reconstructed byte for byte for a request whose pppUserName field is |id > /tmp/marker_sw # and handed to /bin/sh -c in an isolated POSIX sandbox whose invoking shell ran as root, producing a 39-byte marker file owned by root:root containing uid=0(root) gid=0(root) groups=0(root) with shell exit status 0, while the sink's own /tmp/UserName destination was not created, that absence being the proof that the trailing hash reached the shell as a comment rather than being escaped, since a protected sink would have left the file behind. A benign control submitting an ordinary username created its destination containing that username and produced no marker. The same replication was repeated on a workstation under an ordinary unprivileged user account and reproduced the semantics at that identity, ruling out the alternative explanation that running as root caused the marker to appear. The harness removes any pre-existing marker and destination before each run and deletes its scratch files afterwards. Consequently the on-device landing identity of uid=0(root) is inferred from the shipped User root directive plus the root-identity replication and is not an observation from hardware; AV:N is argued from the product's transport and authentication model rather than measured across a network; the pptpUserName and L2TPUserName instances are a structural reading of the same handler rather than a demonstrated result; the sibling-model comparison is static only with nothing executed from that image and no score covering it; no setup-state request was sent; no dictionary or credential attack was attempted; and no overflow was developed against the unbounded stack copy. Proof-of-concept and full analysis, published unconditionally: https://0day-rubbish.com/blog/edimax-br-6478ac-setwan-command-injection-root-rce Companion advisory, same product and image, different handler: https://0day-rubbish.com/blog/edimax-br-6478ac-formwlanmp-command-injection-root-rce PoC location in the public repository: product/edimax/br-6478ac-v2.20/setwan-command-injection-root-rce/exploit/edimax_br6478ac_setwan_command_injection_root_rce.py Repository: https://github.com/Exploit-Garbage/0day-Rubbish The shipped proof of concept is Python 3 using only the standard library, with no third-party dependency and no hardcoded target, and it is built so that it cannot be used accidentally against a live network. Its default mode is replication: it reconstructs the exact string the device's sprintf produces at 0x441ee8 and hands it to /bin/sh -c locally, asserting both that the injected pipeline ran and that the sink's own redirect target was not created, which is what proves the trailing hash reached the shell as a comment, then running a benign username as a negative control and asserting the opposite. That replication mode, not a device run, produced the evidence above. Arguments cover target host, Basic realm username and password, the WAN mode to select, which of the three username fields carries the payload, an option to iterate all three modes, a single non-destructive command defaulting to id, the marker path, the submit-url field value defaulting to /wan.asp, a user agent and a per-request timeout. A send mode additionally POSTs the request to the target and is refused for any non-loopback target unless an explicit allow-remote flag is given, and a print-request mode emits the exact HTTP request that would be transmitted while making no connection at all. Safety rails are loopback-only by default, one non-destructive marker command, no callback listener, no reverse shell, no persistence, and removal of every local file the run created. The tool's own documentation carries the warning that sending against a real device does change stored WAN configuration, because that is what the handler does on any successful submission, so the device's WAN settings must be restored afterwards. The model's published factory password appears in the tool only as a placeholder default so the request shape is self-documenting; the injection does not depend on it and the credential is reported as a separate weakness. Use only against systems you own or are authorised to test. -- 0day Rubbish Research Team disclosure@0day-rubbish.com https://0day-rubbish.com |