The D-Link camera provides video recordings in a maximum HD resolution of 1280 x 800. Motion detection operates via a passive infrared sensor, and the camera also films in darkness per infrared LED illumination. A built-in microphone, along with the loudspeaker, enables two-way communication. These functions are also potentially available to attackers, however, as our test indicates.

Major deficiencies in the test category of encryption

During camera set up, the user is required to enter a password, which is then used for local administrator access. This is independent of cloud user access and corresponding password. For local access, however, there is a default unencrypted connection provided, and the use of an encrypted connection for access via browser is only optional. As a consequence, the password for local access, and thus local access itself, are inadequately protected at best.

When examining the online connections of the app and the camera with Wireshark, we initially see mainly encrypted connections with good, or at least decent, encryption. The good first impression, however, is deceptive, and as soon as these SSL connections are examined in terms of security, it quickly becomes apparent: Unfortunately, it is possible to hack these connections with very little effort. Thus, for example, the user login can be intercepted as a man in the middle and offers potential attackers access to the email and password hash of the user. The following illustration demonstrates this using a mitmproxy recording.

 

After the actual login, an exchange of device information finally takes place. In the process, along with the device ID, model, etc., surprisingly also the administrator password for local access is transmitted – also inadequately protected and prone to interception. The following illustration shows a POST example for this procedure.

Furthermore, the D-Link camera transmits various information over unencrypted connections via the Internet, including the firmware version, for example, but also the internal and external IP address.  In this, the data is encoded merely using Base64 and the binary data simply sent as text. The developers of the camera software, however, were probably aware that this would not stop attackers, and thus they use a type of XOR stream, i.e. a bit stream with the actual usage data linked through an exclusive OR designed to obfuscate the data stream. This does no good, however, as soon as the corresponding algorithm is known, the plain text data can be easily determined – security by obscurity in its pure form.

A look into the program code of the app indicates that vast areas are indeed cloaked with code obfuscation, in order to make analysis more difficult and to create barriers to entry into security relevant features. However, the app defeats this security mechanism itself and saves created screenshots, for example, unencrypted on the SD card. As a result, it is child’s play for attackers (and potentially any random app on the smartphone) to gain access to these images, i.e. via a malware app with which the smartphone of the user has been infected.

Unencrypted video stream

In addition to the HTTP connections already mentioned, there are other unsecured connections. They are used for the camera to stream the recorded video data. D-Link uploads the data via HTTP POST query onto the server, usually in 4 MiB blocks, whereas the corresponding app downloads everything in one download without a defined end. The data packets themselves are divided up into 1 KiB blocks, configured as depicted in the above illustration: Almost the same number each time initiates a 16-byte header. This is followed by the ID of the stream, and the footer is made up of data transmitted in this 1 KiB block. If there are less than 0x3F0 or 1,008 bytes, the block is filled at the end to a fixed length (padding).

With the help of this known data schema, images from intercepted streams in the direction of the app could be reconstructed and displayed using a self-written script. Therefore, it was possible to successfully eavesdrop on streams. This means that potentially anyone who puts in the time and effort can intercept image and video data being sent from the camera to the server and from the server to the app. Those who quickly log into a WLAN on the road thus give the WLAN operator and potentially other WLAN users the opportunity to also observe the stream.

Conclusion

In conclusion, the camera reveals few positive findings in the security test. A large part of the communication between the camera and the app, including the video stream, runs via unencrypted connections, which can even be intercepted on smartphone side. Therefore, we have no choice but to recommend that this camera not be used for remote access.