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.
Questions have arisen about the security of video surveillance cameras. Nozomi Networks Labs’ discovery of Reolink P2P vulnerabilities highlights IoT security risks.
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.
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
After we booted a Reolink camera NVR with UID enabled, we inspected the network traffic and knew the P2P feature was operating, as several UDP packets were exchanged with the host
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:
The Reolink P2P architecture and security set-up, as described by the vendor.
Click to enlarge.
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.
Reolink local traffic analyzed with Neolink dissector.
Click to enlarge.
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.
By analyzing the main NVR binary with 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.
Click to enlarge.
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:
[UDP] nvr:46469 -> p2p.reolink.com:9999
[UDP] p2p.reolink.com:9999 -> nvr:46469
[UDP] nvr:46469 -> p2p.reolink.com:58200
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.
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:
<dmap>tag) to the client.
<relay>tag). (Discussed more later in this article.)
[UDP] p2p_client:23878 -> p2p.reolink.com:58200
[UDP] p2p.reolink.com:58200 -> p2p_client:23878
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.
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.
[UDP] p2p_client:23878 -> nvr:48428
[UDP] nvr:48428 -> p2p_client:23878
sidvalue 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.
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
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.
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.
<xml version="1.0" encoding="UTF-8">
NVR cleartext username/passwords are sent to Reolink servers.
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.
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.
Rising IoT Botnets and Shifting Ransomware Escalate Enterprise Risk
Find out about:
The post New Reolink P2P Vulnerabilities Show IoT Security Camera Risks appeared first on Nozomi Networks.
This content was originally published here.
By Tim Cushing The Ring doorbell/camera has become a fixture of American life, thanks in part to Ring’s partnership…
Neos is a relatively new company to the smart home scene being established just four years ago. Targeting the UK…
Two weeks ago, Security Solutions provider Securex launched a new product for the market called Rafiki. It is a simple…
Share Great Content for Our Resource Section.
AutomateMyHome.com provides the latest news, information and product reviews in the world of Smart Homes and IoT. Our team carefully researches and reviews stories from around the web to provide you the best. Our community welcomes everyone to submit ideas.
Submit ideas to: firstname.lastname@example.org