BugTraq
Hardcoded root password in Zyxel MAX3XX series Wimax CPEs Mar 23 2016 05:59PM
Gianni Carabelli (giannicarabelli gmail com)
########################################
#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.

[ reply ]


 

Privacy Statement
Copyright 2010, SecurityFocus