
0day vulnerability in firmware for HiSilicon-based DVRs, NVRs and IP cameras - mcsoft
https://habr.com/en/post/486856/
======
whalesalad
When you see how small some of these devices are it makes you realize how easy
it would be for a malicious actor to bug just about anything you own. A simple
cell phone charger becomes a listening device that could have an LTE modem
hiding in it.

People are worried when they find a raspberry pi sitting in the network rack -
and rightfully so - but fail to realize that you can achieve pretty much the
same thing by hiding in plain sight.

Imagine how much you could fit into a 6-port commodity surge protector.

~~~
r00fus
Without ruining the main use case - is there some way to sterilize or nuke
things like a basic cell phone charger when it should have no radio-frequency
capability?

~~~
RL_Quine
Nope. Even USB cables now have active electronics and a microprocessor in
them.

~~~
BubRoss
They don't have to. USB is four wires.

~~~
Piskvorrr
...and 500 mA maximum. Anything above that, and things get Complicated.

------
garaetjjte
Nothing surprising about it. These cheap Chinese cameras are just like that:
buggy, default telnet passwords, silly vulnerabilities, crashing ActiveX
plugins. Dahua/Xiongmai/Herospeed/whatever doesn't matter, everything is
awful.

Using these devices outside isolated VLAN with only RTSP tunneled to trusted
client is just bad idea.

~~~
close04
> buggy, default telnet passwords, silly vulnerabilities, crashing ActiveX
> plugins

This pretty much happens with any equipment. If it's very cheap there's no
reasonable expectation that they put too much effort into building and
maintaining it. If it's expensive there may be other interests involved.

The difference is what your nationalism dictates: When you hear of a Huawei
vulnerability you think "spying", and when you hear of a Cisco one (or five
[0]) you think "bug". In the end the choice is to buy cheap and have all the
careless bugs, or to buy expensive and only have the by design ones. And
whether you think they are malicious or not depends on where you come from
relative to the product.

[0] [https://www.tomshardware.com/news/cisco-backdoor-
hardcoded-a...](https://www.tomshardware.com/news/cisco-backdoor-hardcoded-
accounts-software,37480.html)

~~~
therealx
Or the semi-third option; firewall the living hell out of everything with
something you either wrote yourself or can read yourself. No guarantee there
either but you can avoid the garbage fire that is a lot of this. I'm sure the
NSA has exploits for everything tho.

~~~
greyhair
And that third option is only technically available to at most 10 percent of
the population, and most of them have neither the time ("day jobs") nor
inclination to spend their time in that effort. And that is discounting the
fact that the majority of the buggy appliances you encounter are developed by
that very 10 percent in the first place.

------
onesmallcoin
I love these HiSilicon boxes, take a look at the OpenIPC project if you want
to secure your device. It's open source firmware for these boxes, I want to
give a big shoutout to Igor Zalatov and Flyrouter for all their support when
working on these boxes [http://openipc.org](http://openipc.org)

------
lifeisstillgood
I know I am probably too forgiving (and generous and honest
[https://www.pinterest.co.uk/pin/439593613603376622/](https://www.pinterest.co.uk/pin/439593613603376622/))
but dumb companies have left backdoors in everything from heart monitors to
factory equipment.

I understood that the Huawei threat is not "dumb shit" but "clever shit we
don't notice until the cyber portion of the combined arms full scale attack is
launched"

If we cannot trust one hardware company we cannot trust any of them. Open
source hardware seems like the Nash Equilibrium for this problem - everyone
finds a way to make sure everyone can verify the hardware in their network...

~~~
gnfargbl
It is _both_ of those things.

And why wouldn’t it be? Huawei is a large organization and, like all large
organizations, will consist of a multitude of different groups all trying to
achieve the same goal in different ways. Some will want to rob the bank by
tunnelling quietly into the vault at night, some will want to walk through the
front door with a sawn-off shotgun.

~~~
lifeisstillgood
Fair enough - see my edit above. The only protection against dumb or clever
shit is some means to verify SoCs are what they claim to be (yes very hard,
but a future with Open source SoCs, and supply chains where you can inspect
enough to be confident - that future can be glimpsed from here and it's a
future where everyone wins)

~~~
yetihehe
> The only protection against dumb or clever shit is some means to verify SoCs
> are what they claim to be

That's only protection from clever shit. Dumb shit will have security
vulnerabilities due to being made by programmers who don't care, pushed to do
it faster by managers who don't care.

------
mavhc
Someone should just sell a camera and make the code open source, they'd
quickly eat all the market

~~~
PragmaticPulp
Open source has near-zero appeal outside of the hacker niche. The vast
majority of people only care about price and maybe customer support.

Open source isn't feasible for any of the mainstream systems anyway. It's not
up to the camera makers. The silicon vendors would have to open-source license
their chipset drivers and firmware source, which isn't going to happen any
time soon.

~~~
davidzweig
I think some Allwinner SOCs have blob-free mainline linux. If there are solid
drivers for everything (camera, ISP etc.), not sure. V3s is even QFN with
onboard ram, so easy to make a board for. Or use a board like this:
[https://licheepizero.us/](https://licheepizero.us/)

But, yeah, I think you're right, you'd struggle to compete on cost and
features with mass-market players.

You could offer open source firmware for some existing cameras.. I think some
people do do this.

~~~
consp
> I think some Allwinner SOCs have blob-free mainline linux.

Have they finally stopped doing all the GPL violations and published the code?

If no: then it is still a blob, only a linux kernel blob with unknown changes.

~~~
clarry
What blobs did you find in mainline Linux?

------
buran77
> 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.

This was an interesting update, especially the last sentence.

------
tryptophan
I wonder what the solution to this sort of thing is. Open source hardware
maybe? Force publication of firmware for all hardware sold?

~~~
somurzakov
1\. if the device name contains "smart" -> always assume it is vulnerable.

2\. put all IoT devices behind firewall/NAT router and never allow any traffic
from WAN to the IoT. (Allow only South->North traffic)

3\. Never allow east-west traffic between IoT devices.

~~~
voltagex_
OK but what does the general public do?

~~~
silon42
Separate WIFI/network for IoT devices. Do not route to the internet in any way
(skip buying anything that requires it). Connect to windows (or other OS) PC
only, non-routable. Disable all connections from that network to the PC.

~~~
therealx
You wish. People are not going to go to their local PC (if they even have one)
to use their smart lights. Likewise people are not going to change wireless
networks everytime they need to change a smart item.

The best combo I have found is non-cloud smart devices and a solid firewall.
I'm confident enough that my lightbulb isn't going to hack my Mac/Windows
machine, and I can still control it when I'm at home with my phone. If I want
outside control, then it's vpn time.

------
Trias11
So if device is behind firewall - attacker cannot sent TCP request to it?

~~~
pbalau
Being behind a nat, without _any_ firewall, is more than enough to protect
against this. In other words, you need to work hard to be affected by this
"backdoor".

~~~
vageli
> Being behind a nat, without any firewall, is more than enough to protect
> against this. In other words, you need to work hard to be affected by this
> "backdoor".

So long as the device does not utilize UPnP and get the gateway to forward
traffic to it.

------
exabrial
> Full disclosure format for this report has been chosen due to lack of trust
> to vendor. Proof of concept code is presented below.

------
pbalau
> Client opens connection to port TCP port 9530...

Good thing they are not opening a connection to UDP port 9530. Imagine the
horror...

------
ummonk
Flagged for misleading title.

------
inetknght
Is this Bloomberg and SuperMicro all over again?

~~~
gen3
No, there is proof of concept code.

from the article: [https://github.com/Snawoot/hisilicon-dvr-
telnet](https://github.com/Snawoot/hisilicon-dvr-telnet)

------
bitanarch
The title is misleading. HiSilicon is responsible for the SoC, but the
backdoor is part of the Linux-based device firmware made by another company
called Hangzhou Xiongmai Technology Co. There is no clear connection between
Huawei and Xiongmai.

You can find the clarification about the firmware maker (Xiongmai) towards the
end of the article.

~~~
yorwba
> There is no clear connection between Huawei and Xiongmai.

If Xiongmai firmware runs on HiSilicon SoCs, there must be some kind of
connection, even if just via a third party that paid HiSilicon for the
hardware and Xiongmai to write the firmware for it. Unfortunately, the writeup
doesn't clearly identify who that could be.

~~~
elipsey
This argument proves too much. By this reasoning, "Qualcomm-owned Cisco" is
"injecting backdoors" into their chips as well.[1]

The real title of the article is "0day vulnerability (backdoor) in firmware
for HiSilicon-based DVRs, NVRs and IP cameras" and the word Huawei doesn't
even appear in it.

If OP wants to claim that Huawei are involved, maybe they should write their
own article. :/

[1][https://www.zdnet.com/article/cisco-weve-killed-another-
crit...](https://www.zdnet.com/article/cisco-weve-killed-another-critical-
hard-coded-root-password-bug-patch-urgently/)

Edit: the title changed. criticism retracted.

~~~
wolfgke
> This argument proves too much. By this reasoning, "Qualcomm-owned Cisco" is
> "injecting backdoors" into their chips as well.[1]

I would not consider this to be past my belief ...

~~~
DyslexicAtheist
CISCO has not only a long history of creating backdoors, but have also been
marketing them as features. They even wrote an IETF proposal (RFC 2804) for a
LI backdoor:

[https://tools.ietf.org/html/rfc2804](https://tools.ietf.org/html/rfc2804)

[https://www.blackhat.com/presentations/bh-
dc-10/Cross_Tom/Bl...](https://www.blackhat.com/presentations/bh-
dc-10/Cross_Tom/BlackHat-DC-2010-Cross-Attacking-LawfulI-Intercept-slides.pdf)

Edit: Schneier wrote in 2018: _" We don't know if this is error or deliberate
action, but five backdoors have been discovered [in CISCO] already this
year."_ and linking to this article: [https://www.tomshardware.com/news/cisco-
backdoor-hardcoded-a...](https://www.tomshardware.com/news/cisco-backdoor-
hardcoded-accounts-software,37480.html) (the final count went up to 7 actual
backdoors discovered in 2018.

From May 2019: [https://www.scmagazineuk.com/cisco-firewalls-routers-
switche...](https://www.scmagazineuk.com/cisco-firewalls-routers-switches-
compromised-thrangrycat-just-dont-call-backdoor/article/1584822)

~~~
johnmaguire2013
The IETF proposal you linked is not for a backdoor. It's IETF refusing to set
rules on future IETF standards including, or not including wiretapping.

i.e. It states that whether a standard includes a wiretap or not is irrelevant
to it being an IETF standard.

------
easytiger
Why is the title sensationalised. There is no "injects backdoor into their
chips".

It's a debug console on a busybox build. One would have to be on the same lan
to exploit it.

~~~
cjbprime
> One would have to be on the same lan to exploit it.

For what it's worth, DNS rebinding attacks are commonly used against embedded
devices, and remove this restriction.

~~~
corford
Speaking of rebinding attacks... does anyone know why cloudflare's 1.1.1.1
resolver doesn't enforce this? It's the only "big" public one I know of that
happily resolves RFC1918 IPs.

~~~
zAy0LfpBZLC8mAC
That's a terrible idea. For one, RFC1918 addresses are perfectly fine IP
addresses, and as such are perfectly fine to put into DNS, but also, if your
security depends on this, you are not secure, because rebinding attacks work
just as well with non-RFC1918 addresses if that's what you happen to be using
on your local network, so devices and software have to be secured against
rebinding attacks with a non-filtering DNS anyway.

Plus, it just breaks things. More than once have I had the problem of trying
to serve files to other devices on a LAN I was visiting, only for their
idiotic local resolver to helpfully refuse resolving the host name of my
laptop because, oh surprise, it resolved to an address on that LAN!

------
LatteLazy
Isn't this just telnet? Like last time people claimed huawei "injected back
doors", nothing is being injected by them, and these are not backdoors, they
are front doors, standard festures etc? But dressed up in a way to make it
look scarey to someone non-technical? Sorry if I'm missing something here...

~~~
taneq
A hidden door that nobody but the installer of the door knows about is
generally referred to as a back door. If it was without the knowledge of the
main device manufacturer, then it was injected.

------
coliveira
The company in question, Xiongmai, is not owned by Huawei as stated. This is
probably a clickbait article trying to link Huawei with some kind of backdoor.

