Full disclosure: 0day vulnerability (backdoor) in firmware for HiSilicon-based DVRs, NVRs and IP cameras


    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:


    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:
    Login Password
    root xmhdipc
    root klv123
    root xc3511
    root 123456
    root jvbzd
    root hi3518

    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.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 14

      0
      On which models does this vulnerability exist? Do you have a list?
        0
        Yeah, article has dedicated section «Affected devices» which refers to previous research with pretty extensive list of vendors: https://github.com/tothi/pwn-hisilicon-dvr#summary (bottom of page). This is quite big list, so it's hard to enumerate all affected models.
          0
          On which exact DVR you've tested this vulnerability?
            0
            Initial research performed against firmware for some Xiong Mai «HI3518C_50H10L»-based device. I hadn't physical access, only network one. I'll be provided with more specific information about that device tomorrow.

            Once vulnerability was discovered it was tested on a variety of other devices, without knowledge of their model or brand attribution. One of recent devices was branded as «H264dvr» and had «AHB7804R-MH-V2» string in it's ProductDefinition file.
              0
              Received more info: first camera was ELP-1881-POE (http://www.elpcctv.com/)
          +1

          Why do you accuse HiSilicon?


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

          The software you are talking about is supposed to be made by Xiongmai (Hangzhou Xiongmai Technology Co, XMtech).
          Sofia binary supported by custom busybox and dvrHelper.
          A lot of chinese noname companies just burn this stuff into their camera modules, because it just works.


          HiSilicon SoC itself and compliment software (Linux Kernel and Kernel modules from HiSilicon SDK) does not have this vulnerability.


          I've made firmware for HiSilicon-based camera by myself using only Kernel and modules from HiSilicon SDK and it has no backdoors of any kind.


          For example, AXIS does use HiSilicon chips in some cameras — are they at risk? No.

            0
            Thanks you! I've added update to an article.
              +1

              This is more clear now from your updating and comments above, that HiSilicon is the Victim !however, i noticed that some IT/security media website already use your wording and research information try to mix those responsiblity with HiSilicon, even accuse Huawei that "Huawei effectively built a poorly hidden, insecure backdoor into potentially millions of surveillance devices that use its HiSilicon subsidiary's chips". Did those Medias respect your original creation intention or ask your permission or authorization?


              Wording from the Register:
              https://www.theregister.co.uk/2020/02/04/hisilicon_camera_backdoor/
              "Huawei effectively built a poorly hidden, insecure backdoor into potentially millions of surveillance devices that use its HiSilicon subsidiary's chips, it appears.


              This security blunder could be exploited over the local network to inject commands into vulnerable equipment."


              Wording from ZDNET:
              https://www.zdnet.com/article/researcher-backdoor-mechanism-discovered-in-devices-using-hisilicon-chips/


              "Russian security researcher Vladislav Yarmak has published today details about a backdoor mechanism he discovered in HiSilicon chips, used by millions of smart devices across the globe, such as security cameras, DVRs, NVRs, and others.


              A firmware fix is not currently available as Yarmak did not report the issue to HiSilicon citing a lack of trust in the vendor to properly fix the issue."

                0
                Did those Medias respect your original creation intention or ask your permission or authorization?
                This report is supposed to be widely disseminated, so I'm glad media works how it works.

                That particular article on The Register has many inaccuracies like lame analysis based on Shodan output and so on. However, article does what intended and notifies users: action required!
            +2
            There are several issues on these SoCs and I've complained to Huawei Europe on several occasions about the GPL violations in HiSilicon devices without much effect

            Running «strings» on the Sofia binary is «educational» — there are even RSA private keys in there! — along with other stuff that shows XiongMai's complaints about «software piracy» are extremely hypocritical.

            Perhaps a project to reverse engineer and replace Sofia might be worthwhile. This is a Monolithic «thing» that seems to be stripped, but at the same time appears not to be — and it would be worth seeing what it is doing as well as removing the nasty «activeX» stuff and the insistence on using the XMeye tunnel that quite effectively backdoors your private network if you are not careful.

            For what it's worth: The information I've been able to find is that XiongMai were contracted to write this DVR software by Huawei/HiSilicon, so it is probably correct to blame them both for this mess — however one of the biggest problems is that whils the code is very poor (so are Huawei's switches) they are too «proud» to listen to suggestions from «outsiders»

            One way of solving that would be to rewrite the implementation to be secure, much smaller/faster and GPL (which will embarrass them)

              +1
              Great work! The improvement was that you have decrypted challenge/responce required to open telnet sesion, was it?
              BTW, have you been interviewed by Cnews? They state that vulenrability is built-in in HiSilicon CPUs (based on interview). Is it correct statement?
                +1
                Great work! The improvement was that you have decrypted challenge/responce required to open telnet sesion, was it?
                That's correct
                BTW, have you been interviewed by Cnews? They state that vulenrability built-in in HiSilicon CPUs (based on interview). Is it correct statement?
                I had interview with them. During the interview I've outlined vulnerability is restricted to DVR-specific software. Statement in article about processors is likely a misconception inferred from common trait of those devices.
                +1

                there are already some uppdating on history vulnarability which mentioned in your articles.


                Here I also found some declarations uppdating for your reference for history vulnarability which mentioned in your articles from internet.


                we may need to take some efforts to disminish the unproper negative impact and harm, both on vendors and End users as a security research. i also realize the consequence and harm may be more serious as the vunarability after the media misconception and dissemination.


                https://blog.netlab.360.com/the-new-developments-of-the-fbot/


                (original blog with chinese was translated by google translation)


                New progress on FBot
                [Update: December 4, 2019] Recently we have received many inquiries about this blog. We decided to add some facts as follows:
                -Kenneth Crurrin Schuchman, nicknamed Nexus-Zeta, a 21-year-old young man, has pleaded guilty to the US District Court for Alaska on September 3, 2019. Schuchman's confession shows that Schuchman and his co-conspirators created a series of botnets, including Satori, Okiru, Masuta, Tsunami, and Fbot, by infecting a large number of devices, and used these botnets' DDoS destructive power to make a profit;-in
                this blog The vulnerability involved does not occur at Hisilicon. Through follow-up analysis and communication with the security community, we confirmed that the vulnerability occurred at the downstream suppliers of Huawei Hisilicon's supply chain. In order to protect the interests of the end customers, we have decided not to disclose the details of the vulnerability, the payload used by the attacker or the specific manufacturer's name;
                -Huawei PSIRT responded responsibly to the security incidents we disclosed;


                Readers should continue to read this blog, it should be clear that the word Hisilicon appears in the blog and samples, which originated from the misjudgment of Schuchman and his co-conspirators. In fact, the entire IoT industry chain is complex, and its volume far exceeds the scope that an attacker or any single practitioner can understand. Only the cooperation of the industry and the security community can enhance the security of the industry chain.


                (more information refer to the original blog...)

                  +1
                  I mean, we may need to take some efforts to diminish the improper negative impact and harm, both on vendors and End users as a security research community as i also realize the consequence and harm may be more serious as the vulnerability does exist and may still not be patched or very difficult be patched one by one for different version. especially after the media misconception and dissemination.

                  Only users with full accounts can post comments. Log in, please.