HiKam - "Hi - I'm (not) your Kam"

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

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.

Picture of HiKam S6 UART pins
Figure 1: HiKam S6 UART pins

Brief overview of all vulnerabilities

  • Broken Authentication in the Web Interface: Setting a cookie bypasses the login.

  • Enumeration of all customer Cloud Devices and LAN/WAN IPs: All active cameras can be discovered, as shown below.

  • Message Protocol Downgrade: The message protocol can be downgraded to a previous version with less security checks.

  • Insufficient use of Cryptography: Usage of MD5 hashes as passwords as well as a custom XOR-CBC encryption.

  • Insufficient Message Protocol Checks: Due to insufficient checks of the protocol, hash relaying can be used to access all camera features once one hash is known.

  • Device Spoofing: Device IDs can be enumerated. This is the only required piece of information to simulate a camera.

  • Outdated Software Components: Multiple outdated software components were found in the OS.

  • Weak default credentials for Gwelltimes P2P accounts: For each app user, HiKam registers a user account for the Gwelltimes P2P cloud with a default password. The account is never used for HiKam S6; however, it is very likely, that older camera models can be accessed with these default credentials.

  • Leak of HiKam's SMTP credentials: The camera sends alert messages via email. The password for the company's SMTP server is leaked in the debug output.

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.

Flow graph of the HiKam camera operation
Figure 2.1: Flow graph of the camera's operation
Flow graph of the HiKam camera operation
Figure 2.2: Flow graph of the camera's operation

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:

Flow graph of the HiKam spoofing attack
Figure 3.1: Flow graph of the spoofing attack
Flow graph of the HiKam spoofing attack
Figure 3.2: Flow graph of the spoofing attack

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.

Location of HiKam devices used in different countries
Figure 4: Shares of devices used in different countries

Mapping Vulnerable Devices all over the World

By using some of the same steps above, the cameras will also leak their internal and external IP addresses. These IPs can be used to roughly locate the devices. During our research, we discovered around 26,000 online devices (February 2021) through the internet. The pie chart in figure 4 shows the shares of their locations. As can be seen, more than 80% of these devices are based in Germany, but some of them are also used in Austria and the US.

Heatmap of affected devices on a world map
Figure 5: Heatmap of affected devices worldwide [1]
Heatmap of affected devices in the U.S. on a world map
Figure 6: Heatmap of affected devices in the US [1]
Heatmap of affected devices in Europe
Figure 7: Heatmap of affected devices in Europe [1]

The heatmaps in figure 5,6 an 7 show the worldwide usage of these cameras. Single devices were discovered to be operated in locations we would not have expected. Additionally, two main spots of interest can be identified: Europe and the US. A closer look at the data gathered from the US shows smaller spots mapped to various cities. However, Europe turns out to be the most interesting location. The camera seems to be widely popular all over Germany and partially in Austria. We attribute this to the fact that the HiKam S6 camera model was sold during Summer 2020 at a German discount supermarket chain.

[1] Base map and data from OpenStreetMap and OpenStreetMap Foundation, © OpenStreetMap contributors. The map includes GeoLite2 data created by MaxMind, available from https://www.maxmind.com.

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