Where does the video feed from home cameras go? A traffic analysis. The product – Part 1

In home security cameras have been increasing in numbers hugely in the past few years. Used for checking pets, indoors, outdoors environments they provide a quick and simple way to have an eye in places where it is needed – like shops or inside homes – and human presence is not always available. Often the camera is the only component bought, meaning that the video feed goes to a cloud. Yes but which? And where? And whose is it? And what can the backend system do?

An analysis of the traffic of the EZVIZ/Hikvision wireless security camera and app has been done. Basically the Italian users data goes to remote cloud servers everywhere, except Italy.

Just for clarity, it is probably the same scenario for different camera manufacturers, more are in testing.

Recommendations on camera regulations:

• For the security of Italian users’ data, all information should remain in data centers in the country.
• Video backends used by cloud enabled home security cameras should be clearly detailed. All the servers/services of the cloud should be located in the country, in this case Italy.
• Online vendors should list vulnerabilities found in the hardware they are selling on the items’ page, just like the item’s reviews.

Table of contents

Part 1: The Ezviz in home security camera product

Part 2: The cloud backend and the traffic analysis from the security camera

Part 3: The security camera manufacturer, Hikvision

Part 4: Worst case scenario of cloud software for private consumers

Currently all the videos recorded by the security camera in Italy transit through servers abroad before being sent back to the user in Italy.

The servers in Frankfurt owned by Tencent and London/Honk Kong owned by uCloud transport the video feeds from the camera to the user. The camera’s time is set via NTP from a Hikvision server based in China, and the API commands of the app to the camera are sent via a EC2 instance server in Ireland owned by Amazon. The graph shows these interactions:

The model analysed were bought over the top from Amazon’s Italy store. All the information here is for educational and research purposes.

How does the video from the security camera get to the smartphone?

The way the Ezviz in home security camera shares traffic is – conversely to what could be thought – not only from the camera to the smartphone via local wifi,as it happens for RTSP streaming/lan view. The camera is connected to the smartphone app of the user monitoring: from the camera to a server outside Italy, then from the server to the users’ smartphone app wherever the user is, in Italy at home or abroad. The video feed is encrypted via a proprietary protocol, and it seems Transport Stream (TS) video.

No where it is mentioned that the video data of a user in Italy before reaching his/her smartphone goes through a server in possibly in Honk Kong and/or London.

The graph below highlights this:

The graph above shows the 4 steps of the connection:

1. The IP camera in the user’s home connects to the users home Wifi modem and records what it sees
2. The data is then transferred via a proprietary protocol to a Ucloud server registered in Honk Kong.
3. The server then processes the data and either stores it in its cloud or relays it (only?) back to the Wifi network
4. The users’ smartphone connected to the Wifi network receives the data and decrypts it via the smartphone proprietary app and gets the video.

This sort of interaction is not made clear on the product page, neither it is specified anywhere in the description of the product once received at home.

From the user point of view, it would be best if Consumer Electronics (CE) manufacturers were required by law to have server hosting the data in the country that the devices are being sold, for example Italy and monitored by privacy watchdogs.

The video camera product – EZVIZ

The model tested was an indoor security camera (C6N) from EZVIZ: https://www.amazon.it/gp/product/B07W4FMSD9/

And the Amazon page:

In order to understand the traffic flow from the security camera to the web and back, the camera was LAN connected to a laptop running Wireshark and sharing its connection. The Ezviz app on the phone was being run at the same time as Charles Proxy with a Charles CA installed on the phone to decrypt parts of the traffic going through.

The model being sold is currently subject to CVE-2022-2471, which per the NVD has a CVSS3 score of 9.8/10, discovered in September 2022.

The vulnerability:

Stack-based Buffer Overflow vulnerability in the EZVIZ Motion Detection component as used in camera models CS-CV248, CS-C6N-A0-1C2WFR, CS-DB1C-A0-1E2W2FR, CS-C6N-B0-1G2WF, CS-C3W-A0-3H4WFRL allows a remote attacker to execute remote code on the device.

https://nvd.nist.gov/vuln/detail/CVE-2022-2471

And the other vulnerability also discovered in September 2022 is CVE-2022-2472, with a score of 7.6/10 and defined as:

Improper Initialization vulnerability in the local server component of EZVIZ CS-C6N-A0-1C2WFR allows a local attacker to read the contents of the memory space containing the encrypted admin password.

https://nvd.nist.gov/vuln/detail/CVE-2022-2472

EZVIZ made an announcement around these vulns with a fix initially at this page: https://www.ezviz.com/us/page/notice-2022-09-14. The notice is:

EZVIZ recommends updating the firmware on the wireless security camera!

Online vendors (like Amazon) should be required by law to list the number and severity of vulnerabilities with the model/version of the item being sold on the item’s page, by fetching this information via API from vulnerabilities databases.

In part 2 the cloud backend and the camera traffic from and to the internet will be analysed.