Today we announced the discovery and responsible disclosure of a new security camera vulnerability, the latest in a series of Nozomi Networks research discoveries regarding IoT security.
This particular vulnerability affects a software component from a company called ThroughTek. The component is part of the supply chain for many original equipment manufacturers (OEMs) of consumer-grade security cameras and IoT devices. ThroughTek states that its solution is used by several million connected devices.1
ThroughTek’s P2P Software Development Kit (SDK) is used to provide remote access to audio/video streams over the internet. P2P is used by multiple camera vendors and today’s disclosure is another reason to check whether your CCTV solution has this feature.
The risk of using vulnerable cameras is unauthorized access to confidential audio/video camera feeds. For critical infrastructure operators, this could reveal sensitive business, production and employee information.
In this article we describe the ThroughTek vulnerability, the difficulties in evaluating the risks of security camera systems, and why we’re optimistic about better software security in the future.
P2P Functionality for IoT Security Cameras
Before delving into our new findings, let’s recall our earlier discovery regarding the P2P implementation of Reolink security cameras. When we talk about P2P in the context of security cameras, we refer to functionality that allows a client to access audio/video streams through the internet.
Our blog on Reolink explains and shows the following three components of a typical P2P architecture:
- A NVR, which is connected to security cameras and represents the local P2P server that generates the audio/video stream.
- An offsite P2P server, managed by the camera vendor or P2P SDK vendor. This server acts as a middleman, allowing the client and NVR to establish a connection to each other.
- A software client, either a mobile or a desktop application, that accesses the audio/video stream from the internet.
While Reolink develops its own P2P functionality, many security camera and IoT device manufacturers source it from third-party providers like ThroughTek. A peculiarity of P2P SDKs, though, is that OEMs are not just licensing a P2P software library. They also receive infrastructure services (the offsite P2P server) for authenticating clients and servers and handling the audio/video stream.
ThroughTek’s website shows its technology being used by OEMs that manufacture IP cameras, baby and pet monitoring cameras, and robotic and battery devices.1
Keeping this in mind, let’s now look into details of the ThroughTek vulnerability.
Discovering the ThroughTek P2P SDK Vulnerability
At Nozomi Networks we have a continuous pipeline of devices that enter our lab environment, from PLC to IoT to medical devices. When we receive a new device, one of the first activities we do is analyze its network traffic.
Our lab recently received an NVR and our team quickly determined that it has P2P functionality. We then analyzed the network traffic generated by a Windows client connecting to the NVR through P2P. We noticed several packets connecting to iotcplatform.com, the domain name accessed by clients of ThroughTek’s P2P platform.
We then started investigating the client implementation, soon realizing that it comes embedded with different sets of P2P libraries. The software client is essentially a white-label product, and for this very reason it needs to provide full interoperability with several P2P vendors.
After setting a few breakpoints in the right spots, we managed to identify interesting code where the network’s packet payload is deobfuscated. We later parsed the code to understand which type of commands it contained.
We use the word “deobfuscated” to signify that the protocol lacks a secure key exchange and relies instead it on an obfuscation scheme based on a fixed key.
The consequences of the vulnerabilities of both Reolink and ThroughTek are similar: since this traffic traverses the internet, an attacker that is able to access it can reconstruct the audio/video stream.
The following is a proof-of-concept script we developed, which deobfuscates on-the-fly packets from the network traffic. The string starting with XYEU is the UID that uniquely identifies a device in the P2P network.
We responsibly disclosed this vulnerability in March 2021 and ThroughTek promptly acknowledged the problem. The company also proceeded to notify its customers and committed to fixing the vulnerability by adding a “layer of encryption based on DTLS ECDSA-PSK.” ThroughTek’s webpage addressing the SDK vulnerability advises customers to enable security functionality or upgrade to a current version.
ICSA-21-166-01 was eventually assigned to track this vulnerability, with a CVSS v3 base score of 9.1 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N).
Evaluating the Risks of This Vulnerability Is Difficult
Because ThroughTek’s P2P library has been integrated by multiple vendors into many different devices over the years, it’s virtually impossible for a third party to track the affected products. The threat model under which this type of vulnerability is exploitable, is the limiting factor for its actual impact.
In essence, any actor that can access the network traffic between the NVR and the end user, including the P2P third-party server provider in some scenarios, could access and view confidential audio/video streams.
The DLL that implements the P2P protocol has an export called IOTC_Get_Version which, as the name says, returns the internal version number. In the screenshot below, we see version number 3.1.4.35, which is the version used by the client we first analyzed. This specific version is quite old and uses a hardcoded key also found in other P2P implementations.
While doing further research we stumbled upon more recent versions of the library, with a different obfuscation scheme and a different set of parameters. We could not perform a dynamic analysis of those libraries because finding a device running the newer version of the protocol proved to be a bigger challenge than finding the vulnerability.
In summary, while ThroughTek states its software is used by millions of devices, and P2P functionality is widespread amongst vendors, it is difficult to evaluate the risk of a particular security camera.
Evaluating Security Cameras with P2P Is Also Difficult
Generally, when a buyer looks at the technical details of various security cameras, they are unable to identify the P2P provider or find a proper description of the protocol. In our experience, the best and only way to get this information is to look directly at the client/server implementation. Unfortunately, most buyers do not have the skills or inclination to do this.
Therefore, the best way to prevent captured audio/video content from being viewed by strangers over the internet is to disable P2P functionality.
We recommend that users only enable P2P in the rare situations where the vendor can provide a thorough technical explanation of why the algorithms used in their products are secure.
Further considerations include assessing the security and privacy policies of both the camera vendor and the jurisdiction in which the vendor is located.
In other words, don’t take a chance on viewing camera feeds over the internet, unless you have done thorough technical due diligence and feel comfortable with the vendor’s security and privacy practices.
Hope for More Secure Software Supply Chains
The post-SolarWinds world has the increased awareness level of software supply chain risks. The U.S. Federal Government, one of the world’s largest buyers, will soon be requiring its suppliers to provide a Software Bill of Materials (SBOM) for the solutions it purchases. This requirement is also being implemented by more and more commercial purchasers, and, over time, will raise the security bar for all software.
In the meantime, security camera purchases, especially by critical infrastructure organizations, should receive careful security and vendor evaluation.
For specific mitigations for the ThroughTek vulnerabilities and recommended control systems security best practices, see the ICS-CERT Advisory.
References:
