An update on the post "Pwning the Dlink 850L routers and abusing the MyDlink Cloud protocol":
MITRE was very effective and provided several CVEs for these vulnerabilities:
CVE-2017-14413, CVE-2017-14414, CVE-2017-14415, CVE-2017-14416, CVE-2017-14417, CVE-2017-14418, CVE-2017-14419, CVE-2017-14420, CVE-2017-14421, CVE-2017-14422, CVE-2017-14423, CVE-2017-14424, CVE-2017-14425, CVE-2017-14426, CVE-2017-14427, CVE-2017-14428, CVE-2017-14429, CVE-2017-14430.
D-Link provided firmware updates at: http://supportannouncement.us.dlink.com/announcement/publication.aspx?name=SAP10074.
Full-Disclosure seems to work! It forced D-Link to provide working security patches to the public in a timely manner.
Only 14 CVEs (of 18 CVEs) are recognized in the list from the Security Announcement from D-Link. I verified myself that the vulnerabilities have been indeed patched or not - for all 18 CVEs - as shown below on a real router with the latest firmware.
This work was possible thanks to another pre-auth 0day exploit that I have not yet released and which still works against the latest revB firmware (
user@kali:~/petage-dlink$ ./pwn-dlink-850-003 192.168.0.1 [...] # uname -ap Linux dlinkrouter 188.8.131.52 #1 Mon Sep 18 10:27:42 CST 2017 rlx GNU/Linux # busybox BusyBox v1.14.1 (2017-09-18 20:18:33 CST) multi-call binary Copyright (C) 1998-2008 Erik Andersen, Rob Landley, Denys Vlasenko and others. Licensed under GPLv2. [...] #
The algorithm seems to have been updated. The previous program doesn't work anymore. Luckily, having a root shell on the device gives me some hints about how to decipher firmware images.
Corrected - the vulnerable files have been removed, as shown below:
# cd /htdocs/web # ls -la *php -rw-r--r-- 1 root root 143 Sep 18 2017 wiz_mydlink.php -rw-r--r-- 1 root root 3768 Sep 18 2017 vpnconfig.php -rw-r--r-- 1 root root 204 Sep 18 2017 version.php -rw-r--r-- 1 root root 1074 Sep 18 2017 getcfg.php -rw-r--r-- 1 root root 2661 Sep 18 2017 dnslog.php -rw-r--r-- 1 root root 149 Sep 18 2017 bsc_mydlink.php #
Corrected - the vulnerable file has been removed.
# ls /htdocs/web/register_send.php ls: /htdocs/web/register_send.php: No such file or directory #
Note that the device still sends clear-text passwords to the Cloud protocol (www.mydlink.com).
Not checked as this is going to be taking to much time.
Corrected - as shown below:
# ls -la /etc/stunnel.key ls: /etc/stunnel.key: No such file or directory #
The new certificate (
/tmp/server.crt) is generated on-the-fly during the boot process by the
scripts/updatessl.sh script. It's a self-signed certificate:
# cat scripts/updatessl.sh [...] openssl req -new -newkey rsa:2048 -days $SSLDAYS -sha256 -nodes -x509 -subj "/C=TW/ST=Taiwan/L=Taipei/O=D-Link Corporation/OU=D-Link WRPD/CN=General Root CA/emailAddress=webmaster@localhost" -extensions usr_cert -keyout $TMPKEY -out $TMPPEM -config /etc/openssl.cnf -rand $TMPRAND [...]
This opens question about the security of the Cloud protocol.
Corrected - this file has been removed from the firmware image.
Corrected - the passwords are replaced by 'x' everywhere:
# cat /var/passwd "Admin" "x" "0" # cat /var/etc/hnapasswd Admin:x # ls -la /var/passwd -rw-rw-rw- 1 root root 16 Jan 1 00:00 /var/passwd # cat /var/passwd "Admin" "x" "0" # ls -la /var/etc/hnapasswd -rw-rw-rw- 1 root root 8 Jan 1 00:00 /var/etc/hnapasswd # cat /var/etc/hnapasswd Admin:x # cat /var/etc/hnapasswd Admin:x # ls -la /var/etc/hnapasswd -rw-rw-rw- 1 root root 8 Jan 1 00:00 /var/etc/hnapasswd # ls -la /var/etc/passwd -rw-r--r-- 1 root root 146 Jan 1 00:00 /var/etc/passwd # cat /var/etc/passwd root:x:0:0:Linux User,,,:/home/root:/bin/sh nobody:x:1000:500:Linux User,,,:/home/nobody:/bin/sh Admin:x:1001:0:Linux User,,,:/home/Admin:/bin/sh # cat /var/etc/shadow root:!:10956:0:99999:7::: nobody:!:10956:0:99999:7::: Admin:!:10956:0:99999:7::: # ls -la /var/run/storage_account_root -rw-rw-rw- 1 root root 12 Jan 1 00:00 /var/run/storage_account_root # cat /var/run/storage_account_root admin:x,::: # ls -la /var/run/hostapd*conf -rw-rw-rw- 1 root root 1160 Jan 1 00:00 /var/run/hostapd-wlan1.conf -rw-rw-rw- 1 root root 1170 Jan 1 00:00 /var/run/hostapd-wlan0.conf
Corrected - the variables are sanitized.
Corrected? I don't think so.
I'm happily surprised by the results of dropping 0days without coordinated disclosure when it is about D-Link products. Should this be the only method with D-Link to get working security patches in a timely manner?
Hopefully one day a coordinated disclosure could work in the same way.
This research is licensed under a Creative Commons Attribution Non-Commercial Share-Alike 3.0 License: http://creativecommons.org/licenses/by-nc-sa/3.0/
published on 2017-09-21 00:00:00 by Pierre Kim <email@example.com>
|2017-09-08 00:00:00||Pwning the Dlink 850L routers and abusing the MyDlink Cloud protocol|
|2017-09-07 00:00:00||Zer0con slides - Owning embedded devices and network protocols|
|2017-03-08 00:00:00||Multiple vulnerabilities found in Wireless IP Camera (P2P) WIFICAM cameras and vulnerabilities in custom http server|
|2017-02-09 00:00:00||TP-Link C2 and C20i vulnerable to command injection (authenticated root RCE), DoS, improper firewall rules|
|2017-02-07 00:00:00||CVE-2017-5850 - Remote DoS against OpenBSD http server (up to 6.0)|
|2017-02-02 00:00:00||Update - Multiple vulnerabilities found in the Dlink DWR-932B (backdoor, backdoor accounts, weak WPS, RCE ...) - Analysis of the corrected firmware|
|2016-11-01 00:00:00||GPON FTTH networks (in)security|
|2016-10-17 00:00:00||Studying the Internet Censorship in South Korea|
|2016-09-28 00:00:00||Multiple vulnerabilities found in the Dlink DWR-932B (backdoor, backdoor accounts, weak WPS, RCE ...)|
|2016-04-04 00:00:00||Multiple vulnerabilities found in Quanta LTE routers (backdoor, backdoor accounts, RCE, weak WPS ...)|
|2016-02-16 00:00:00||Why I stopped using StartSSL (Hint it involves a Chinese company)|
|2016-01-15 00:00:00||CVE-2015-5677 - FreeBSD bsnmpd information disclosure|
|2016-01-05 00:00:00||CVE-2015-7944, CVE-2015-7945 - Ganeti Security Advisory (DoS, Unauthenticated Info Leak)|
|2015-12-01 00:00:00||Huawei Wimax routers vulnerable to multiple threats|
|2015-11-12 00:00:00||CVE-2015-8100 - OpenBSD package 'net-snmp' information disclosure|
|2015-10-07 00:00:00||A comprehensive study of Huawei 3G routers - XSS, CSRF, DoS, unauthenticated firmware update, RCE|
|2015-08-13 00:00:00||TOTOLINK Update - How to NOT handle security issues|
|2015-08-10 00:00:00||Watching SBS and KBS in a remote country|
|2015-07-27 00:00:00||updated - 172 ipTIME router models vulnerable to an unauthenticated RCE by sending a crafted DHCP request|
|2015-07-22 01:00:00||Why Full Disclosure is the solution ? An example with RIPE|
|2015-07-22 00:00:00||Using Linux (Debian 8) on a LG 13ZD950|
|2015-07-16 00:00:00||Backdoor credentials found in 4 TOTOLINK router models|
|2015-07-16 00:00:00||4 TOTOLINK router models vulnerable to CSRF and XSS attacks|
|2015-07-16 00:00:00||15 TOTOLINK router models vulnerable to multiple RCEs|
|2015-07-16 00:00:00||Backdoor and RCE found in 8 TOTOLINK router models|
|2015-07-06 00:00:00||127 ipTIME router models vulnerable to an unauthenticated RCE by sending a crafted DHCP request|
|2015-07-03 00:00:00||ipTIME n104r3 vulnerable to CSRF and XSS attacks|
|2015-07-01 00:00:00||Exploit Code for ipTIME firmwares < 9.58 RCE with root privileges against 127 router models|
|2015-06-23 00:00:00||Small monitoring system using Freemobile|
|2015-06-09 00:00:00||Recovering Windows on a "Windows-free" LG laptop|
|2015-05-05 00:00:00||ERRATA - 127 ipTIME Routers/WiFi APs/Modems/Firewalls models vulnerable with RCE with root privileges|
|2015-04-20 00:00:00||112 ipTIME Routers/WiFi APs/Modems/Firewalls models vulnerable with RCE with root privileges|
|2015-04-07 00:00:00||Annyeong haseyo!|