Zyxel MAX3XX Series Wimax CPEs Hardcoded Root Password
Posted on 28 March 2016
######################################## #Vulnerability Title: Hardcoded root password in Zyxel MAX3XX series Wimax CPEs #Date: 23/03/2016 #Product: Zyxel MAX3XX series CPEs #Vendor: www.zyxel.com #Affected Firmware: Latest version at the time of disclosure v 2.00 and below (tested) #Patch: Unpatched #Vendor contact date: 12/12/2015 #Authored by: Gianni Carabelli <giannicarabelli (at) gmail.com> ######################################## #Introdution Zyxel produces some IEEE 802.16e CPE devices. These devices are usually owned by ISP, that grant the usage to the subscriber. Subscriber can't usually login with admin privileges on the devices, due to ISP policy, but only with less privileges (guest user). #Technical details: Affected models suffer CWE-25 for telnet, ssh, serial access. In /bin/busybox and /bin/dropbear there are hardcoded plain text passwords, easily discoverable reading the binaries. These binaries are not readable by web interface, so to analyze the firmware there are only two known ways: * dumping the firmware via jtag * download the binary firmware from the vendor site, unpack and analyze it In the login process, the standard /bin/shadow is not honored at all, so dropbear or busybox are doing something strange to do authentication. The binaries busybox and dropbear are located on a squashfs filesystem (so a readonly fs). This filesystem is mounted via loopback and lives in a file (/etc/initrd). /etc is the mountpoint of a jffs2 (rw) partition. User with hardcoded password are "root" (uid 0) and another one (usually "mfgroot" with uid 0) Password discover example: wget 'ftp://ftp.zyxel.com/MAX318M/firmware/MAX318M_2.00(UUA.1)D0.zip' unzip MAX*zip tar xvfz 200UUA1D0/ras/200UUA1D0.bin binwalk -e initrd strings `find -name busybox` |grep -A 10 Password #Affected devices: MAX208 MAX218 MAX306 MAX318 HES319 # Other devices that may run the same software: GREENPACKET WIMAX CPE - unknown models (untested) Huawei wimax CPE BMxxx (untested) Other mt710x devices #Impact It is a ISP decision to leave ssh/telnet open or not. Usually ftp is always open for maintenance, but often also the other ones are open. Due to reflashing the CPE by ftp is allowed, a malicious user can take control of the CPE uploading a modified firmware via ftp. If ISP leave also ssh or telnet open a malicious user take easily control over the device without any reflash. #The worst * The device is no more actively supported, but still in production in large scale. * On the filesystem, there is also tcpdump, so subscriber LAN (eth0) are not at safe. All pc and connected devices, can be sniffed. * Playing with ARP tables or DNS proxy, already on the board, it easily possible to perform MITM attacks. * Some ISP offer natted internet access, so malicious user may operate only in LAN, using private IP. But some ISP offer dinamic public IP, or premium public fixed IP, so wmx0 of the device has an assigned internet IP. Scanning the ISP ip class, may reveal critical situations * Due to ISP buy these devices in stock, a high percentage of the subscriber devices may be one of the affected ones, if ISP chose that vendor as device provider. #Mitigation End user (subscriber) can't do anything do protect his network from this vulnerability. Due to the binaries are on a squashfs only a reflash of the CPE, done by ISP, can fix the problem. At the moment, no firmware for these devices are known to be without the hardcoded password.
