SoC

Previous work and historical context

https://www.cnblogs.com/mmseh/p/6537924.html, 2017 (in Chinese)

https://habr.com/ru/post/332526/, 2017 (in Russian, by Habr user CentALT)

Technical details

Sofia

macGuarder

dvrHelper

macGuarder

dvrHelper

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. Server (device) anwers with string randNum:XXXXXXXX where XXXXXXXX is 8-digit random decimal number. Client uses it's pre-shared key and constructs encryption key as concatenation of received random number and PSK. Client encrypts random number with encryption key and sends it after string randNum: . Entire message is prepended with byte indicating total length of message. Server loads same pre-shared key from file /mnt/custom/TelnetOEMPasswd or uses default key 2wj9fsa2 if file is missing. 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. Client encrypts string Telnet:OpenOnce , prepends it with total length byte, CMD: string and sends to server. 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.

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.

Login Password root xmhdipc root klv123 root xc3511 root 123456 root jvbzd root hi3518

/etc/passwd

/mnt/mtd/Config/Account*

Affected devices

Testing vulnerability

make

./hs-dvr-telnet HOST PSK

2wj9fsa2

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

Telnet port opens after hs-dvr-telnet run.

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.

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

RCE

Subjects not covered by this research

This is a full disclosure of recent backdoor integrated into DVR/NVR devices built on top of HiSiliconwith Xiaongmai firmware. 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.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 DVR device's 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: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.Vulnerable DVR/NVR/IP camera devices under discussion are running Linux with minimal set of utilities provided by busybox , main video applicationand 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 hasorprocess running and accepting connections on TCP port 9530. Code and log strings suggest thatformerly was a separate process, but later it's functions were merged intoprocess 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: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: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 infile. 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 fromfiles. Hash function was described in previous research by Istvan Toth.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.PoC code: https://github.com/Snawoot/hisilicon-dvr-telnet Building PoC program from source: runin source directory.Usage:Most common PSK is default one:Example session:IP address in example above is an IP address from address block reserved for documentation by RFC5737.Device should be considered vulnerable if: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 containvulnerabilities.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.(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 Xiongmai for backdoor authentication and original 3DES cipher. These differences can be expressed by this git commit: https://github.com/tothi/pyDes/commit/7a26fe09dc5b57b175c6439fbbf496414598a7a2 (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.(2020-02-21 10:30+00:00): Xiaongmai acknowledged vulnerability and released a Security Advisory: link archive 2 . Body of actual article has been updated accordingly in order to reflect origin of vulnerability properly.