As part of our Quick Check tests, we have repeatedly looked at gadgets and solutions in the past that were rather in the low-price segment and thus also suggested rather small security budgets. As expected, we often found what we were looking for when it came to identifying sometimes serious security vulnerabilities. In the future, we plan to test more in this area again, so that we do not lose sight of the supposedly “darker” side of the Internet of Things in contrast to the high-security products examined in our certification tests and thus retain a more representative impression of the overall situation.
As one of the first candidates, we chose the Nooie Cam 360 from the Chinese manufacturer Shenzhen Apeman Innovation Science & Technology – a popular, frequently sold IP camera with a comparatively low price and wide distribution. Whether it confirmed our expectations in a negative way or even surprised us in a positive way is clarified in the following test report.
In terms of features, the Nooie Cam 360 offers everything you can expect in this category and at the suggested price of under 50€: The video recording happens in 1080P and this with the help of the built-in 940nm infrared LEDs even in complete darkness up to 10m away. In addition, the camera has 2-way audio, motion and noise detection and can be rotated or tilted almost completely by 355° horizontally and 94° vertically. As usual, the camera is set up, managed and controlled via a mobile app for Android and iOS (“Nooie”; com.nooie.home). In addition, the status light, which indicates an active recording, can optionally be turned off (why you would want to do that remains to be seen).
The applications belonging to the device (tested versions 2.2.1 for Android and 2.3.0 for iOS) were, as usual in our tests, sent through a static analysis in the first step and did not show any serious problems at first. As expected for the camera’s range of functions, the Android application requests all permissions (37 in total) that are necessary for localization, audio, Bluetooth, etc. – but also permissions to change system settings or download additional functions without notifying the user. That alone already suggests a quite extensive data collection independent from the functionality actually provided. We will come back to this point later.
Another indication for a possible vulnerability regarding unsecured storage of personal data locally is the authorization to access the external storage, i.e. the SD card. If data is actually stored there, it can also be accessed by all other apps installed on the smartphone. However, no real threat could be identified here. The app does store the screenshots taken from the camera stream on the SD card, but Android’s screenshot function would not solve this differently. Critical data, such as account data, keys or similar, could only be found in the protected app area, to which only the Nooie app itself has exclusive access – at least on non-rooted smartphones.
The analysis of the Android manifest basically only shows standard problems: A large number of services, receivers and activities are potentially vulnerable to being accessible to other apps as well, which could lead to unintentional data leakage. In addition, the application is configured to allow unencrypted communications by default – not a sure proof of a security problem, but at least an indication already.
In addition, several trackers and analysis modules can be identified in the app code. Among them are Google Firebase, Firebase Analytics, Firebase Data Transport and Google Mobile Services. Thus, a quite extensive collection and analysis of data is possible in any case.
The situation is quite similar for the iOS application, albeit due to the more restrictive nature of iOS with fewer permissions and without data collection via Google services of course. However, a configuration that allows unencrypted communication via the Internet is especially noticeable here also.
Local and online communication
As mentioned in the previous section, the static analysis pointed out some potential weaknesses in this area. This was further investigated through the practical analysis of the concrete, observable communication of the device and mobile application.
Basically, the communication here is structured as in many other representatives of the product category as well: Authentication and account management are carried out via a TLS connection in order to then run control and camera stream via connectionless UDP. Basically, there is no conceptual problem with this, as long as the TLS connection is adequately implemented and secured, and the payload, i.e. the actual transmitted image and audio data of the UDP stream, is additionally encrypted. The UDP protocol does not offer this option by default, so here the manufacturer has to add an encryption layer himself. As said, no problem with this implementation, if these points are taken into account – In the case of the Nooie Cam 360, however, a “if” with a question mark.
The camera stream itself looks secure at first. We could also identify parts in plain text here and there, but these were rather uncritical information that could also be secured, but basically did not cause any vulnerability. A limited code analysis as part of the quick check also indicated a quite solid implementation and payload encryption with AES (with the help of the relatively frequently integrated SDK from the Chinese IoT manufacturer Tuya in version 3.34.5).
The real problem, however, is actually the communication for authentication and administration, which, although encrypted with TLS 1.2, completely undermines the protection of the camera stream due to its implementation. We were able to identify a classic vulnerability in the form of insufficient certificate validation on the application side. A simple man-in-the-middle attack on the connections of the applications thus allows account details, user data and the like to be read and entire accounts to be taken over in this way. The account password itself is then transmitted as MD5 and can therefore also be reconstructed relatively easy, especially if it is a natural language password. Using the mobile application in a public, possibly untrustworthy WLAN would therefore be extremely risky because the WLAN operator could easily break all encrypted connections and access critical information.
Also noticeable from the communication readout is the large amount of data that the camera system collects and transmits about the user and the user’s phone. We will come back to this point in the next section.
Furthermore, as usual, we also subjected the server side of the solution to a quick security scan and did not find any super critical issues. Only a small update of the server configurations would be suggested here – support for the long outdated TLS protocol versions 1.0 and 1.1 leave some theoretical weak points and should be disabled immediately. In the current implementation of the applications, however, this point is almost irrelevant, since connections in the more recent TLS version 1.2 are also vulnerable to a number of attacks here.
Data protection and privacy
The sheer amount of collected information is not something that could be criticized, as long as the user is informed about it in detail. What the user decides for himself and his data is up to them. We would still like to mention it because it obviously exceeds what would be necessary for the pure functionality of the camera system in our opinion.
The Nooie Cam 360 is quite a usable camera solution. In fact, we had expected worse beforehand. Of course, we also have to note that this was only our quick check – we did not dive into the deepest depths of the solution and thus cannot completely rule out further abysses. What we have seen, however, could be turned into a quite solid security solution with a few manageable updates and fixes. The serious security flaw in online communication and the far from perfect implementation of data protection and privacy do not allow more than 1 out of 3 stars as a rating in the current state – but admittedly 1 star more than we had initially feared.