But it's in the software which ships with this chips and is meant to be used by everyone using the chip.
> Many such devices on the market today are based on HiSilicon (a Huawei brand) hi3520d ARM SoC running a special Linux distribution called HiLinux, with a set of user-space utilities and a custom web application on top.
(emphasis mine)
So while this is not a hardware backdoor it's in no way less problematic.
EDIT: Which you never said it was... Anyway it's useful to know that it's the software which is chipped alongside with the chip and not some arbitrary 3rd party software some arbitrary OEM put on-top of it.
That the chip is running an operating system provided by the chip manufacturer does not imply the OEM didn't add their own stuff. Even the part you emphasized includes the "custom web application on top" which is probably not provided by HiSilicon. (Otherwise, what's custom about it?)
Yeah, it seems this is all just buggy application code. The title should probably be changed to something less suggestive, particularly given current paranoia around Chinese surveillance.
They're not claiming it's not a backdoor; they're claiming the backdoor is not in "HiSilicon based hardware video encoders", but rather in management software associated with said encoders. The former would be near impossible to fix, whereas the latter can (supposedly) easily be replaced.
Edit: to be clear: 1, I don't know that the backdoor isn't in the hardware itself, but that's what they're claiming. 2, it sounds like the software in question is the manufacturer-provided drivers for the hardware, which is worth emphasizing, but not the same as the hardware itself being compromised.
Yet another reason not to trust proprietary OEM software. This article is really nice since it explains part of the reverse engineering process, helping others achieve the non-trivial task of replacing bad OEM stuff with free software.
OpenWRT doesn't run on Broadcom chips because the devs do not want to include non free software in OpenWRT and Broadcom only works on Linux with their proprietary blobs. The raspi thus requires this proprietary stuff in their Raspbian OS and afaik in all the third party OSs for it.
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.
Cool! I wonder how much it will be. The Wyze/Xiaomi cams are MIPS 32 bit and the pine cube is ARM. Also the pine cube seems to have a better wifi and more flash. Wyze only has 16 so it can be a tight fit. Also bluetooth and PoE. All very nice additions but I wonder if it will push it over the $20 price point for a cheap IP cam.
Very nice. I had used DaFang Hacks previously to get RTSP support, but now WYZE provides a semi-official RTSP firmware so I've been using that (and it's much better than DaFang Hacks). It looks like you've recently added RTSP as well. I've give it a try!
I don't really get why IP cameras don't run RTOSes on the application processor. It seems like the schedules are basically fixed anyway.
Could be an area of exploration.
Maybe when the Pine64 Cube is out, I'll take a crack at it, maybe on Tock if its scheduler can do what I want. It looks like most or all of the required drivers are in upstream linux, which should take some of the mystery out of it.
I would love to get to the point where my IP cameras just dump MPEG-DASH streams into B2, ready to be streamed directly into a browser or mpv.
> I imagine supporting RTOS semantics to be an order of magnitude harder?
You can still do mixed scheduling on an RTOS, but it gives you the tools to avoid underruns or underprovisioning the static tasks (copying and transmitting video).
I guess maybe if you're pulling from the camera rather than pushing from it, then maybe it could be harder.
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.
Thought the same, until I bought a tiny drone, which you access by connecting to an unsecured WiFi access point it provides, over which one can access an open telnet server giving you something in the shape of kernel debugger for the RTOS it’s running.
What about wifi wall plug which every minute sends your wifi ssid and password in cleartext (inside some binary status packet, but still cleartext) to chinese servers. It was some Ogemray one.
People are quick to jump to conclusions especially when it comes to China but this is more like a half-assed attempt at a cloud account system than anything intentionally malicious.
I guess the idea would be that you'd have an account on their cloud service and it would cache the Wi-Fi password for you so that next time you buy a new smart home device, the client app can retrieve that password (as apps - at least on iOS - are not allowed to access saved Wi-Fi passwords) and automatically send it to the new device so it can connect to your wifi network without having to ask you to type the password.
How do they send that password? Well, they already have a telemetry channel for other reasons (like syncing the local on/off state of the plug with the cloud so local chances to the plug are reflected in the cloud app) so they decided to just stick it in there even though it's unnecessary and wasteful as the password would not change (and if it does, then the device would lose connection anyway so it would require explicit user intervention to reconfigure).
As an attacker interested in broad, general access, I would think to dump it onto the pile of rainbow tables I've accumulated, possibly with metadata to say "We got this from closeparen's wifi; try this preferentially when we figure out their email address"
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.
There have been plenty of alternatives for a while. Ambarella is the higher-end option, and Grain Media is one of the lower end options. I expect both of these companies (and others) to benefit from Huawei's loss here.
Why do you think they are squeezed out by Huawei? Ambarella has been continuously releasing improved products for surveillance cameras. Many of the top vendors of video cameras (Axis, Avigilon, Hanwha) either never used HiSilicon chips at all, or only used them in lower-end products.
HiSilicon has been the SoC of choice in many lower-end and consumer oriented products, but they were far from a monopoly in the space.
Partially because of the "low-end" keyword, for chips, volumes are key criteria, hisilicon sold way more chips there than others, it does seem like a monopoly to me though. Two years ago I read somewhere it has 80% of the chips shipped in surveillance market, not only for cameras, but NVR/DVR as well.
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.
Separating these devices physically is more secure than looking for alternative or reverse engineered firmwares. A VLAN would also suffice as long as it's not under the same subnet as your main LAN. Same applies to Wi-Fi. Also, separating these cameras is something you can reliably do yourself and today.
Yep, separate network segment with no internet access with a VPN gateway acting as a bridge. If you want to access the cameras you VPN into the gateway first.
This will shield the insecure cameras from remote attacks, provide transport-layer security thanks to the VPN without depending on the cameras themselves supporting that and would neutralize most backdoors unless the cameras have code to search for public wifi networks or bruteforce private networks to use as a covert channel.
You bring up a point of interest to me about the potential for malicious code that would bruteforce private networks to use as a covert channel. In regards to IoT devices, is there any documented cases of this happening in the wild? I could possibly see actors inserting malicious code baked in that would search for public wifi networks in things like a smart TV.
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").
> 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.
No, because you will find stuff like this in nearly all of their products.
It's fully intentional.
> It's also not a backdoor that the Chinese government (or whoever) can particularly easily exploit, since it listens on your local network.
Network isolation is well known to not be a reasonable security measure. Especially in home networks. I mean think about it many people have ton's of not necessary supper secure/trustable devices in their home network like:
TV setup boxes, the TV itself and most of IoT. Furthermore especially vendor provided routers are known to often not be so secure and well maintained taking often way to long to get security patches or not even get them at all.
Sure this is probably not build intentionally by the Chinese government to spy on US people. In a certain way it's worse, as it shows how Chines companies put backdoor by default in all kind of things "just in case" they are needed by anyone.
They didn't say it is not effective but that it is unreasonable for most consumers. Most consumers aren't running smart switches and somewhat advanced access points with multiple VLANs and configuring the firewall to control traffic flows between the VLANs. They're running an ISP provided router/modem/combo unit with no VLAN support at all.
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.
I was expecting some exotic VPU hardware backdoor. Nevertheless, the article was a good read.