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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 21 Sep 2017 01:25:17 +0200
From: Pierre Kim <>
To:, fulldisclosure <>
Subject: Re: [FD] Pwning the Dlink 850L routers and abusing the MyDlink
	Cloud protocol


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:

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

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:

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
    # uname -ap
    Linux dlinkrouter #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,

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 (

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


## 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/` script. It's a self-signed certificate:

    # cat scripts/
    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

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
    # 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
    # cat /var/etc/hnapasswd
    # 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
    # ls -la /var/run/storage_account_root
    -rw-rw-rw-    1 root     root           12 Jan  1 00:00
    # cat /var/run/storage_account_root
    # ls -la /var/run/hostapd*conf
    -rw-rw-rw-    1 root     root         1160 Jan  1 00:00
    -rw-rw-rw-    1 root     root         1170 Jan  1 00:00

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

Pierre Kim

Sent through the Full Disclosure mailing list
Web Archives & RSS:

Powered by blists - more mailing lists