Year after year, researchers are discovering more IoT devices using a P2P cloud connection. Last year's Defcon Talk of Paul Marrapese and Mandiant's recent discovery cover just some of the latest security publications. In this blog post, we'll present our latest research on such devices, namely the HiKam S6.
The camera is advertised as a fairly basic home security camera and is being retailed on multiple websites as well as a large German supermarket chain. Features include night vision, two-way audio, and an alarm system that can notify a user once motion is detected by the camera. The app requires to create a HiKam account. Afterwards, cameras can be added and controlled within the smartphone application. Two different app versions are available on the app stores: HiKam and HiKam Pro. On first sight, both apps have the same features and are just a design rebrand. On second look, some commands are changed within the HiKam Pro app. However, this does not affect the research results, as both protocols are still supported by the camera and the backbone of the HiKam infrastructure.
The app connects to the phone through a P2P protocol. Thus, all data should be exchanged directly between the camera and smartphone. The protocol uses a P2P cloud server to punch holes in the firewall to establish the direct link. Multiple function names were recovered in debug messages that would point to the CS2 P2P SDK.
The camera features the fairly common Hi3518 SoC manufactured by HiSilicon. There are three probe points next to the SoC which are wired to the UART of the device as shown in figure 1. Thus, a shell can be obtained on the device within minutes, which makes researching and identifying vulnerabilities much more easy.
We have found a huge number of critical security issues in the device and also its architecture/protocol and contacted the vendor through our responsible disclosure process back in March 2021. Our technical security advisory also contains a more detailed description of the vulnerabilities whereas this blog post gives an overview of how easy it is to remotely hijack HiKam devices and how many users might be affected.
Attacking Devices in your Local Network over the Internet
On first thought, one might think that these cameras are only vulnerable to exploits from the local network and thus only provide limited impact. However, the P2P mechanism allows for accessing the cameras that are hidden behind routers and firewalls. The flowchart 2.1 and 2.2 depict how the connection between the camera and smartphone app is established.
Keep in mind, that the end user only knows the short UID of the camera. UIDs are in the format Axxxxxx where x is a number. Hence, UIDs can be easily enumerated. UUIDs are longer IDs formatted like FFFF-123456-ABCDE. FFFF is the prefix of the UUID, which is set to EUA on our HiKam cameras. Paul Marrapese published multiple other prefixes that he came across.
As one can see in the pictures above, the direct link is established through a method called hole-punching. This method lets everyone connect to the camera as long as the UID is known. The major vulnerability results from the HiKam server translating easily guessable UIDs into UUIDs. This gives us the only piece of information that is necessary to register our computer in the P2P cloud as a camera. The flowcharts in figure 3.1 and 3.2 show the attack vector:
The attacker program as well as the camera try to register themselves as the same camera ID in the P2P cloud. However, as the camera only tries to register itself roughly every 60 seconds, it is very likely that the attacker will win this race condition by spam registering himself every second. Therefore, the wrong IP is returned to the mobile app and all communication is now being sent to the attacker instead of the camera. As most features require authentication, the app will include the MD5 hash of the camera's password. This hash can now be cracked easily.
To increase the impact of the vulnerability, multiple other vulnerabilities can be chained together for changing the password to an arbitrary one chosen by the attacker. This is possible because the received hash can be used in a relay attack to authenticate arbitrary messages to the real camera. Hence, full control of the camera can be taken. Using the WiGLE project, it is then possible to locate the camera using its surrounding Wi-Fi signals.
Visit the full advisory page for more insights regarding all the vulnerabilities, and their technical details, e.g., the analyzed XOR-CBC encryption of the login message for the P2P cloud.
P2P Cloud SDKs, a Never-Ending Story
This is not the first project where SEC Consult analyzed devices using P2P cloud SDKs (e.g., see this blog post from 2018 or this one also about the Gwelltimes P2P cloud), and as already mentioned at the beginning of this post, it is by far not the first case unearthed by security researchers all around the world. This blog post about a similar model from the same company, sharing big parts of the security model and requests, was published in 2016! Although the vendor was already informed about all these vulnerabilities 5 years ago, apparently nothing changed.
We often give IoT devices, such as surveillance cameras, quite intimate access to our lives. The security of such devices should be in the focus of their vendor and user. Sadly, this is often not the case for neither of them (at least until someone uncovers the gaping security issues in their devices). Therefore, the tireless work of these dedicated researchers plays a crucial part in securing available and future devices.
Related security advisory: Critical vulnerabilities in HiKam
This research was done by Steffen Robertz and Gerhard Hechenberger on behalf of SEC Consult Vulnerability Lab.
SEC Consult is always searching for talented security professionals to work in our team. More information can be found at: www.sec-consult.com
