I recently updated the firmware of my Amcrest IP2M-841 and IP3M-943 cameras to the latest version. Afterward I began noticing a constant connection to three separate, unknown servers.

I found this odd as I had not seen these connections prior to the firmware update. Performing a simple DNS lookup for each yielded the following:

ec2-52-90-88-253.compute-1.amazonaws.com

ec2-107-23-233-106.compute-1.amazonaws.com

ec2-52-91-65-92.compute-1.amazonaws.com

This clearly shows that all three servers are hosted on Amazon AWS. Unfortunately this tells us nothing about who is using Amazon’s infrastructure to talk to my cameras. So to investigate further, I went directly to ec2-52-90-88-253.compute-1.amazonaws.com in the browser, noting to use HTTPS since port 443 was being used.

This triggered a warning that the SSL certificate was not trusted and could not connect. The error message provided by Chrome was “ERR_BAD_SSL_CLIENT_AUTH_CERT” with no further details. I was not able to find out the certificate was self-signed by someone named “Dan Burkett” until I used Pale Moon. So who is Dan Burkett and why are my cameras using a self-signed SSL cert to speak to him?

According to CrunchBase, Dan Burkett is co-founder and CTO at Camcloud, based in Ontario, Canada, where he primarily focuses on platform architecture, mobile development and streaming media.

So is Dan watching me undress? Probably not, but let’s see how much bandwidth (traffic) my IP2M-841 camera is using to talk to Dan’s servers. This is accomplished with an SNMP sensor in PRTG once the SNMP option is enabled and the strings set in the camera configuration page.

Over the last two days the traffic has been constant, averaging about 14 kbit/s during the time period. Is this enough usage to be watching a secret live video feed of me? Not likely as that equates to a transfer rate of 1.75 kilobytes per second. At this level even a low resolution JPEG snapshot being taken at a reasonable interval would be near impossible.

So what is actually being disseminated to these mysterious cloud servers? The only way to find out would be to complete a packet capture with Wireshark and monitor the traffic in real time.

Unfortunately the traffic to the mysterious cloud servers is encrypted, so without the server’s private key we will never known what is being transmitted.

However, we are able to find out the DNS names of the servers based on the queries sent from the camera. Finally the names were revealed when the DNS lookup answers came in:

Queries

ftps.hostedcloudvideo.com: type A, class IN

Answers

ftps.hostedcloudvideo.com: type A, class IN, addr 54.159.91.18

ftps.hostedcloudvideo.com: type A, class IN, addr 54.224.213.162

ftps.hostedcloudvideo.com: type A, class IN, addr 54.80.240.204

ftps.hostedcloudvideo.com: type A, class IN, addr 54.80.249.22

ftps.hostedcloudvideo.com: type A, class IN, addr 54.158.231.89

ftps.hostedcloudvideo.com: type A, class IN, addr 23.20.159.229

ftps.hostedcloudvideo.com: type A, class IN, addr 54.159.95.70

ftps.hostedcloudvideo.com: type A, class IN, addr 54.166.187.129

ftps.hostedcloudvideo.com: type A, class IN, addr 54.162.101.239

ftps.hostedcloudvideo.com: type A, class IN, addr 54.198.155.118

ftps.hostedcloudvideo.com: type A, class IN, addr 54.158.208.74

ftps.hostedcloudvideo.com: type A, class IN, addr 54.146.1.185

ftps.hostedcloudvideo.com: type A, class IN, addr 54.167.219.193

ftps.hostedcloudvideo.com: type A, class IN, addr 54.162.218.154

ftps.hostedcloudvideo.com: type A, class IN, addr 54.146.46.97

ftps.hostedcloudvideo.com: type A, class IN, addr 54.221.201.14

ftps.hostedcloudvideo.com: type A, class IN, addr 23.20.254.144 Queries

config.amcrestcloud.com: type A, class IN

Name: config.amcrestcloud.com

Answers

config.amcrestcloud.com: type A, class IN, addr 54.158.250.32 Queries

command-4.amcrestcloud.com: type A, class IN

Answers

command-4.amcrestcloud.com: type A, class IN, addr 52.90.88.253 Queries

media-amc-0.hostedcloudvideo.com: type A, class IN

Answers

media-amc-0.hostedcloudvideo.com: type A, class IN, addr 54.162.224.230 Queries

dh.amcrestsecurity.com: type A, class IN

Answers

dh.amcrestsecurity.com: type A, class IN, addr 54.84.228.44

This shows the constant connection to 52.90.88.253 is the “command server” command-4.amcrestcloud.com. Amcrest Support was not able to provide any reasons why is this connection necessary.

Bonus Notes

The last DNS query shows another connection the camera made to another server, dh.amcrestsecurity.com. This connection was not encrypted.

It appears the camera reads the file http://dh.amcrestsecurity.com/readbinfile.html as some sort of firmware check.

6/1/2017 — Update

After much discussion with Amcrest Support regarding this issue, the following update was received:

Hello Troy, I’m from Amcrest Cloud support. Sorry for all the back and forth. We’ve finally come to understand the situation. Thanks for all the feedback via email and your blog post (great analysis btw). A couple of points: 1 – All the traffic from camera -> cloud is expected and standard for this kind of device and matches what would be in our server logs, including pings to the cloud servers, certificate exchange/setup, etc. 2 – The problem you’ve identified is that the outbound communication is supposed to stop after 2 hours if a user has not attached their camera to a cloud account. We have finally reproduced this problem internally and you’re right, there is an issue in the firmware. We are working with the firmware team to ensure this traffic is halted after 2 hours, as intended. I’m currently testing a release that fixes this, so it shouldn’t be long before the new firmware is released. Once again, thanks for taking the time to dig into our product at this level of detail. Regards,

Alen

8/22/2017 — Update

Amcrest has fixed this issue for certain cameras / firmware versions. Read more in my update here.