Nozomi Networks Labs has discovered vulnerabilities in the Peer-to-Peer (P2P) feature of a commonly used line of security cameras – Reolink. Our research has resulted in a coordinated disclosure with ICS-CERT, which published advisory ICSA-21-019-02: Reolink P2P Cameras today.
Reolink’s cameras and NVRs (Network Video Recorders) are typically used by homeowners and small businesses, however they are relevant for critical infrastructure and industrial operators in two ways.
One, they may be in use at your facilities, including on your OT networks. Two, P2P is used by several camera vendors and, if your CCTV solution has this feature, it’s important to understand the potential risks.
This blog describes the journey we took to find these IoT security vulnerabilities, and presents technical details that are relevant for security teams and researchers.
Peer-to-Peer Functionality in IoT Security Cameras and Its Security Implications
Peer-to-Peer (P2P), in the context of security cameras, refers to functionality that allows a client to access audio/video streams transparently through the internet. The video data is available from the cameras or accessed through NVRs.
Rather than have a user explicitly configure a firewall to let a client reach the device with the video data, “P2P” establishes a connection through a set technique commonly defined by the umbrella term “hole punching”. The technical details vary between vendors and third-party providers of this functionality. However, the typical scenario involves an internet-reachable node which acts as a mediator between the client that wants to access the audio/video stream, and the device that serves the data.
In August 2020, security researcher Paul Marrapese1 published extensive research2 detailing security issues affecting the P2P implementations of some vendors. By exploiting these vulnerabilities, an attacker is able to intercept the audio/video stream at will.
What concerned us the most about Marrapese’s brilliant work was the sheer number of end users affected by the problems identified, and the lack of official documentation describing how P2P functionality works. By examining some devices we had in our lab, it became clear that the privacy and security implications of using a camera’s “P2P” feature are not clearly explained to users.
This realization led us to investigate the situation further. Our research goals are typically twofold. First, we want to protect industrial operators who might be unwittingly running P2P functionality in cameras on their OT networks or at their facilities. Second, we want to shed some light on the security level of P2P implementations and share our findings with the security community at large.
Reolink CCTV Camera P2P Overview
Beginning with a full set of Reolink CCTV cameras and the matching NVR, we began investigating whether P2P functionality was present in first place. As explained in the support section of the Reolink website,3 the term “UID” is used instead of P2P in the device user interface. After we booted an NVR with UID enabled, we inspected the network traffic and immediately realized that the P2P feature was operating, as several UDP packets were exchanged with the host p2p.reolink.com.
We must highlight that the scope of our assessment was limited to understanding how the audio/video stream was secured when traversing the internet. We exclusively recorded the traffic originating from Reolink devices in our lab, and analyzed how the devices and clients created and reproduced the streams. We did not perform any activity against Reolink servers or submit bogus traffic of any kind. The traffic that reached Reolink servers was always created by Reolink software.
The setup we used in our analysis mirrors the one described by the vendor in the description of the P2P architecture:
- A NVR is connected to security cameras through the same local network, and represents the P2P server that generates the audio/video stream.
- A “Reolink P2P server”, a server managed by the vendor, acts as a middleman allowing client and NVR to establish a connection.
- A software client, either a mobile or a desktop application, accesses the audio/video stream from the internet.
Before launching our investigation, we conducted background research to understand whether research on Reolink’s P2P implementation had already been done. We came across George Hilliard’s blog,4 in which he documents the proprietary protocol that Reolink devices and clients use within a local network. This provided an interesting place to begin.
By analyzing the local traffic with the dissector provided, we could easily navigate through the TCP streams. These carried the “signaling” portion of the proprietary protocol and the audio/video component. In particular, we noticed that signaling packets were obfuscated with a trivial 8 byte key. Armed with this knowledge, we turned our attention to the P2P traffic.
Communication between NVR and Reolink P2P server
We first exclusively analyzed the traffic exchanged between our NVR and the Reolink P2P server and immediately noticed some patterns in the UDP packets exchanged. This observation led us to think that an obfuscation strategy, like the one used in the local network protocol, could be employed for the traffic traversing the internet. By loading the NVR binary in charge of creating these packets in the disassembler, we located the functions responsible for network I/O. From there we found the code that performs the obfuscation using a hardcoded key.
The most obvious next step was crafting a small script that tried to reveal the UDP payload with the key we had just identified. What follows is the output obtained with the first three packets:
The first three packets of the UDP payload are revealed using a small script and the hardcoded key identified by our team.
Accessing the cleartext protocol was the first building block that allowed us to develop an understanding of the operations performed by the P2P server.
Communication Between the P2P client and the Reolink P2P Server
Once we established that we could access the cleartext communications between the NVR and the Reolink P2P server, it was time to bring a P2P client into the picture. There are several client applications available to choose from, both mobile and desktop. For the sake of the analysis, there’s no practical difference since they all use the same protocol.
We proceeded with the same methodology. By inspecting the deobfuscated communication between the client and Reolink server, we could extrapolate several things:
- The Reolink server gives the IP address / UDP port pair of the NVR server (<dmap> tag) to the client.
- The Reolink server also sends a sid value that is later used by the client to authenticate the NVR.
- The client acknowledges the IP address / UDP port of choice for the relay functionality to the Reolink server (<relay> tag). (Discussed more later in this article.)
The code above shows the Reolink server and the client communicating IP address and UDP port pair information, as well as the value used to authenticate with the NVR.
Communication Between the NVR and the P2P Client
With all the pieces in place, we could finally understand how the P2P client communicates with the NVR. The precondition for this to happen is obviously that the NVR has enrolled itself with the Reolink server, otherwise the client would promptly be informed about missing source audio/video data.
To our surprise, even the communication between the NVR and the P2P client was lacking any sort of secure key exchange. Rather, the same hardcoded key that we used thus far to reveal the network traffic was still effective. We could then analyze how the P2P client authenticates itself to the NVR, using the sid value that was given by the Reolink server.
The P2P client authenticates itself to the NVR using the same sid value that was given by the Reolink server.
Before replying to the P2P client, the NVR receives a notification of the upcoming client connection from the Reolink server through the cmap tag, which operates similarly to the dmap one that presented earlier. The P2P client is now authenticated with the NVR, and can start requesting audio/video streams.
CVE-2020-25169 – P2P video/audio lack of encryption and stream reconstruction
CWE-319: Cleartext Transmission of Sensitive Information reconstruction
We requested audio/video streams from the client to generate traffic for later analysis. The first noticeable variation for the packets carrying audio/video data, is the specific header magic, namely 0x2a87cf10.
The other obvious element that stood out was the presence of some cleartext “keywords” such as 01dcH264. This suggested that a secure encryption of the payload might be missing altogether. We proceeded to determine the remaining header fields to properly reconstruct the stream as seen by the client. Once finished, we could reproduce the audio/video content in cleartext.
The consequence of this design choice is that anybody who can access client/NVR traffic as it traverses the internet can access its audio/video payload—with no confidentiality for the parties involved.
In some situations, the connection between a client and the NVR is not stable enough. In these cases, the Reolink P2P implementation also allows for the P2P server to act as a relay node, effectively behaving as a man-in-the-middle.
Coupling the lack of an end-to-end encryption with the relay feature, de facto exposes the cleartext audio/video stream to the vendor.
CVE-2020-25173 – P2P protocol deobfuscation and credentials leak
CWE-321: Use of Hard-Coded Cryptographic Key
While investigating the protocol exchange between the Reolink P2P server and the NVR, we noticed another security issue. The vendor’s server also pulls the list of local users registered with the NVR, together with their corresponding cleartext passwords.
We struggle to understand the reason why the vendor wants to access this sort of information. The immediate consequence of this design is that an actor who can access this network traffic can fetch the local users’ credentials. Once they deobfuscate the protocol, as explained earlier, they can login into the NVR with a regular Reolink client.
NVR cleartext username/passwords are sent to Reolink servers.
Vendor Mitigation
Reolink has released a new version of the firmware, which according to them, mitigates the issues discussed in this post. Nevertheless, we suggest you carefully evaluate the potential risks involved with the P2P functionality before enabling it. We also suggest you consider alternatives such as VPNs, which provide stronger security, though more setup effort.
Reolink P2P Vulnerabilities Highlight IoT Security Camera Risks
IoT security cameras are extensively used by industry and the critical infrastructure sector. According to research firm Markets and Markets, the global video surveillance market size is expected to grow from US $45.5 billion in 2020 to US $74.6 billion by 2025. The infrastructure sector—including transportation, city surveillance, public places, and utilities, is expected to grow at the highest CAGR during that period.
Given their prevalence and growing use, it’s important to understand the security risks of IoT cameras. We urge you to take measures to prevent unauthorized access to audio/video streams and CCTV user credentials. Failure to do so could result in privacy, confidentiality, and business harms.
References
- https://twitter.com/PaulMarrapese
- “Security Cameras Vulnerable to Hijacking,” Hacked.camera.
- “How to Disable Remote Access/P2P on IP Cameras,” Reolink Support, December 2020.
- “Hacking Reolink Cameras for Fun and Profit,” George Hilliard, &> /dev/null Blog, May 16, 2020.
- “What Is IP Camera P2P & How Does a P2P Camera Work,” Reolink, November 4, 2020.
- “Wireshark dissector for the Baichuan/Reolink proprietary IP camera protocol,” George Hilliard, Github, November 30, 2020.
- “Video Surveillance Market,” Markets and Markets.
- “12/07/2020 Firmware for Reolink RLN4-410, RLN8-410, RLN8-410-E and RLN16-410 (H3MB02),” Reolink Support, January 4, 2020.
