Super-Admin Password Leak Affecting Zyxel CPE/ONT/LTE Fleet

1. Login privilege GET returned raw passwords

In the firmware source, zcfgFeDal_LoginPrivilege_Get iterates through RDM_OID_ZY_LOG_CFG_GP_ACCOUNT and copies each account's Password field directly into the outgoing JSON array.

json_object_object_add(paramJobj, "Username",
  JSON_OBJ_COPY(json_object_object_get(loginPrivilegeObj, "Username")));
json_object_object_add(paramJobj, "Password",
  JSON_OBJ_COPY(json_object_object_get(loginPrivilegeObj, "Password")));

The DAL command registration then exposes login_privilege as edit|get with an empty privilege string, even though the inline comment still says root_only.

2. TR-069 GET copied the whole management object

The TR-069 DAL getter uses a generic copy path across the management parameter list. That includes Password and ConnectionRequestPassword, which are copied out unless another layer explicitly strips them.

else {
  json_object_object_add(pramJobj, paraName,
    JSON_OBJ_COPY(json_object_object_get(mgmtJobj, paraName)));
}

The corresponding DAL registration exposes tr69 as get|edit.

3. Cosmetic hiding arrived after the backend exposure

Later patches show Zyxel masking values in display code by printing ******** for ACS and SIP passwords. That is a UI and CLI presentation fix, not a backend access-control fix.

printf("%-45s %s\n", "ACS Password", "********");

4. Subsequent metadata fixes confirm the sensitivity

Other later patches add PARAMETER_ATTR_PASSWORD to fields like Password, ConnectionRequestPassword, DefaultPassword, and PasswordHash. That change acknowledges these values should not have been returned verbatim in getter flows.

1. The shell script is only a front-end

I started with the extracted genpass shell wrapper, not the password algorithm itself. The script validates the serial format, exports it as SERIAL, sets LD_LIBRARY_PATH to Zyxel's extracted libraries, preloads libhook.so, and then invokes the real worker binary: /opt/genpass/getpassword.

The visible script does not derive passwords on its own. It acts as an execution harness that feeds controlled input into vendor code that was originally meant to run inside the router environment.

2. libhook.so replaces the router's serial source

The preload library supplies the serial number expected by the vendor code. Static analysis of its exported symbols shows that it overrides zyUtilIGetSerialNumber and zcfgBeCommonIsApplyRandomSupervisorPasswordNewAlgorithm.

In the first hook, the code calls getenv("SERIAL"). If the environment variable is present, it copies that value into the caller's buffer. If not, it falls back to the original function via dlsym(RTLD_NEXT, "zyUtilIGetSerialNumber"). In the second hook, it simply returns 1, forcing the "new random supervisor password" path on during emulation.

3. getpassword is an orchestrator, not the algorithm

String and symbol analysis of getpassword shows that it dynamically resolves the real generators at runtime. Its string table contains libzcfg_be.so, libzcfg_be_wind.so, zcfgBeCommonGenKeyBySerialNumMethod2, zcfgBeCommonGenKeyBySerialNumMethod3, zcfgBeCommonGenKeyBySerialNumConfigLength, zcfgBeCommonGenKeyBySerialNumConfigLengthOld, and zcfgBeWlanGenDefaultKey.

The binary does not embed one monolithic algorithm. It loads vendor library entry points, asks them for the required buffer sizes, invokes multiple generation routines, and prints the results under labels such as old/new supervisor, old/new admin, WIND-specific admin variants, and several Wi-Fi key families.

4. The emulator recreates enough of the firmware to make the vendor code run

This works in QEMU because the extracted filesystem still contains the userland and shared objects the original firmware expected. The wrapper points LD_LIBRARY_PATH at Zyxel's library directories, the preload hook substitutes missing hardware-derived state, and the vendor password functions execute as if they were running on the device.

From a reverse-engineering perspective, genpass is a harness around reusable product logic rather than a standalone cracking tool. The lab setup does not reimplement Zyxel's algorithms; it restores just enough runtime context to call them directly.

5. The supervisor routines are deterministic and portable

Disassembly of zcfgBeCommonGenKeyBySerialNumMethod2 and zcfgBeCommonGenKeyBySerialNumMethod3 shows two exact supervisor paths. Method2 computes MD5(serial), renders each digest byte as vendor-style hex where one-nibble bytes are duplicated instead of zero-padded, hashes that string again, and then samples every third character to build the old supervisor password.

Method3 reuses that same double-hash stream, uppercases it, derives a 16-bit seed from bytes 1 and 2 of MD5(serial), increments the seed until a ten-slot mod-3 schedule contains uppercase, lowercase, and digit classes, and then maps each sampled byte into safe alphabets with explicit substitutions for I, O, l, o, 1, and 0. That is why the generator can be ported cleanly into browser JavaScript: the firmware logic is deterministic and table driven.