Zyxel MAX3XX Series Wimax CPEs Hardcoded Root Password

`########################################  
#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.  
`