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 (DIR850LB1_FW220WWb03.bin).

user@kali:~/petage-dlink$ ./pwn-dlink-850-003 192.168.0.1
[...]
# uname -ap
Linux dlinkrouter 2.6.30.9 #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.
[...]
#

Firmware "protection"

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.

WAN && LAN - revA - XSS - CVE-2017-14413, CVE-2017-14414, CVE-2017-14415, CVE-2017-14416

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
#

WAN && LAN - revB - Retrieving admin password, gaining full access using the custom mydlink Cloud protocol - CVE-2017-14417, CVE-2017-14418

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

WAN - revA and revB - Weak Cloud protocol - CVE-2017-14419, CVE-2017-14420

Not checked as this is going to be taking to much time.

LAN - revB - Backdoor access - CVE-2017-14421

Corrected.

WAN && LAN - revA and revB - Stunnel private keys - CVE-2017-14422

Corrected - as shown below:

# ls -la /etc/stunnel.key
ls: /etc/stunnel.key: No such file or directory
#

The new certificate (/tmp/server.key and /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.

WAN && LAN - revA - Nonce bruteforcing for DNS configuration - CVE-2017-14423

Corrected - this file has been removed from the firmware image.

Local - revA and revB - Weak files permission and credentials stored in cleartext - CVE-2017-14424, CVE-2017-14425, CVE-2017-14426, CVE-2017-14427, CVE-2017-14428

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

WAN - revB - Pre-Auth RCEs as root (L2) - CVE-2017-14429

Corrected - the variables are sanitized.

LAN - revA and revB - DoS against some daemons - CVE-2017-14430

Corrected? I don't think so.

Conclusion

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.

Disclaimer

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/