The camera from Gigaset records its environment in a picture quality of 720p with a frame rate of up to 30 FPS. Thanks to night vision mode, it even works at low light intensity.

Outdated encryption

In order to transmit the video stream, the camera and app establish encrypted connections to the servers of the manufacturer Gigaset. If an attempt is made to intercept the connections as part of a man-in-the-middle attack, e.g. with mitmproxy, the connections are shut down, which prevents interception in most cases. The following illustration shows an excerpt from Wireshark. We see that the connection is protected with TLS 1.2 and a sufficiently secured encryption method (see below), and our man-in-the-middle attack is rejected due to an invalid certificate.

With the installed root certificate on the user smartphone, it was indeed possible to hack this connection also by means of a man-the-middle attack. The following illustration shows the intercepted login data in mitmproxy. This demonstrates that the security level of the application really could be additionally improved, but in practical terms, the installation of an own root certificate on an Android smartphone by an attacker cannot be readily carried out, and therefore does not lead to downgrading.

While the connection between the app and the server is still sufficiently encrypted, the connection between the camera and the server is another story entirely: Here RC4 encryption is used, which is outdated and considered practically broken. Already in February 2015, the use of this stream encryption was forbidden in the encryption protocol TLS (RFC 7465) for security reasons. The fact that this outdated and unsecure encryption is still used to transmit data of the Gigaset camera does not speak for the security of the product.

Data unprotected on SD Card

But there was another category in which the security camera failed to make a good impression in the quick test: Although the data transmission of the deployed Android app is still in good shape, there are issues concerning the self-protection of the app: The fact that it does not contain sufficient obfuscation of the program code makes it easier for attackers to analyze potential vulnerabilities. But even worse. The app saves downloaded videos unencrypted on the SD card of the smartphone. In this, the storage location is not apparent to users of the app, as there is no corresponding message. Thus, danger exists that videos can be spied on by malware apps of attackers by extracting the videos from SD card.

An additional, at least theoretical vulnerability is found in the connection secured via SSL, over which the camera streams video data: No authentication is necessary for viewing and downloading the recordings. If you enter the corresponding URL into the VLC player, for instance, the program can play it directly. While the attackers are required to know the URL, this can be found out. The bare-bones configuration is as follows: https://gigaset.y-cam.com/vods3/_definst_/mp4:amazons3/ycam-[Chain1]-[year/month]/[MAC]_[Date/time]_[chain2].mp4/playlist.m3u8. Character string 1 was always the same in our tests, and finding out the MAC address of the camera is in the realm of an attackers possibilities. If necessary, the year-month combination contained in the URL can simply be tried out. Character string 2, by contrast, appears to be assigned at random, and the specification of date and time down to the second would probably present difficulties for attackers without inside view. In our test, the available recordings were determined via api.gigaset-elements.de. The queries contained a “user token”, which was sent to the app after successful login. Attacks on the live stream of the camera could also be carried out via the following URL: https://gigaset.y-cam.com/live/[MAC]_[Zeichenkette].stream/playlist.m3u8.

Unencrypted server communication

Moreover, we examined the connections between the camera and the server more carefully. The encrypted connections and their problems were indicated earlier. Yet there are even more connections that are transmitted at least partially unencrypted. In order for the images of the camera to be viewed on the smartphone, they must first run through the server of the manufacturer. Because there is no local access, this also applies even if the user and the camera are in the same network. In the process, the camera establishes several connections to the address cam-dx.gigaset-elements.com, which is part of the Amazon Cloud. One of the connections is unencrypted and consists almost exclusively of “KEEPALIVE”, which the camera sends to the server. In doing so, the camera transmits the MAC and internal IP address.

An additional connection via real-time streaming protocol (RTSP) is at least partially unencrypted. There is an initial communication of data, e.g. the configurations of the live stream, and therefore the resolution and codec used. This occurs in plain text, and attackers could intercept this data. The following illustration shows an excerpt from transmission: Internal IP, parameters for the video transmission (resolution and codec) as well as an authorization token are transmitted, among other things – potentially useful information for an attacker.

This is followed by binary data; based on the volume and the time sequence, it contains the actual stream or transmission of video and sound. During our tests, despite several indications, we were, however, unable to determine that it actually contained unencrypted video stream data. That is why the camera was also not downgraded in this test category.

Conclusion

The Android app saves downloaded videos unencrypted in freely accessible locations on the smartphone. The encryption selected by the manufacturer for camera streams is outdated and unsafe, what’s more, the camera partially communicates unencrypted, which is why status information, but also individual images, can be intercepted. While it is more complex for attackers to intercept connections between the devices at home and the manufacturer’s servers than between the app and servers in a public WLAN, such attacks are still possible. All in all, this means we are unable to give a high rating to the product.