Backdoors and other vulnerabilities in HiSilicon based hardware video encoders
kojenov.com
kojenov.com
I was expecting some exotic VPU hardware backdoor. Nevertheless, the article was a good read.
> 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.
They defend HiSilicon and suggest that the vulnerabilities were introduced on top of the SDK by the vendor.
Full administrative access with hard-coded password: https://kojenov.com/2020-09-15-hisilicon-encoder-vulnerabili...
Commonly known as backdoor.
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.
The title is extremely misleading.
Are the hardware and software made by separate vendors? According to the article they're both made by hisilicon.
On a Hikvision one I pulled apart recently it was literally a binary running as root called `backdoorServer`.
If anyone is interested this is the project: https://github.com/openmiko/openmiko
Apparently it's gonna cost 20-30$ :)
This is the store page but it's not available to order yet. Your best bet is probably following their news blog .
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.
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.
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...
You know who has in past been sued for copying competitors work, sometimes stealing the whole package including bugs and backdoors?
Here is a hit: the company is currently banned from multiple markets due to national security.
That brings a bit of nostalgia on for me. Interesting that a modern device would be set up this way.
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"
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.
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.
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.
I'm actually interested in working on some open source surveillance software
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.
"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.
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.
> 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").
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.
Just think about the fact that every Android app gets full local network access by default, and there's no native way to disable that permission.
Network isolation is effective. What you're describing is just a poor implementation / not really isolated.
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.