In part 1 of this Ezviz traffic analysis the video camera connections was introduced. Now in part 2 the cloud backend and data connections of the camera to the internet are analysed in technical detail.
The HikVision/EZVIZ cloud system processing the video feed
The video cloud backend for EZVIZ wireless security cameras allows for a view from anywhere set up: from your smartphone you see the security camera feed from anywhere you are even far from home, simply by opening the camera app on the phone. The view from anywhere system is similar version of the Hikvision Intelligent transportation integrated management and control platform Overseas Edition, or iVMS – a video surveillance system with facial recognition, automatic activities detection and object recognition and extensive search capabilities.
Passing video data from the camera or the mobile phone, to somewhere and to then process it and send it back is the way also video streaming works, except the camera is in a studio and not in the house.
Going deeper into the detail of the graph shown in part 1, the Ezviz/Hikvision security camera network traffic is represented here as well showing the data from a user and camera in Italy to abroad, depending on the services and protocol types used in the interactions:
So it is important in the case of personally identifiable information like video feed from home security cameras, that it is clear which cloud backend system it is, where it is located and what can it do and who manages it.
The following diagram shows how the Hikvision iVMS video management cloud backend system is set up:
The system is a video surveillance system, which is described by Hikvision as follows:
[iVMS is] integrated with video surveillance – preview, video, playback, on the TV wall – checkpoint, electronic police, urban illegal evidence collection, electronic maps and other functions in one integrated management and control platform. To achieve the unified management of surveillance, capture, encoding, decoding equipment, organizations, users and permissions.
Hikvision iVMS 8600 manual
https://www.scribd.com/document/437478074/IVMS-8600-Platform-Software-Introduction
In this analysis direct connection with the Video Transmission Management (VTM) component of the system has been identified and documented. More information at the end of the article.
The data exchange between the camera and the internet
The IP addresses reached from the EZVIZ/Hikvision camera during the traffic capture:
Once it started streaming from the camera to the phone, it would send the video data to this IP address: 118.193.65.131, sending packets with length of 1412 bytes via TCP.
The video traffic from the camera to the HikVision’s uCloud server in London:
Initially the TCP packets include the camera unique ID and backend storage address.
The nature of the address of the remote server 118.193.65.131:
- The IP address belongs to: UCloud Information Technology (HK) Limited. A provider of cloud functionalities for Chinese companies home and abroad. The specific IP address is assigned from the Hong Kong internet exchange point
- Doing a WHOIS on the IP address, some show that it is based in London, England other in Honk Kong. In the case of the hosting in London, one Whois provider is showing that this IP address is using privacy to be hidden and a Proxy-registered route object
- The initial part of the data being sent to the video management server is:
00718:euuc_cen10.201.193.254:F91451956:110.201.193.254is the address of the database holding the video segmentsF91451956is the unique camera ID:1is the camera channel
So the video feeds from security cameras of Italian users are going through London and/or Honk Kong without any scrutiny on whether the data is then relayed further or copied, indexed or viewed.
Continuing on the investigation, when the app on the mobile phone is sending API commands to the camera, the API calls are sent and received by the camera through this IP address: 34.244.172.97, which belongs to Amazon in Ireland.
The Thrift protocol with protobuffer streamed to the smartphone app carries the video feed of users.
Other protocols used by the camera to exchange information: X11, DNS, Protobuffer, NTP, SSDP, Thrift
X11 remote view protocol
Interestingly another service in constant connection with the camera, living at 49.51.150.132, and based initially in Frankfurt and being owned by Chinese Tencent cloud computing (Beijing) Co., Ltd.
https://ipinfo.io/49.51.150.132
The client-server communication:
- the Italian user public IP address:
92.22.296.119 - the port its using to communicate:
46345 - the camera unique ID in XML format, via mostly the UDP protocol:
F91451956 - (possibly) the MIT-MAGIC-COOKIE-1 to authenticate to the X server:
985f68ff2efca9a75ac05fd38ae35cb2and4ecadd67ce5139d18d5d7f1c355977fb
The XML format used reflects also the one used in iVMS and Hik-connect.
Request from the camera:
<?xml version="1.0" encoding="utf-8"?> <Request> <DevSerial>F91451956</DevSerial> </Request> 4ecadd67ce5139d18d5d7f1c355977fb
Response from the Tencent iVMS server:
<?xml version='1.0' encoding='utf-8' ?> <Response> <Result>0</Result> <Client Address="92.22.296.119" Port="46345"/> </Response> 985f68ff2efca9a75ac05fd38ae35cb2
After the (unencrypted) UDP data exchange is being done, there is an unexpected
X11 protocol exchange process:
The X11 protocol allows for remote access via SSH for display.
Why is this necessary?
And why is this opened on a private camera?
Network Time Protocol setting time on the camera
Investigating the other IPs contacted by the wireless security camera, another one is for the Network Time Protocol: 183.136.184.225 which is a IP address based in China of the “Hangzhou Hikvision digital technology Limited by Share Ltd” NTP version 4 service to sync local time with UTC.
Basically it is a server that helps in performing a very important function in any computer and as such a connected home security video camera, which is to sync the time on the camera device to the internet time. Setting time is an important concept of cryptography because it contributes to the random number generation of decryption keys.
SSDP Protocol and discovery of other devices in the wifi local network
The camera also supports SSDP or Simple Service Discovery Protocol which is incorporated in uPnP and in the past has been used for DDOS attacks, evidence of this is seen at:
A backup image from the camera saved, via HTTP protocol
Backup image is saved into AWS Amazon in Ireland:
There is also a post request being made to: 52.210.64.1 an AWS EC2 instance with a hostname: ec2-52-210-64-1.eu-west-1.compute.amazonaws.com
POST /sdk.post HTTP/1.1 Accept: *.* Host: backupserver:8080 Connection: close Content-Length: 23306 Content-Type: application/x-www-form-urlencoded filename=undefined&code= hikencodepicture
With the response being:
HTTP/1.1 200 OK Date: Fri, 04 Nov 2022 10:30:59 GMT Server: nginx Content-Length: 54 Connection: Close /image/pic/3358021107254688bt2267dc852d7af9?c=1700de8c
So there is an image being sent (and saved) to an EC2 AWS instance in Dublin, Ireland, but why?
This is not an IP address used by the app to share information with the camera.
Domain Name Server resolution protocol, ip address to URL
DNS protocol includes accessing the table where an IP address is linked to a URL, so that the server hosting the site at the URL can be loaded.
DNS resolutions are made to:
litedev.ezvizlife.com
pmseu1.ezvizlife.com
There is another connection, made to 152.32.198.25 sending video chunk of abouot 3MBs to the phone. The IP is uCloud Information Technology (HK) Limited and also located in London.
The Thrift protocol for video data
Initially the IP Camera sends packets mostly of 1466 bytes which is video data embedded in, then at some point, only the 152.32.198.25 server based in London responds with packets of size 54 bytes. After 152.32.198.25 sends a RESET flag to the IP Camera, the conversation between the IP security camera and this uCloud IP ends with a request from the IP wireless security camera via the Thrift protocol using a CALL method:
EZVIZ phone app video protocol
The EZVIZ app traffic was captured using Charles Proxy with Charles’ HTTPS certificate added to the phone trust store to decrypt the communication between the EZVIZ app and the internet.
The video feed is being transmitted from the cloud in London via protobuffer which allows the transmission of data with proprietary video encryption and transmission. The other endpoint and associated metadata for receiving the video feed from the camera is:
ysproto://152.32.198.25:7100/live?dev=F91451956&chn=1&stream=1&cln=1&isp=0&auth=1&ssn=ut.<UNIVERSAL_TOKEN>&weakstream=1&isretry=0&lid=2<LICENSE_ID>&biz=1×tamp=1667559606601×tamp=1667559606601 2a15228f55116d3a5b95az9f98a5982v3.6.1.20210513 2v3.6.1.20210513
Base64 decoding 2a15228f55116d3a5b95az9f98a5982, gives ~ “youoi“, a company in Shenzen, China creating components for IOT devices.
The request to 152.32.198.25:7100, based in London, is preceded by an “options” request to the streaming address.
The response to this “options” request includes the server which will be streaming the camera feed: ys7-vtm vtmeu193.105
ys7: is the identifier for the EZVIZ OpenBiz SDK, infact www.ys7.com redirects to www.ezviz.com/cn and therefore HikVision.
vtm: is the Video Transmission Management Server of the Hikvision iVMS system.
So it is a EZVIZ installation of Hikvision iVMS.
As per the Hikvision manual definition on VTM:
Video Transmission Management Server(VTM)
The video transmission management server, which manages the stream media server, supports the following functions.
Stream media server cluster management and load balancing.
Streaming re-orientation: Once the client asks the VTM for streaming, according to the client required URL and load balancing strategy, the VTM selects a VTDU address from the configured cluster and assembles a result URL to the client. The client gets stream from VTDU via the RTSP protocol after receiving the result returned by VTM
https://www.hikvision.com/content/dam/hikvision/en/support/download/vms/ivms4200-series/user-manual/2021-07-01/UD24421B_iVMS-4200-Client_User-Manual_V3.6.0_20210622.PDF