While the world, surprisingly for many, was in a state of emergency for another whole year, and of course we were not completely unscathed ourselves, testing, analysis and certification continued in our laboratory. But now that even this crazy year is coming to an end, we want to take the opportunity to look back at the tests of 2021: What is the status of the overall security level? What problems were we able to observe? And what is the trend? – are the questions we would like to answer from our point of view.

The following data is based only on the tests conducted in 2021. This year, more than 20 systems mainly from the areas of smart locks, IP cameras, smart home and alarm systems were subjected to our security or even certification tests. Among others and besides some internal tests, the following products were tested this year:

  • Bosch Smart Home
  • Nuki 2.0 und 3.0
  • Telekom Magenta Smart Home
  • eufyCam 2C
  • Somfy Door Keeper & TaHoma V2
  • eQ-3 Homematic IP
  • Prowise Touchscreen
  • Cosori CS158-AF

As always, our tests were divided into the 4 major test areas of application security, online communication, local communication and data protection, and we would like to discuss the individual test areas here in the same order.

Application Security

If the tested product is not directly a mobile application itself, then a mobile application is always at least part of the IoT system in question. At least this is the case with all the products we tested this year. The mobile applications are used to perform setups, remote control and device configurations. Naturally, they are therefore essential for any IoT product from a security point of view and thus also receive a great deal of attention in our tests. In the first step, we primarily examine statically whether potential problems can be identified in the implementation of the app. These can be serious, for example, such as hard-coded secrets, or are more in the area of “misconfiguration”, which can sometimes also cause critical problems, but are usually very easy to fix or only have theoretical implications in a given application scenario. It is important to note here that we exclude problems concerning local or online communication for this evaluation point and outsource them to the corresponding test categories because they are usually a combination of vulnerabilities in the app and the device (or the manufacturer’s cloud).

Overall, the security level of the apps tested this year was generally quite high. We actually did not have a single app combination (of Android & iOS app) that did not have at least minor problems, but the number of really serious problems was comparatively low. Only about 10% of the apps we looked at had issues that had to be rated as at least medium severity, and only half of those had issues with critical consequences for system security.

What we typically see here, are errors in configurations regarding network security. Although both Android as well as iOS provide options that allow for system sided blocking of unsecured Internet communication of the app (usually just a corresponding flag that has to be set) – you can hardly keep your app “secure by default” in a simpler way – Many developers make their lives far more complicated than necessary to accomplish the same “manually”.

Other classic problems in this area go in a similar direction: Missing activation of memory access mechanisms (such as ASLR) for libraries used, incorrectly or unnecessarily broadly set options to share app content with other apps (via so-called intents) or the use of potentially insecure method calls that can (under certain circumstances) be exploited for buffer overflows and similar attacks – all of which are more in the theoretical realm and therefore usually rated as less severe in our reviews.

Online Communication

The Super-GAU for any IoT system is a vulnerability that can be exploited remotely via the Internet and allows attackers to launch attacks without physical proximity. Investigating precisely this possibility is the main focus of this test area, and potential vulnerabilities are assessed here with corresponding severity. We mainly examine the communication between the device, application and cloud, but also analyze the device itself for open ports or active and/or outdated protocols that could be used to launch attacks or obtain information.

The results in this area have always been rather mixed in recent years, and this did not really change in 2021 either: 15% of all tested products had serious problems in this area, and a full 55% had at least minor problems that were not necessarily rated as critical, but at least potentially provided attack surface. On a positive note, however, 30% of the tested products did not have any obvious weaknesses in this area and could be rated as adequately secure by us right away. Another positive aspect is the fact that manufacturers were successfully informed and appropriate countermeasures were taken for all products that were found to have critical vulnerabilities. In all cases, the manufacturers also responded extremely gratefully to our information – a trend that we can only welcome. A few years ago, we experienced this very differently in some cases.

The classic problems we have encountered in this area relate, as they always have, to the encryption of communications. Although the proportion of products that do not use encryption at all is steadily decreasing – in fact, this year we did not have a single product in the test that did not use encryption at all – this is still where the biggest problems lie. Using encryption is relatively easy, but using it correctly is more difficult: An encrypted connection via HTTPS/TLS is not automatically completely secure just because it uses these protocols. Certain points still need to be considered so that these protocols can really provide their full security, and the most important point is certificates. Here we can often observe in practice that the certificate validation, which must take place when the connection is established in order to be able to verify the identity of the server, at least for the client, is not always implemented correctly. The consequence is that the client (the device or the mobile application) cannot verify whether it is actually communicating with the desired host (vendor server/cloud) at a given time. The result is vulnerability to man-in-the-middle attacks and the ability to break or bypass encrypted connections without the user noticing. With the so extracted critical data, an attacker can gain full access to user accounts in the worst case.

A second serious problem we often observe is the use of weak encryption. This is usually encryption that the manufacturer has developed themselves because it was either cheaper, easier, or both than using existing protocols. In practice, however, these self-developed encryption protocols usually turn out to be weak and buggy – which is no wonder at all. Existing encryption protocols such as TLS have been peer-reviewed thousands of times, improved in countless versions, and are still never completely secure. A single IoT manufacturer, at the first attempt, has no chance of landing an infallible hit right away. The result is an algorithm that is easy to break with the right knowledge and, again, inadequately protected access to critical data.

Local Communication

There are then two aspects to consider for the test area of local communication: Firstly, the network communication of the device and the mobile applications is again considered (but only among each other in the same network) and secondly any other short-range radio communication (mainly Bluetooth). A vulnerability in this test area usually turns out to be less severe, since the attack scenario (attacker must be on site and/or already have access to the network) is simply less relevant in practice. Nevertheless, depending on the application scenario, certain vulnerabilities can have serious consequences here as well.

In this year’s tests, this test area presented itself quite positively: 40% of the products tested had no immediately recognizable weaknesses in this area at all. A further 30% had deficiencies of lower to medium severity, but due to the existing application scenarios and the resulting threats, the practical danger here was also kept to a very manageable level. Only 10% of the systems tested had to be certified as having a vulnerability with a serious impact. For the remaining 20%, local communication was not the focus of the investigation or simply did not exist.

The problems that we are increasingly seeing here are naturally very similar to those in online communication. As already mentioned, however, such problems usually have much less severe consequences at the LAN level. Nevertheless, we never get tired of explaining to manufacturers that there must be adequate protection here as well – just one compromised other device on the network and all other vulnerable device on the same network run the risk of being the next target.

As far as Bluetooth communication is concerned, the observed problems are usually also linked to a rather careless handling of the underlying protocol, which does not implement any security mechanisms by default and therefore has to be extended and secured independently by the manufacturer for his solution. Unfortunately, this does not always happen with full consistency. Typical problems here are the possibility of DoS attacks, which even if the attacker cannot directly control anything with such an attack, he can at least disrupt the control by the legitimate user. For a typical Bluetooth device, such as a smart lock, this can be more than just annoying. Apart from that, Bluetooth communication must also be encrypted to provide a sufficient level of security, and thus familiar problems, such as self-developed and buggy encryption, have an appearance again.

Privacy and Data Protection

The area that has been coming to the fore for years now, and is consequently also having a greater impact on our testing this year, is of course privacy and data protection. With each passing year, we can see how IoT devices are further expanding their already extensive data collection capabilities. As long as the user is fully informed about this and is thus given the opportunity to deliberately decide to use a particular product with all its privacy implications, this alone is not a problem. The problem only appears, if there is not enough informationen given to allow for an educated decision.

In order to be able to make a well-founded statement on this question, we first examine the basic data collection capabilities of a product. What sensors are installed? Are trackers integrated into the apps? If so, what can these trackers do and what are they used for? Is data being collected in operation that obviously wouldn’t need to be collected for actual functionality? etc. We then look at the privacy policy that comes with the product, compare our findings with the information provided there, and make our assessment based on that.

Although the topic of privacy and data protection has become more important, especially in recent years, it is still a rather problematic issue. This year, we only had one product in our tests where our testers really had nothing to complain about at all. This contrasts with the 75% share of products where we had at least minor to medium points to complain about. For the rest, we even identified quite severe problems. The reason for this is certainly the still (relatively) young GDPR and the resulting increased requirements, to which not all manufacturers have been able to adapt. On the other hand, however, the topic is often not yet given enough attention.

The biggest and most frequent problem in this area is in most cases simply missing and/or incomplete information – in varying degrees of severity. Here, we rate particularly hard when information on data collection, processing and storage is missing, and even more so when we could clearly observe data being collected during operation. Information about integrated tracking modules, which are nowadays included in virtually every app and bring far-reaching capabilities for user analysis, is also often missing – rarely with the intention to conceal evil doings. Often it is simply forgotten and just as often the developer was not aware at all of the additional “functionality” he was adding to his app via the integration of specific trackers and SDKs. Overall, we see a thoroughly positive trend in this area, even if it still reveals problems relatively often – a few years ago, the whole thing looked a lot more dubious.

Bottom Line

Even though not all security problems in the IoT world have been solved this year (as expected), from our point of view we can say that despite all the vulnerabilities and security gaps that have been identified, the general level of security continues to increase. We still see vulnerabilities and weak points that are quite unnecessary by today’s standards, but on the whole we were given a fairly optimistic picture this year. Admittedly, our tests this year were more in the qualitative area of the IoT and therefore we were certainly spared a bit of the really black sheep in the product range – perhaps an impulse for us to keep a closer eye out for these products again next year. In any case, we will be testing and certifying again!

We wish everyone a Merry Christmas, relaxing holidays and a happy new (hopefully more normal) year 2022!