It is again time for another Quick Check. This time, we take a look at a rather unusual camera, namely one that draws its power from a lamp socket. So the annoying days of changing batteries or hiding cables seem to be over. It also scores points for its ease of installation (if a free lamp holder is available) and by that expands the application areas for discreet surveillance in private homes and businesses. The camera, therefore, promises a high level of convenience for a small budget. Nevertheless, we also wanted to know whether or not it also performs just as well in terms of security and subjected it to our Quick Check.

 

 

Features

The WI-FI Panorama Camera from China (unfortunately, neither the packaging nor the device itself reveals more information about type name or manufacturer) uses a lamp socket as power supply and offers live video streaming, video recording, screenshots, two-way audio and motion alert function. It enables 360-degree surveillance with preselected positions. The accompanying application supports resolutions of 720p, 1080p, 2K, and 4K but with only noticeable changes between 720p and 1080p.

Mobile applications

As usual with our Quick Check, the mobile application ftycampro (com.fty.cam in tested version 1.88 for Android) was subjected to a static analysis. It revealed that the application is configured to allow for plaintext communication, which by itself is not already a serious problem, but is often an indication for such. But more on this point later in the Local and Online Communication section.

Furthermore, with the use of the app the user grants the application access to the external memory, i.e. the SD card of the smartphone. This can be accessed by any other application with the appropriate permission. Normally, this does not cause problems for camera applications, since they store videos and/or images there. However, it is always advisable to look at what is stored here and a closer look revealed that the QR code for logging into the camera is stored there. This allows all other applications on the smartphone to use this QR code and if that is not enough, the identification number (UID), as well as the password to the camera can be seen in it in plain text.

In the further analysis, one tracker was identified: Google Firebase Analytics.

Local and online communication

As mentioned in the previous section, the static analysis pointed out possible vulnerabilities in the plaintext communication. By observing the communication between the device and the application, we examined this in more detail.

As one could already guess, the more detailed analysis revealed that the communication takes place entirely in plain text. This means that the unique identification of the device (UID) is transmitted without encryption. The UID is used in the login procedure to determine the IP address and port of the camera, so anyone with the UID can determine the location of the camera and can easily gain access to devices only protected by weak/default passwords.

Further analysis revealed that the password is transmitted in plain text when logging in and changing the password. Well, actually it is not exactly plain text but “cleverly” made unrecognizable by assigning the one higher or lower ASCII value to each character. So the password: “AAaabbccddeeffgg11223344” becomes “@@“ccbbeeddggff00332255” in the plain text login.

Thus, the password is definitely not secure, but even creating a secure password is not required by the application. The password must contain only one capital letter, one small letter, one number and be longer than 5 characters. This is not what a secure password looks like. In addition, if you enter the password incorrectly and are prompted to enter the correct password, you do not have the option to enter special characters.

But actually, an attacker would not even need the password as the UDP video stream itself is also transmitted in plain text. This allows anyone to record it and reassemble the packets to view the video.

The approach thereby would be as follows:

  • Detect the packets transmitting the video using a dissector for P2P communication.
  • Extract the packets from Wireshark using the filter function pppp.message_type == MSG_DRW into a json document, making sure to check the bytes box.
  • Assemble the packets to a MJPEG using the following script.

  • View by splitting it into individual frames with ff mjpeg -i output.mjpeg frame%d.jpg

The mentioned problems in the P2P communication of Shenzhen Yunni Technology iLnkP2P library existed already in 2019. At that time Paul Marrapese shared the problems in his blog and at the Dev Con. In those he reported his findings and notified them using 2 CVEs. We checked them for their actuality and added our own tests.

The first CVE-2019-11220, states that messages can be read in plain text, including the password and the video stream.

The second CVE-2019-11219, states that the attacker can determine arbitrary UID of the cameras and thus in combination with weak default passwords as factory settings, in our specific case admin:admin, lead to access to all devices.

The UID, which is assigned once when the device is manufactured, consists in our case of 3 uppercase letters identifying the manufacturer/distributor, 6 numbers identifying the device and 5 uppercase letters as a check sum over the rest of the UID. The manufacturer prefix can be easily determined by trying all combinations and sending them to the test camera servers. A UDP request looks like this:

The manufacturer prefix is sent in plain text, so you can just go through them. This is followed by various responses:

  • 0x00 Success, the entire UID exists.
  • 0xFD prefix does not exist.
  • 0xFF Prefix exists, but rest of UID is not correct.

Unlike 2019, today there is a request limit for the servers and after 4 messages you don’t get a response. As a result, we had to wait to send more requests. With our 3 letters, this resulted in a number of 13,824 possibilities. With the 4 messages per 20 seconds limit, this results in a time of 19.2 hours to check the entire vendor prefix space.

In the next step, in 2019 it was possible to calculate the security letters for each of the 6 numbers, as the algorithm was supplied with the application, but this is no longer the case. This has made it much harder to find existing devices, as there are now 10^5 possibilities for the numbers, and a check sequence of 24^5 possibilities for each number. This makes 7,962,624 possibilities to test if one in 100,000 devices exists under the prefix. With the correct prefix, however, we no longer have any limits on our queries to the server (other than the maximum server load), making it theoretically possible to find existing devices in reasonable time.

Data protection and privacy

As part of the Quick Check, we looked at the privacy policy (last modified 12/23/2021). However, to understand it, you should have a good understanding in Chinese, as there is only a Chinese variant. Of course, we have looked at a translated version.

However, there is not much to say about it, as it does not, in the slightest, comply with the GDPR, so we can only summarize what little information is given here. According to the privacy policy, the manufacturer only collects data that is required for use. Data is only passed on if regulatory and judicial (in this case, the Chinese) authorities demand it. Furthermore, there is a point that translates to: “Web camera data automatically received and recorded when you use the APP service.” The item could mean that the location of the camera and the active time of the camera are stored, but could also include all other functions of the camera like the video stream with voice. As a result of our analysis, we could only find out that a heartbeat was transmitted from the camera and some data during login. Thus, it seems that only the location and active time seems to be transmitted and stored, but not the videos or other communication.

It should be noted that the user agrees to the privacy policy by launching the application without having a choice. We would like to mention that the privacy policy in the GooglePlayStore has nothing to do with the usage agreement in the application and that it probably does not belong to this application. Furthermore, the user has no rights to view, correct or delete data. Google’s tracker is also not mentioned.

Verdict

In summary, the camera, at least in concept, actually allows for quite a clever camera solution with a good idea for the power supply. However, due to the aforementioned security issues, it is possible for third parties to gain access to the camera and the live videos. Since the camera thus has serious weaknesses in all relevant security areas we cannot award any stars here.