HiKam S6 WiFi IP Camera – Quality at ALDI price?

IP cameras are still one of the best selling gadgets for the home. Accordingly, the range of products for this segment continues to be virtually endless. It is therefore hardly surprising that large discounters are constantly adding solutions to their range.

The HiKam S6 WLAN IP camera is a typical example of such a product, which in this case is sold in large quantities and at low prices by the discount giant ALDI. The fact that these products are often of a high standard in terms of feature list and quality is no longer a rarity, but whether they are also convincing in terms of security is something we have checked in our quick check.

Features

The HiKam S6 actually offers everything that a device must offer as standard in this category in order to be prepared for the most varied application scenarios of an IP camera. It delivers a 720p HD video stream with infrared night vision, has 2-way audio communication, i.e. integrated microphone and loudspeaker as well as Alexa support, and also offers configurable motion and person detection. Communication is performed via WLAN, so that the camera can also be placed easily and flexibly. The recorded video data can then be stored on the included cloud storage or stored locally on SD card or NAS. All in all, a well-equipped IP camera is offered here, especially at this price.

Mobile Applications

The mobile applications for the HiKam S6 (Android: com.hikam.pro v5.0.20; iOS: HIInfinity.HiKam-Pro v1.1.1) did not reveal any serious problems in the static analysis, even if here and there a few points are still noticeable.

It is almost surprising that only three trackers can be detected that have an entry in the Exodus Privacy Database. The two Google trackers (Firebase Analytics and AdMob) are almost standard nowadays and, furthermore, do not reveal any real weak points. The third module from Bugly (officially also intended for bug reporting) is less common and almost exclusively found on devices of Chinese origin. During the operation of the HiKam S6 we could observe relatively regular traffic between the app and the Bugly servers. However, only small amounts of data were transmitted, unencrypted via HTTP, but not in plain text.

When analyzing the Android manifest, it is noticeable that almost 80 activities (basically individual app functions that are usually presented to the user via dedicated screens; in this case virtually the entire app functionality) can all be exported, i.e. they can be requested and executed by other applications, but are not protected by corresponding permissions. Usually, a developer only allows this if certain functions of an app, such as image acquisition or processing functions, should also be accessible to other apps. The fact that an application does this with almost all of its functionality makes little sense and we have not seen this anywhere else yet. Apart from that, this practice also brings with it security problems. Here the developer should definitely check if and to what extent this is necessary, useful and desired.

Apart from that, the static analysis did not identify any real critical weak points: The iOS app  in some places uses insecure API, which can lead to memory problems if used incorrectly. However, all important protection mechanisms for memory access (i.e. ASLR, ARC and SSP) are activated, so that we can only speak of a theoretical threat at best. In addition, the ATS (App Transport Security) restrictions are not set, which means that the app may communicate unencrypted via HTTP, for example, and encrypted without requirements for a minimum TLS version, cipher and so on. Since some modules, such as the bugly module mentioned above, communicate via HTTP and also large parts of the app communication run over the standard unencrypted UDP protocol, this is not surprising and on its own not critical.

Local and online communication

However, for the communication in the local network and via the Internet, we noticed some things during the test that should not be underestimated in their severity.

In the local network, i.e. when the smartphone with the running application and camera are in the same network, the communication is almost completely unencrypted. Although local access is protected by authentication on the camera side, the login name is set to “admin” and the password is transmitted unencrypted, as the following network recording shows.

The actual video stream then runs via the standard unencrypted UDP protocol, but the payload, i.e. the actual video data, appears to be additionally encrypted. However, with local access to the camera, the attacker has already won at this point anyway due to insufficient authentication. In addition, there are additional weaknesses of the local web server on the camera, but these are actually of no consequence, since they are harder to exploit than an attack on the insecure authentication itself.

Depending on the application scenario, it may be possible to condone unsecured local communication (but certification according to our standard would not be possible under any circumstances), but if communication via the Internet also has more serious weaknesses, the whole thing indeed becomes critical.

Let’s start on the positive side first: Over the Internet, the actual video stream seems to be via UDP as well, but with additionally encrypted payload. But, to go directly to the negative, the authentication and the handling of the account login information cannot be considered secure as well too.

For example, the password for local camera access is also transmitted online in plain text (see following image). But since this is really only for local access, you can almost ignore it at this point. But it is not an exactly elegant solution, to say the least.

If you look at the account login, everything looks fine at first glance – an encrypted connection (TLS in version 1.2) is established and the data is transferred with adequate security. But if you take a closer look at the network recording of the process, you will notice that there is also communication done via UDP (which is used for other purposes besides the actual video transmission). This way the account name (email address) and the password are also transmitted, e.g. when changing the account password as show in following image. As one can see, the account name is transmitted in plain text, the corresponding password as MD5 hash.

If the password is sufficiently long, unique and complex (over 12 characters, lower/upper case, numbers, special characters), this should not be a problem in itself. In reality, weak passwords (the app only requires a minimum of 6 characters) are more common than strong passwords, and then using outdated and no longer sufficiently secure hashing algorithms, like MD5, in combination with unencrypted transmission becomes a problem. In addition, there is also a lack of brute force protection for the login process, so an attacker has potentially infinite number of guessing attempts without being hindered.

During the analysis within the scope of our quick check, we also noticed further plain text transmissions of various URLs, tokens and keys, which we have not yet further checked in the limited time frame. However, we are relatively sure that we would encounter more problems if we only dig deep enough.

Data protection and privacy

In this area, on the other hand, the HiKam solution left a quite positive impression on our testers: The privacy policy (as of 20.05.2018) of the Hikam Pro App provides very comprehensive, detailed and transparent information on all important topics such as data collection, processing and storage. According to this, these are realized by High Infinity Technology GmbH, Germany, which stores and processes all data within the European Economic Area.

Almost standard is the formulation to present oneself only as a contract processor for video and audio recordings for the customer, according to which the customer alone is responsible for informing all persons filmed by the camera about the data processing. Sounds like shifting responsibility to the customer, but under current law it is difficult for manufacturers to find another solution. All other (meta-)data collected is processed by the provider as the entity responsible. Although the recorded video data itself may be stored by other service providers according to the privacy policy, but always encrypted. The right to use additionally recorded data, e.g. on user behaviour and app usage, for product and service improvement is also assured, but also rather standard nowadays.

Verdict

The HiKam S6 offers an absolutely solid package in terms of features for the estimated price: the feature list is long, the configuration options are extensive and operation is uncomplicated. From a security point of view, however, too many smaller and above all larger weak points are too obvious in the test for us to be able to make a recommendation. The problems especially in the area of communication cost the camera too many points for a good rating. The fact that it does not afford to have any serious weak points in the area of application security and that the topic of data protection is obviously taken fairly seriously, barely saves it one star out of three possible.