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).
Camera Setup
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.
Initial Testing
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.
Request:
Response:
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.
Request:
Response:
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.
Request:
Response:
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
While confirming the unauthorized account modification vulnerability, I also found the input I passed in the user.email parameter was not validated or fully sanitized. This could be exploited to inject arbitrary JavaScript into a victim’s session; a perfect example of a stored cross-site scripting vulnerability.
Request:
Proof:
Conclusion
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.
Timeline
- 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