Vulnerabilities Identified in Dafang Camera

As the creator of the world’s first smart home cybersecurity hub, Bitdefender regularly audits popular IoT hardware for vulnerabilities that might affect customers if left unaddressed. This research paper is part of a broader program that aims to shed light on the security of the world’s best-sellers in the IoT space. This report covers vulnerabilities identified in Dafang smart cameras and possibly in Xiaofang Dafang smart cameras with firmware version 5.5.1.419.

Vulnerabilities at a glance

• [REMOTE] Improper credential validation in the apicn.hualaikeji.com API endpoint
• [REMOTE] remote connection authentication bypass (similar to CVE-2019-9564)

Disclosure timeline

• Feb 02, 2019: Internal notification
• Feb 28, 2019: Bitdefender enquires for a secure channel to share the vulnerability report
• Mar 01, 2019: Vendor responds, Bitdefender shares info and PoC
• Mar 05, 2019: Vulnerable vendor confirms the issue
• Mar 29, 2019: Bitdefender asks for an update
• Mar 29, 2019: The vendor asks for an extension
• Jun 14, 2019: Bitdefender asks for another update
• Jun 17, 2019: Vendor confirms patch release
• Jun 20, 2019: This report becomes public as per our vulnerability disclosure guidelines

Vulnerability walkthrough

Part 1 - apicn.hualaikeji.com improper credential validation:

To authenticate on the apicn.hualaikeji.com API the camera will:

• get a random value from API server
• encrypt value with the public key and send the result to API server
• API server decrypts the value and confirms that it matches -> camera has the proper key
• for every request, the camera sends the first 16 bytes of the encrypted random in the parameter "camenr"

We discovered that the API server does not validate the "camenr" parameter when requesting the Kalay/TUTK UID on /ISC3API/camapi/getp2pid.htm.

That means we can request the UID for any camera by only knowing its MAC address. However, our lab test revealed that we can enumerate all the MAC addresses to get all the valid UIDs.

Example request for our camera with MAC address 34CE00AFEB24 (notice the camenr parameter):

POST /ISC3API/camapi/getp2pid.htm HTTP/1.1
Host:apicn.hualaikeji.com:8443
Content-Type:application/x-www-form-urlencoded
Content-Length: 244
Connection:Keep-Alive
Cache-Control:no-cache

headinfo={"camid":"34CE00AFEB24","camenr":"0123456789abcdef","cmpt":"df3","chwv":"5.5.1.243","hwv":"0.0.0.0","pn":"iCamera","ReturnIndex":"0","sc":"53ffc227c877427ab8fb6b314703f70e","sv":"afd4bf6473554db3838414ae50f83f82"}&content={"contype":2}

In the response, we get the UID 3Y9YSPVGYAUDP5B3111A:

HTTP/1.1 200 OK
Cache-Control: private
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Date: Fri, 01 Mar 2019 13:01:49 GMT
Content-Length: 131

{"Result":"1","ResultMessage":"100","ReturnIndex":"0","ReturnValue":{"contype":2,"coninfo":"3Y9YSPVGYAUDP5B3111A"},"TS":1551445309}

Now that we have the UID, we can connect remotely through the Kalay/TUTK service. Unfortunately, we need to authenticate to the devices, which brings us to step 2.

Part 2 - remote connection authentication bypass (very similar to what we previously disclosed  in our Wyze Cam research and summarized in CVE-2019-9564):

When connecting remotely, the client needs to log into the device. Usually, this is done by following these steps: the client sends an IOCtl command with ID 0xBE

the device generates a random value, encrypts it with the 16 bytes "enr" and sends the result to the client

the client, knowing "enr", decrypts the value and sends the result in an IOCtl command with ID 0xC0if the values match, the client is authenticated and can control the device

We discovered a bug in this process that allows us to bypass the login and authenticate without knowing the "enr".

Normally, after the client sends the 0xBE command, the device stores the generated value in memory. However, if we skip sending the 0xBE command, that memory remains NULL. Then, when we send the 0xC0 command with the authentication bytes set to NULL, the device will compare NULL with NULL and authenticate us.

After authentication we can fully control the device, including motion control (pan/tilt), disabling recording to SD, turning camera on/off, etc. We cannot view the live audio and video feed because it is encrypted and we don't have the "enr", but a workaround is described below.

We can set the device to upload all the footage to a rogue SMB server using the 0x2328 IOCtl. From now on, everything that is recorded by the camera (including the videos already on the SD card) will be uploaded to this rogue server.

Impact

Using the API vulnerability, an attacker can get the UID of any camera by only knowing its MAC address. Given that a threat actor can also enumerate all the MAC addresses and get the UIDs for any valid cameras, we can confidently assume that all devices can be compromised and become fully controllable by the attacker.