Recently I purchased a number or IoT devices for a vulnerability research project. Among them was the Amcrest IPM-721S Wireless IP camera, a wireless pan-and-tilt camera, which at the time had 6,381 reviews on Amazon.com (interestingly, that number is down to 1,425 at the time of this writing).
Initial setup of the camera was straightforward using the Amcrest View Pro Android app. Setup included scanning a serial number QR code on the camera to join the app with the camera’s default peer-to-peer (P2P) wireless network, followed by setting a new administrator password and adding the camera to a home wireless network.
Once the camera setup was complete, it called home to www.amcrestcloud.com to receive a short extensible markup language (XML) configuration file including addresses and ports for various services including Command, FTP and Media. The camera then opened a connection to the Command server on TCP port 8443.
This call home facilitated adding the camera to one of Amcrest’s “cloud viewer” applications. Amcrest offers two options for browser-based remote camera viewing, amcrestcloud.com and amcrestview.com. Amcrest Cloud appears to be the newer application, offering cloud storage of recorded video while Amcrest View appears to be the legacy application for simple remote viewing. I focused on the simpler Amcrest View web application for my initial testing.
The Amcrest View application relies on an unsigned ActiveX plugin to handle P2P connections between the browser and any cameras associated with the user’s account. Cameras are added to the application by entering a device name as the label, the camera’s serial number, and the administrator credentials that were configured during the camera’s initial setup. Once added to an account on Amcrest View, the application allows the owner to view the status of the camera (online or offline) and access a live view of the camera.
The first thing I attempted was the obvious goal; viewing a camera that was not associated with my account. To test this, I added my camera to an account and then created a second account to use in my tests.
I performed most of my investigating using Burp Suite’s proxy to Man-in-the-Middle my browser connections to the web application as well as Burp Suite’s repeater tool to easily modify and send requests to the server.
Accessing a camera starts with sending the serial number via POST request to https://www.amcrestview.com/equipment/equipment_goToEquipmentWeb.action and receiving connection details including the P2P port and the Base64-encoded password for the camera.
The browser application then submits another request to decode the returned Base64-encoded password and finally hands off all the details to the ActiveX plugin.
My attempts to retrieve the same connection info with an unauthenticated session and with my second authenticated user failed, confirming Amcrest verifies ownership of the serial number by the authenticated user before providing connection details.
If I couldn’t view a camera that I didn’t own, how about simply taking ownership of the account that owned the camera?
Unauthorized Account Modification Vulnerability
Amcrest View, like most web applications, has a facility for modifying account settings like the associated email address. To change the email address associated with an account, the browser submits a POST request to https://www.amcrestview.com/account/users_modifyUserInfo. A successful edit returns “true” in the response body while an unsuccessful edit returns “false” in the response body.
The POST request contains several parameters with the important ones being user.userName and user.email. A successful request tells Amcrest View to set the email address for the username in the user.userName parameter to the value of the user.email parameter. As it turned out, this request succeeded even if the user.userName parameter didn’t match the username of the currently authenticated user session.
Logging in to the TestUser2 account confirmed that the associated email address had been modified by my request made using TestUser1’s authenticated session. If I were a bad guy, I could have used this vulnerability to modify the email address associated with any account and then issue a password reset to take over the account and obtain live access to their cameras. The vulnerability admittedly did require knowledge of the victim’s username, but there are ways to obtain potential usernames, such as the Amcrest public forums.
Stored XSS Vulnerability
After confirming both vulnerabilities, I immediately wrote and submitted a report to Amcrest. Amcrest quickly confirmed the vulnerabilities and patched their web portal within 30 days of confirmation.
- 3 November 2016 – Vulnerabilities discovered
- 4 November 2016 – Reported to manufacturer
- 8 November 2016 – Report confirmed by manufacturer
- 7 December 2016 – Vulnerabilities resolved by manufacturer
Nice work, Marc.
all products designed for the IOT market should be pressure tested like this…WHY are companies not doing so?
Its partially reason why the Internet is so broken.
Good on your for writing and researching this!
Shame on Amcrest. Glad their reviews dropped and I will not buy a second item from them again.
@Lou Why are we shaming Amcrest again? They acknowledged multiple vulnerabilities on their legacy web portal within a week and patched the vulnerabilities within a month. That’s not bad at all for a small company.
I found this write-up specifically because I wanted to see how they responded to responsible disclosure before I buy their products. If anything this has convinced me that they can be trusted to respond appropriately to vulnerabilities and apply patches appropriately.
Mark Kobin says
lots changed in a year.
current (7/2018) firmware for 941 and 841 cameras can not shut off wifi or upnp. it looks like its off in the web interface (and nvr central) but when you scan for it you see the services are alive. in certain instances service is actually brought down only to come back up in a reboot (either due to power cycle or administrative reboot).
the web interface shows it off but both air and/or network sniffing/scanning show that the services are alive.
if youve setup your wifi once but then opted for ethernet and turned off wifi you are very vulnerable to yes-man or any ap masquarading attack. i havent had the chance to go into detail but it seems to have implemented the wpa2 handshake partially or something else ive overlooked.
through upnp it is very easy to DOS it as it does not fully implement standard and becomes unstable. unit may come back into service after 40-50min or stay unresponsive till reboot. will reply to ping but no camera feed and loging into web interface is possible but unusable.
and just to be clear tested with 4×841 and 2×941 cameras.
amcrest support acts dumb. multiple scheduled phone calls with their engineering never happened and followed by dead silence and apologies when i followed up. email engineering escalation has not resulted in any solution or even an acknowledgement…
i kind of let it go when one of the first line support people suggested that i can open the casing and remove the wifi antenna, and then noted but that would void my warranty… lots of changes in their service level i guess…
amcrest seems to be falling the way of the cheap chinese camera black hole.