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