(Editor’s note: contributed blogs like this are part of ChannelBuzz.ca’s annual sponsorship program. Find out more here. This article was originally posted to the ESET site We Live Security by ESET Malware Researchers Milan Fránik and Miloš Čermák.)
Many people are looking to improve the security of their homes or offices by installing “smart” cameras. With a direct connection to the internet, their surveillance stream is just a few clicks away and available at any time. Yet, this kind of convenience can quickly turn sour if the camera suffers from a security vulnerability that opens the door to unauthorized actors. As shown by ESET smart home research, this is the case with the D-Link DCS-2132L cloud camera, which allows attackers to not only intercept and view the recorded video, but also to manipulate the device’s firmware.
The most serious issue with the D-Link DCS-2132L cloud camera is the unencrypted transmission of the video stream. It runs unencrypted over both connections – between the camera and the cloud and between the cloud and the client-side viewer app – providing fertile ground for man-in-the-middle (MitM) attacks and allowing intruders to spy on victims’ video streams.
Figure 1 – Scheme picturing the vulnerable data transmission and possible MitM attack vectors
The viewer app and the camera communicate via a proxy server on port 2048, using a TCP tunnel based on a custom D-Link tunneling protocol. Unfortunately, only part of the traffic running through these tunnels is encrypted, leaving some of the most sensitive contents – such as the requests for camera IP and MAC addresses, version information, video and audio streams, and extensive camera info – without encryption.
The vulnerability responsible for this and some of the issues described later in this blogpost can be traced to a condition within the request.c file (part of the D-Link customized open source Boa web server source code) that handles HTTP requests to the camera. All HTTP requests from 127.0.0.1 are elevated to the admin level, granting a potential attacker full access to the device.
Figure 2 – Condition in the boa web server source code. All incoming requests are elevated to admin
Intercepting video and audio streams
A MitM attacker intercepting network traffic between the viewer app and the cloud or between the cloud and the camera, can use the data stream of the TCP connection on the server (cloud) port 2048 to see the HTTP requests for the video and audio packets. These can then be reconstructed and replayed by the attacker, at any time, to obtain the current audio or video stream from that camera. In our experiments, we obtained the streamed video content in two raw formats, specifically M-JPEG and H.264.
To reconstruct the video stream, one needs to take a few steps (which can be easily automated via a simple program or a script):
- Identify the traffic that represents video streams. This traffic consists of multiple blocks of data, each block having a specific header and defined length.
- Separate the data parts from the headers.
- Finally, the parts of the video are merged into one file.
Playing the video files obtained this way can be a little tricky as they are in a raw streaming format instead of a container file format. However, some media players can handle these raw formats if run with the appropriate command line switches (for example, MPlayer can handle M-JPEG files and VLC can play H.264 files).
Flawed plug-in
Another serious issue found in the camera was hidden in the “mydlink services” web browser plug-in. This is one of the forms of the viewer app available to the user, others being mobile apps that were not part of our research.
The web browser plug-in manages the creation of the TCP tunnel and the live video playback in the client’s browser but is also responsible for forwarding requests for the video and audio data streams through a tunnel, which listens on a dynamically generated port on localhost.
The tunnel is made available for the whole operating system, so any application or user on the client’s computer can simply access the camera’s web interface by a simple request (only during the live video streaming) to hxxp://127.0.0.1:RANDOM_PORT/.
No authorization is needed since the HTTP requests to the camera’s webserver are automatically elevated to admin level when accessing it from a localhost IP (viewer app’s localhost is tunneled to camera localhost).
This vulnerability also allows any attackers to replace the legitimate firmware with their own rigged or backdoored version.
The video below gives a handy demonstration of the now-fixed security issue with the plug-in:
Illicit firmware replacement
At the time of writing, issues with the “mydlink services” plug-in have been successfully fixed by the manufacturer.
However, the malicious firmware replacement is still possible via vulnerabilities in the custom D-Link tunneling protocol described earlier in this blogpost. To achieve this, an attacker needs to modify the traffic in the tunnel by replacing the video stream GET request with a specific POST request that uploads and runs a bogus firmware “update”.
We need to stress at this point that performing such an attack is non-trivial, as it would have to follow all the rules of the tunneling protocol, dividing the firmware file into blocks with specific headers and of a certain maximum length.
However, the authenticity of the firmware binary is not verified during the update process. A customized firmware with some additional “hidden” features like cryptocurrency miners, backdoors, spying software, botnets or other trojans could thus be uploaded to the device. Further, the lack of any authenticity checks means that a malicious actor could deliberately “brick” the device.
UPnP exposing HTTP port to the internet
D-Link DCS-2132L also had a few other minor, yet still concerning, issues. It can set port forwarding to itself on a home router, by using Universal Plug and Play (UPnP). This exposes its HTTP interface on port 80 to the internet and can happen without the user’s consent even with the “Enable UPnP presentation” or “Enable UPnP port forwarding” fields in the settings unchecked.
Why the camera uses such a hazardous setting is unclear. Currently close to 1,600 D-Link DCS-2132L cameras with exposed port 80 can be found via Shodan, most of them in the United States, Russia and Australia.
Figure 3 – Results of Shodan search of DCS-2132L on port 80
The simplest way to mitigate this current risk is to disable UPnP on the user’s router.
Plugin fixed, other issues persist
As a part of responsible disclosure, ESET reported the discovered issues to D-Link on 22nd August 2018, including vulnerable unencrypted cloud communication, insufficient cloud message authentication and unencrypted LAN communication.
D-Link responded immediately, informing ESET that the vulnerability reports had been forwarded to their research and development teams, promising follow-up.
Since then, some of the vulnerabilities have been mitigated – according to our tests, the “mydlink services” plug-in is now properly secured – although other issues persist. At the time of writing the most recent version of firmware available for download was from November 2016 and did not address the vulnerabilities allowing malicious replacement of the camera’s firmware, as well as interception of audio and video streams.
D-Link DCS-2132L camera is still available on the market. Current owners of the device are advised to check that port 80 isn’t exposed to the public internet and reconsider the use of remote access if the camera is monitoring highly sensitive areas of their household or company.
