full-disclosure - Re: [FD] Pwning the Dlink 850L routers and abusing the MyDlink Cloud protocol

Open Source and information security mailing list archives

Date: Thu, 21 Sep 2017 01:25:17 +0200
From: Pierre Kim <pierre.kim.sec@...il.com>
To: bugtraq@...urityfocus.com, fulldisclosure <fulldisclosure@...lists.org>
Subject: Re: [FD] Pwning the Dlink 850L routers and abusing the MyDlink
	Cloud protocol

Hello,

Following the advisory posted to FD and Buqtraq about "Pwning the
Dlink 850L routers and abusing the MyDlink Cloud protocol"
the HTML version on analyzing the security on the corrected
firmware for Dlink 850L routers is posted here:
    https://pierrekim.github.io/blog/2017-09-21-update-dlink-850l-mydlink-cloud-0days-vulnerabilities.html

Please find a text-only version below sent to security mailing lists.

=== text-version ===

An update on the post "Pwning the Dlink 850L routers and abusing the
MyDlink Cloud protocol
(https://pierrekim.github.io/blog/2017-09-08-dlink-850l-mydlink-cloud-0days-vulnerabilities.html)":

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@...i:~/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@...alhost" -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/](http://creativecommons.org/licenses/by-nc-sa/3.0/)

-- 
Pierre Kim
pierre.kim.sec@...il.com
@PierreKimSec
https://pierrekim.github.io/

_______________________________________________
Sent through the Full Disclosure mailing list
https://nmap.org/mailman/listinfo/fulldisclosure
Web Archives & RSS: http://seclists.org/fulldisclosure/

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives