Latest firmware update for Amcrest cameras results in constant connection to cloud servers even for non-cloud customers

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.

Amcrest likes to watch you.

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.

Dan Burkett also likes to watch!

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.

Camera bandwidth (traffic) usage

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 realtime.

Wireshark Capture

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.

Wireshark Capture 2

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.

5 Replies to “Latest firmware update for Amcrest cameras results in constant connection to cloud servers even for non-cloud customers”

  1. good on you Troy!

    my webcam is constantly trying to connect to config.amcrestcloud.com and i don’t have any of their cloud garbage setup.

    shame on you Amcrest ! here comes another shitty amazon review and refund request! you shouldn’t be making ANY outbound requests without me telling you to. idgaf about what you think is standard for a webcam.

  2. I too just installed the new firmware and by chance I installed pi-hole on my network. Well, in 24 hrs there has been thousands of requests back to config.amcrestcloud.com that I have now blocked with pi-hole. This really is pissing me off knowing my network is getting slammed with traffic. I have 6 Amcrest cameras running using Blue Iris. I hope this is fixed soon or I will have to figure out a way to stop these at the source.

  3. I AM HAVING MAJOR ISSUES ALL OF A SUDDEN ALL MY CAMS ARE BEING HACKED AND THEY ARE RENAMING THE CAMS AS HACKED AS TO THROW IN MY FACE I CONTINUE TO CHANGE PASSWORDS AND EACH TIME I CONNECT BACK TO MY HOST THEY CRASH THEM AGAIN AND CHANGE ALL MY IP ADD AND MORE CAN SOMEONE PLEASE GIVE ME ADVICE BC AMCREST TECHS HAVE NOT BEEN HELPFUL AT ALL.

Leave a Reply