Backdoors and other vulnerabilities in HiSilicon based hardware video encoders

  • The vulnerability is not in the computer chip. The vulnerability is in the management software of the OEMs.

    I was expecting some exotic VPU hardware backdoor. Nevertheless, the article was a good read.

  • No, this is a backdoor in application software that runs on a device based on huawei silicon. This is like blaming broadcom for openwrt bugs.

    The title is extremely misleading.

  • They went to some amount of effort to hide it.

    On a Hikvision one I pulled apart recently it was literally a binary running as root called `backdoorServer`.

  • This is actually one of many reasons I started my own project to rewrite some of the firmware on an IP camera that I bought (WyzeCam). I wanted something open where I owned most of the stack and could customize as needed. I'm not as worried with a hardware level backdoor but firmware backdoors and/or just bugs are more worrisome. It has been a great learning experience working on the embedded side.

    If anyone is interested this is the project: https://github.com/openmiko/openmiko

  • I have two of these Hi3520D video encoders, from different manufacturers. They provide services (live-encoding H.264/HEVC to SRT or similar) you'd otherwise have to get a box that's 20x as expensive for, but they are also of course rather buggy, and don't have the best quality-per-bitrate.

    When I asked the manufacturers about the telnet password, one of them refused to give it to me (I followed basically the same steps as OP to get the passwd file, and cracked the hash -- it was their domain name...). The other one went, “err, we're not quite sure, but we think it might be <name of competitor>”. And while the competitor's name didn't work, I found _their_ default root password on some random site, and lo and behold, full root access...

  • "root access via telnet...The telnet daemon is running on the device by default, and there is no way to disable it via the official admin web interface"

    That brings a bit of nostalgia on for me. Interesting that a modern device would be set up this way.

  • all the HiSilicon stuff I've RE'd had hardcoded root passwords less than 8 characters in length, and a telnet server running with root login permitted. many of the passwords I've run across are actually the SDK defaults. all but one used the default webadmin setup included with the SDK that allows downloading a config backup that includes the passwd file. not much need for a back door when the front door is wide open...

  • So in short, when plugging in CCTV cameras, avoid wifi and instead keep them on wired ethernet physically and logically segregated from anything that matters. This should already be standard practice.

    Clearly, the cause is just shitty firmware from vendors.

    Vendors are just small factory owners who decide to tool up to fabricate 1000s of simple reference design based products by assembling PCBs, cables and plastic enclosures, possibly in cardboard boxes with manuals, and then ship them at cut rates as quickly as possible to as many ends of the earth as will accept them.

    For vendors, firmware security is low on the priorities list. Their fixed costs, tooling costs, design rebadging overhead and the open reference designs from silicon vendors mean that with minimal value add they will have to produce a vast number of each design very quickly and cheaply in order to have any chance of obtaining a profit in a market essentially guaranteed to have numerous competitors.

    This misaligned incentive situation will remain the status quo so long as the majority of the market (which is Chinese, not foreign) doesn't practically care about anything other than cost.

    It is not some evil state conspiracy.

    If you think there is a market for open source high transparency devices with closed source silicon and driver isolation as a top level design priority, then by all means do a startup.

  • "5150 - serial to TCP Mysterious service. netcat connects but the server does not seem to react to any input"

    Pretty sure that would just be something that implements RFC2217. Virtual serial ports. Maybe ser2net. It's not going to react to input if there's nothing connected to the real serial port, or if you aren't implementing the protocol.

  • Hisilicon owns surveillance chip market, like 90+% of the market. TI used to own it but was beaten to death in about 3 years time span there.

    Based on recent Huawei silicon restrictions, not sure if there will be any alternatives.

    the best and secure way for surveillance market will be like PC in the old days, i.e. off-the-shelf components with open source code releases that anyone can install and upgrade.

  • Why is all that stuff even in there? Ngnix? Telnet?

    "The default credentials are admin/admin".

    This is so common. That's one problem with embedded Linux - there's just too much junk in Linux that has no business in an embedded system, and it's hard to take it all out.

  • What’s the state of alternative firmware for Hikvision cameras? I have several. I keep them shuttered away from internet access, but why’re still on the LAN and that makes me nervous.

  • The term "backdoor" is motivation-neutral - while this is a backdoor, you don't have enough information to establish intent, so I'm surprised at this conclusion:

    > While most vulnerabilities seem unintentional (i.e. coding mistakes), one of them stands out. The hardcoded password is a deliberate backdoor.

    It certainly could be, and there are good arguments that it probably is, but it also could be something they put in for testing and forgot to take out. (It could be quite literally a backdoor they deliberately added during testing but didn't intend to ship in production.) Certainly there's no shortage of US-based companies that have done this and have offered that rationale for why their production products have backdoors.

    It's also not a backdoor that the Chinese government (or whoever) can particularly easily exploit, since it listens on your local network. Unless you're connecting it directly to the internet or forwarding the admin port from the public internet with no further authentication, it's not accessible to outside attackers.

    If they had an automatic firmware update mechanism that connected to a server on the internet, that would be much more easily accessible (but also, we generally don't call automatic update mechanisms "backdoors").

  • What an amazing article and breakdown/RE.

    Very informative and helped me to understand what all the different vulnerabilities were and how they could be exploited by easy to understand examples.

    Well done!

    As a side note, THIS is why security research is needed and why attempts to make security research illegal (Voatz) will have disasterous effects on national security.