News broke this week about a critical vulnerability in the firmware of certain HiSilicon-based devices running software from Xiongmai, including network video recorders, IP enabled cameras, and digital video recorders. HiSilicon is a “system on a chip” (or SoC) manufacturer, and some of its products are intended for use in IP-enabled video equipment. The vulnerability was uncovered by Vladislav Yarmak, who characterizes it as a “backdoor.” His report explains how the devices will activate a telnet server when they receive a “secret knock” sent on port 9530/tcp. Yarmak reverse engineered the firmware and discovered how to activate the backdoor.
At Censys, our extended dataset for enterprise customers, the Universal Internet Data Set (UIDS), has been scanning port 9530 for some time now and found 188,989 hosts with that port open, although most of them are HTTP servers and other well known protocols, including SSH. Following Yarmak’s report, we did a more specific scan to look for the vulnerable HiSilicon service globally. Using the Censys scanning infrastructure, we found 9362 hosts listening on 9530/tcp that speak the HiSilicon protocol.
Geographically, the two most popular countries for these devices are Taiwan and Vietnam, followed by Brazil, Turkey, and other countries.
Port 9530 is just one of over 1000 ports we scan regularly, so we can also explore what other ports are open on those hosts. The RTSP (real-time streaming protocol) service on 554/tcp dominates, which is something you’d expect for a video-over-IP system. Of the 137 hosts we further analyzed, 100 of them had RTSP listening on port 554, 50 had HTTP open on port 80, and 17 had port 9527 open.
Further Vulnerabilities
Yarnak describes how the devices use a challenge-response protocol to activate the backdoor: the server sends a random eight-digit number and requires the client to reply with that number encrypted with a pre-shared key embedded in the firmware.
Looking at a set of “random” values sent by the responsive hosts, we noticed that they are dominated by a single value, with several other values also occurring repeatedly. The chart below shows the ten most common values, sorted by frequency—note the log scale on the vertical axis:
Clearly, these aren’t even random! The first bar shows that 8759 of the 9362 “random” values were identical.
Upon further investigation, there seem to be two distinct families of hosts, each with its own interesting flaw in the pseudo-random number generator (PRNG):
- Most hosts appear to use a hard-coded seed for the PRNG, making it output a fixed sequence, probably restarting every time the device boots. The vast majority of devices haven’t been probed before, so they all use the same challenge value. An attacker who observed the correct response for that value could replay it to all the other devices that are in the same PRNG state.
- A smaller number of hosts appear to use a time-based PRNG that is seeded with the current time, in seconds. This makes it possible to replay challenge responses from one device to the others within a short time interval (more than a second, because the clocks are not all in sync).
Of course, thanks to the flaws already disclosed by Yarnak, the devices can be exploited without taking advantage of these PRNG vulnerabilities—the pre-shared key used to create the challenge responses is hard-coded in the firmware and easy to extract. Still, it’s an interesting example of weakness in depth—an implementation that has one very bad security misbehavior, like the presence of a backdoor, is likely to have other significant security flaws, which might independently provide attackers a way in.
Security flaws like those found in the HiSilicon SoC system rarely happen in isolation; they usually represent systemic flaws in engineering design and implementation. It’s unclear whether the flaw found was intended as a nefarious backdoor, but the risk of malicious exploitation was certainly compounded by negligence in the form of hard-coded credentials and broken cryptography. Unfortunately, flaws like these are all too common in embedded devices, and leave millions of consumers and organizations at risk.
To learn more about Censys and see our tools in action, please visit us at www.censys.io, and follow us at @censysio .
