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