This is a full disclosure of recent backdoor integrated into DVR/NVR devices built on top of HiSilicon SoC. Described vulnerability allows attacker to gain root shell access and full control of device. Full disclosure format for this report has been chosen due to lack of trust to vendor. Proof of concept code is presented below.

Previous work and historical context

HiSilicon has a long track record of implementing backdoor access on their devices.

Earliest known versions of it had telnet access enabled with a static root password which can be recovered from firmware image with (relatively) little computation effort. This vulnerability was covered by previous author's article (in Russian) in 2013. In 2017 Istvan Toth did a most comprehensive analysis of HiSilicon firmware. He also discovered remote code execution vulnerability in the built-in webserver and many other vulnerabilities. It's worth noting that disclosure was ignored by vendor.

More recent firmware versions had telnet access and debug port (9527/tcp) disabled by default. Instead they had open port 9530/tcp which was used to accept special command to start telnet daemon and enable shell access with static password which is the same for all devices. Such case was covered by these articles:

• https://www.cnblogs.com/mmseh/p/6537924.html, 2017 (in Chinese)
• https://habr.com/ru/post/332526/, 2017 (in Russian, by Habr user CentALT)

Most recent firmware versions have open port 9530/tcp listening for special commands, but require cryptographic challenge-response authentication for them to be committed. This is a subject of actual disclosure.

Apparently, all these years HiSilicon was unwilling or incapable to provide adequate security fixes for same backdoor which, by the way, was implemented intentionally.

Technical details

Vulnerable DVR/NVR/IP camera devices under discussion are running Linux with minimal set of utilities provided by busybox, main video application Sofia and a small set of custom auxilary utilities responsible for support of device operation. Hardware has ARM-based CPU tens to hundreds megabytes of RAM.

Device with vulnerable firmware has macGuarder or dvrHelper process running and accepting connections on TCP port 9530. Code and log strings suggest that macGuarder formerly was a separate process, but later it's functions were merged into dvrHelper process as a separate thread.

It's worth noting that earlier versions of firmware had dvrHelper process compiled into busybox as additional applet. Taking into account busybox has GNU GPL license, it is possible that license violation takes place because dvrHelper software was distributed without source code.

Successful backdoor activation process is following:

1. Client opens connection to port TCP port 9530 of device and sends string OpenTelnet:OpenOnce prepended with byte indicating total message length. This step is last for previous versions of backdoor. Probably telnetd was already started if there no response after this step.
2. Server (device) anwers with string randNum:XXXXXXXX where XXXXXXXX is 8-digit random decimal number.
3. Client uses it's pre-shared key and constructs encryption key as concatenation of received random number and PSK.
4. Client encrypts random number with encryption key and sends it after string randNum:. Entire message is prepended with byte indicating total length of message.
5. Server loads same pre-shared key from file /mnt/custom/TelnetOEMPasswd or uses default key 2wj9fsa2 if file is missing.
6. Server performs encryption of random number and verifies result is identical with string from client. On success server sends string verify:OK or verify:ERROR otherwise.
7. Client encrypts string Telnet:OpenOnce, prepends it with total length byte, CMD: string and sends to server.
8. Server extracts and decryptes received command. If decryption result is equal to string Telnet:OpenOnce it responds with Open:OK, enables debug port 9527 and starts telnet daemon.

Entire authentication process may resemble some sort of HMAC challenge-response authentication except it uses symmetric cipher instead of hash. This particular symmetric cipher resembles some variation of 3DES-EDE2 for keys longer than 8 bytes and similar to simple DES for shorter keys.

It's easy to see that all clients need for successful authentication is knowledge of PSK (which is common and can be retrieved from firmware in plaintext) and implementation of that symmetric block cipher. Recovery of that symmetric cipher implementation is most difficult, but it was achieved during this research. Exploration and tests were conducted using this set of tools:

• Ghidra 9.1.1 from NSA (https://ghidra-sre.org/) — suite for binary executeble code inspection.
• QEMU (more specifically qemu-user in Debian chroot — https://www.qemu.org/) — software which allows foreign architecture binaries (ARM) to be executed transparently on host.
• Common GNU utilities and toolchain.

Once telnet daemon activated, it's very likely it will accept one of following login/password pairs:

These passwords can be recovered from firmware as well by bruteforce of hash in /etc/passwd file. Modern consumer-grade GPGPU with hashcat is capable to find pre-image for hash in a matter of hours.

Debug port 9527 accepts same login/password as Web UI and it also provides some shell access and functions to control the device. Speaking of Web UI accounts, attacker may reset password or grab password hashes from /mnt/mtd/Config/Account* files. Hash function was described in previous research by Istvan Toth.

Affected devices

Previous research has a good collection of brands affected: https://github.com/tothi/pwn-hisilicon-dvr#summary. There are dozens of brands and hundreds of models.

Author of this report, reposing on survey across population of random IP addresses, estimates total number of vulnerable devices exposed via Internet somewhere between hundreds of thousands and millions.

Probably, the easiest way to check whether your device is vulnerable is PoC code provided below.

Testing vulnerability

PoC code: https://github.com/Snawoot/hisilicon-dvr-telnet.

Building PoC program from source: run make in source directory.

Usage: ./hs-dvr-telnet HOST PSK

Most common PSK is default one: 2wj9fsa2.

Example session:

$ telnet 198.51.100.23
Trying 198.51.100.23...
telnet: Unable to connect to remote host: Connection refused
$ ./hs-dvr-telnet 198.51.100.23 2wj9fsa2
Sent OpenTelnet:OpenOnce command.
randNum:46930886
challenge=469308862wj9fsa2
verify:OK
Open:OK
$ telnet 198.51.100.23
Trying 198.51.100.23...
Connected to 198.51.100.23.
Escape character is '^]'.
LocalHost login: root
Password: 

IP address in example above is an IP address from address block reserved for documentation by RFC5737.

Device should be considered vulnerable if:

• Telnet port opens after hs-dvr-telnet run.
• Device responds with challenge on hs-dvr-telnet inquiry. Even if verification fails due to wrong PSK, there exists correct PSK extractable from firmware.
• hs-dvr-telnet stucks awaiting for response, but telnet port opens (this will happen with older firmware versions which require only OpenTelnet:OpenOnce command).

Mitigation

Taking into account earlier bogus fixes for that vulnerability (backdoor, actually) it is not practical to expect security fixes for firmware from vendor. Owners of such devices should consider switching to alternatives.

However, if replacement is not possible, device owners should completely restrict network access to these devices to trusted users. Ports involved in this vulnerability is 23/tcp, 9530/tcp, 9527/tcp, but earlier researches indicate there is no confidence other services implementation is solid and doesn't contain RCE vulnerabilities.

Subjects not covered by this research

Code analysis revealed that authentication procedure on port 9530 decrypts «CMD» payload with arbitrary size (up to size of buffer read from socket at once) into a buffer on stack with fixed size of 32 bytes. Targeted exploitation of this overflow requires knowledge of PSK, therefore it's more practical to proceed normal way to gain access. On the other hand, garbage sent with CMD command may cause stack corruption and dvrHelper daemon failure. Possible effects of that (potential) failure wasn't explored because macGuarder/dvrHelper backdoor functionality appears strictly superior and straightforward approach.

UPDATE (2020-02-05 02:10+00:00): Istvan Toth, author of previous research on this subject, presented his own implementation of PoC program: https://github.com/tothi/hs-dvr-telnet Given implementation is written in pure Python code and implements symmetric cipher in more clear way. Also it outlines differences between 3DES cipher variant used by HiSilicon for backdoor authentication and original 3DES cipher. These differences can be expressed by this git commit: https://github.com/tothi/pyDes/commit/7a26fe09dc5b57b175c6439fbbf496414598a7a2.

UPDATE (2020-02-05 17:28+00:00): Other researchers and habr users had pointed out such vulnerability is restricted to devices based on Xiongmai (Hangzhou Xiongmai Technology Co, XMtech) software, including products of other vendors which ship products based on such software. At this moment HiSilicon can't be held responsible for backdoor in dvrHelper/macGuarder binary.