Preface
Half way through 2020, UK independent consumer champion Which? magazine reached out to us and asked if we could assist investigating the security of a series of domestic IoT devices and to perform a vulnerability assessment of each device. The assessments included smart plugs and smart/connected doorbells. We also worked on a number of other domestic IoT device types outside of the Which? research which we will cover in this multi-part blog series.
In this post, we cover a range of IoT doorbells, both branded to non-branded. We walk through some of the main security issues discovered, their real life impact and our conclusion to this part of the research.
Devices Investigated
- Victure: VD300
- Unbranded: HD Wi-Fi Video Doorbell V5
- Unbranded: Smart WiFi Doorbell (YinXn)
- Qihoo: 360 D819 Smart Video Doorbell
- Accfly: Smart Video Doorbell V5
- Unbranded: Smart Wifi Doorbell – XF-IP007H
Infrastructure
Undocumented Device Features
DNS Server (Port 53)
It was found that on the Qihoo 360 device, a DNS service existed. This service was fully functional in that requests sent to the device were met with a response.
It is unknown why there was a DNS service running on the device as all requests at this level inside the network would be handled by the router-issued DNS IP. Investigation into this type of service can sometimes lead down the route of a covert DNS channel for malware delivery. We did not see anything during testing that could lead us into such a rabbit hole.
HTTP Service (Port 80)
A HTTP service that was found to be running on port 80 on the Victure Doorbell could be accessed via the user’s network and required a set of credentials:
We found an unbranded clone of this device for sale online; the firmware was extracted from the cloned device to retrieve the login details by simply performing strings across the firmware. Further analysis of the device firmware revealed the API calls required to interact with the device.
The following endpoints provided the ability to gather debug information from the device including the credentials for the Wi-Fi and backend MQTT server. The endpoints needed to be called in the following order to open (start the logging), upload (read the log) and then close which stops the logging process.
- /log/open
- /log/upload
- /log/close
Cleartext Wi-Fi credentials stored
Within the log output from the process above, the cleartext Wi-Fi name and password could be seen:
[01-01 00:00:00][WARN][board.c:1602] [[[[ dev_cfg wifi_ssid: ]]]]
[01-01 00:00:00][WARN][board.c:1603] [[[[ dev_cfg wifi_psk: ]]]] MQTT credentials
It is unknown what information can be obtained from holding the MQTT information for the device as the credentials cannot be tested. As stated by the log snippet below, they are seen to be valid and could potentially enable the enumeration of further devices connected to the backend server:
[10-30 19:42:16][DBG][mqtt_api.c:464] [[[[ Using default username: ]]]]
[10-30 19:42:16][DBG][mqtt_api.c:473] [[[[ mqtt_params.password: ]]]]
[10-30 19:42:16][DBG][pps_ssl.c:168] [[[[ . Connecting to tcp://apis-us-west.meari.com.cn:443... ok ]]]]
[10-30 19:42:16][DBG][pps_ssl.c:176] . Setting up the SSL/TLS structure... ok
[10-30 19:42:16][DBG][iotx_mqtt_client.c:100] Input heartbeat interval(300000 ms) > Allowed maximum(180000 ms)
[10-30 19:42:16][DBG][pps_sd_stream_mng.c:59] record I frame date: 1604086936
[10-30 19:42:16][DBG][iotx_mqtt_client.c:240] [[[[ MQTT init success! ]]]] System Commands
- /sys/factory_reset – Wipes the device
- /sys/console
- /sys/sleep – Sleeps the device
- /sys/active – Holds the device as active
Firmware Updating
A number of methods existed to perform a firmware upgrade via the embedded web application:
- /flash/encryption
- /flash/identity
- /flash/upgrade/all
- /flash/upgrade/ppstrong
- /flash/upgrade/percent
- /flash/upgrade/release_package
- /flash/iperf3
Internet-Facing Devices
Searching shodan.io for ppstrong, we confirmed our deepest concerns about these devices. At the time of writing this post, 171 online devices were found to contain the ‘www-user@ppstrong’ login banner. These devices were not tested with the login details we extracted from the device, but the fact they have a static IP address and could be reached via the Internet is very worrying.
Mobile Application
Application Communication is Unencrypted
On a number of devices, HTTPS was not enforced or didn’t even exist as a communication method on a range of mobile applications such as the Victure mobile application which was found to be requesting a root certificate via a HTTP request.
GET Request:
GET /cert_pub/root.crt HTTP/1.1
Accept-Language: en-US,en;q=0.8
User-Agent: Mozilla/5.0 (Linux; U; Android 8.1.0; en-us; Nexus 5X Build/OPM6.171019.030.K1) AppleWebKit/533.1 (KHTML, like Gecko) Version/5.0 Mobile Safari/533.1
Host: aliyun-iot.oss-cn-hangzhou.aliyuncs.com
Connection: close
Accept-Encoding: gzip, deflateResponse:
HTTP/1.1 200 OKServer: AliyunOSS
-----BEGIN CERTIFICATE----- MIIDdTCCAl2gAwIBAgILBAAAAAABFUtaw5QwDQYJKoZIhvcNAQEFBQAwVzELMAkG A1UEBhMCQkUxGTAXBgNVBAoTEEdsb2JhbFNpZ24gbnYtc2ExEDAOBgNVBAsTB1Jv b3QgQ0ExGzAZBgNVBAMTEkdsb2JhbFNpZ24gUm9vdCBDQTAeFw05ODA5MDExMjAw MDBaFw0yODAxMjgxMjAwMDBaMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i YWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxT aWduIFJvb3QgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDaDuaZ jc6j40+Kfvvxi4Mla+pIH/EqsLmVEQS98GPR4mdmzxzdzxtIK+6NiY6arymAZavp xy0Sy6scTHAHoT0KMM0VjU/43dSMUBUc71DuxC73/OlS8pF94G3VNTCOXkNz8kHp 1Wrjsok6Vjk4bwY8iGlbKk3Fp1S4bInMm/k8yuX9ifUSPJJ4ltbcdG6TRGHRjcdG snUOhugZitVtbNV4FpWi6cgKOOvyJBNPc1STE4U6G7weNLWLBYy5d4ux2x8gkasJ U26Qzns3dLlwR5EiUWMWea6xrkEmCMgZK9FGqkjWZCrXgzT/LCrBbBlDSgeF59N8 9iFo7+ryUp9/k5DPAgMBAAGjQjBAMA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8E BTADAQH/MB0GA1UdDgQWBBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0B AQUFAAOCAQEA1nPnfE920I2/7LqivjTFKDK1fPxsnCwrvQmeU79rXqoRSLblCKOz yj1hTdNGCbM+w6DjY1Ub8rrvrTnhQ7k4o+YviiY776BQVvnGCv04zcQLcFGUl5gE 38NflNUVyRRBnMRddWQVDf9VMOyGj/8N7yy5Y0b2qvzfvGn9LhJIZJrglfCm7ymP AbEVtQwdpf5pLGkkeB6zpxxxYu7KyJesF12KwvhHhm4qxFYxldBniYUr+WymXUad DKqC5JlR3XC321Y9YeRq4VzW9v493kHMB65jUr9TU/Qr6cf9tveCX4XSQRjbgbME HMUfpIBvFSDJ3gyICh3WZlXi/EjJKSZp4A==
-----END CERTIFICATE-----Version: 3 (0x02)
Serial number: 4835703278459707669005204 (0x040000000001154b5ac394)
Algorithm ID: SHA1withRSA
Validity
Not Before: 01/09/1998 12:00:00 (dd-mm-yyyy hh:mm:ss) (980901120000Z)
Not After: 28/01/2028 12:00:00 (dd-mm-yyyy hh:mm:ss) (280128120000Z)
Issuer
C = BE
O = GlobalSign nv-sa
OU = Root CA
CN = GlobalSign Root CA
Subject
C = BE
O = GlobalSign nv-sa
OU = Root CA
CN = GlobalSign Root CA
Public Key
Algorithm: RSA
Length: 2048 bits
Modulus: da:0e:e6:99:8d:ce:a3:e3:4f:8a:7e:fb:f1:8b:83:25:
6b:ea:48:1f:f1:2a:b0:b9:95:11:04:bd:f0:63:d1:e2:
67:66:cf:1c:dd:cf:1b:48:2b:ee:8d:89:8e:9a:af:29:
80:65:ab:e9:c7:2d:12:cb:ab:1c:4c:70:07:a1:3d:0a:
30:cd:15:8d:4f:f8:dd:d4:8c:50:15:1c:ef:50:ee:c4:
2e:f7:fc:e9:52:f2:91:7d:e0:6d:d5:35:30:8e:5e:43:
73:f2:41:e9:d5:6a:e3:b2:89:3a:56:39:38:6f:06:3c:
88:69:5b:2a:4d:c5:a7:54:b8:6c:89:cc:9b:f9:3c:ca:
e5:fd:89:f5:12:3c:92:78:96:d6:dc:74:6e:93:44:61:
d1:8d:c7:46:b2:75:0e:86:e8:19:8a:d5:6d:6c:d5:78:
16:95:a2:e9:c8:0a:38:eb:f2:24:13:4f:73:54:93:13:
85:3a:1b:bc:1e:34:b5:8b:05:8c:b9:77:8b:b1:db:1f:
20:91:ab:09:53:6e:90:ce:7b:37:74:b9:70:47:91:22:
51:63:16:79:ae:b1:ae:41:26:08:c8:19:2b:d1:46:aa:
48:d6:64:2a:d7:83:34:ff:2c:2a:c1:6c:19:43:4a:07:
85:e7:d3:7c:f6:21:68:ef:ea:f2:52:9f:7f:93:90:cf
Exponent: 65537 (0x10001)
Certificate Signature
Algorithm: SHA1withRSA
Signature: d6:73:e7:7c:4f:76:d0:8d:bf:ec:ba:a2:be:34:c5:28:
32:b5:7c:fc:6c:9c:2c:2b:bd:09:9e:53:bf:6b:5e:aa:
11:48:b6:e5:08:a3:b3:ca:3d:61:4d:d3:46:09:b3:3e:
c3:a0:e3:63:55:1b:f2:ba:ef:ad:39:e1:43:b9:38:a3:
e6:2f:8a:26:3b:ef:a0:50:56:f9:c6:0a:fd:38:cd:c4:
0b:70:51:94:97:98:04:df:c3:5f:94:d5:15:c9:14:41:
9c:c4:5d:75:64:15:0d:ff:55:30:ec:86:8f:ff:0d:ef:
2c:b9:63:46:f6:aa:fc:df:bc:69:fd:2e:12:48:64:9a:
e0:95:f0:a6:ef:29:8f:01:b1:15:b5:0c:1d:a5:fe:69:
2c:69:24:78:1e:b3:a7:1c:71:62:ee:ca:c8:97:ac:17:
5d:8a:c2:f8:47:86:6e:2a:c4:56:31:95:d0:67:89:85:
2b:f9:6c:a6:5d:46:9d:0c:aa:82:e4:99:51:dd:70:b7:
db:56:3d:61:e4:6a:e1:5c:d6:f6:fe:3d:de:41:cc:07:
ae:63:52:bf:53:53:f4:2b:e9:c7:fd:b6:f7:82:5f:85:
d2:41:18:db:81:b3:04:1c:c5:1f:a4:80:6f:15:20:c9:
de:0c:88:0a:1d:d6:66:55:e2:fc:48:c9:29:26:69:e0
Extensions
keyUsage CRITICAL:
digitalSignature,nonRepudiation
basicConstraints CRITICAL:
cA=true
subjectKeyIdentifier :
607b661a450d97ca89502f7d04cd34a8fffcfd4bInsecure QR Code Generation
There were multiple uses for QR codes for these devices. Some of the devices used QR codes that were generated by the mobile application used to share the Wi-Fi BSSID and password to the doorbells while others had a share functionality that allowed others to access the devices and “add” profiles to the device, so that theoretically other family members/friends could also access the device video stream and notifications.
During testing each of the QR codes were captured and analysed, revealing all the details that were contained in plaintext as they were being generated and used. None of the generated QR codes were using any kind of encoding or encryption in order to secure the data they were being used for. For obvious reasons we don’t include here any of the QR codes generated during our research.
The lack of security in something as simple also suggests a deeper issue with the initial concept and design of these devices. It would be possible to use a secure QR code generation but this would require both the mobile application and the hardware to be able to support such an implementation. This would require developers and engineers to accept the expanded hardware requirements to integrate this level of security into both the hardware and software for IoT devices.
Unauthenticated Services
A number of the devices we tested revealed poor access controls on the backend services the doorbells and mobile applications were using to communicate with. The unbranded doorbell (HD Wi-Fi Video Doorbell V5) in particular was found to be handling privileged API requests without any authentication that enabled settings to be modified.
The GET request below was performed using the device’s serial number to request information on the device. The request requires no session cookie generation prior to this, just knowledge of the serial number.
GET request
[[[[ GET /device_check/EKDB_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ]]]] HTTP/1.1
Host: api.gdxp.com:8100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: close
Upgrade-Insecure-Requests: 1Response:
HTTP/1.1 200 OK
Server: nginx
Date: Tue, 10 Nov 2020 16:12:12 GMT
Content-Type: text/html; charset=UTF-8
Connection: close
Vary: Accept-Encoding
X-Powered-By: PHP/7.2.6
Set-Cookie: PHPSESSID=xxxxxxxxxxxxxxxxx; path=/
Expires: Thu, 19 Nov 1981 08:52:00 GMT
Cache-Control: no-store, no-cache, must-revalidate
Pragma: no-cache
Content-Length: 497
{"resultCode":0,"msg":"","content":{"cmd_servers":[{"ip":"xxxxxxxx","port":8888,"udp_port":25050}],"udp_servers":[{"ip":"xxxxxxxx","port":25050}],"oss_setting":{"ossFromId":1,"endpoint":"http://oss-eu-west-1.aliyuncs.com","bucket":"britain"},"local_time":"2020-11-10 16:12:12","current_time":1605024732,"sleep_interval":15,"is_test":0,"p2p_servers":[{"ip":"xxxxxxxx","port":17051}],"push_servers":["http://xxxxxxxx:58720"],"stun_servers":[{"ip":"xxxxxxxx","port":17051}]}}The data that was obtained can provide a rough location of the device. Another major issue with this device is the ability to update the ring volume as an unauthenticated user:
POST request:
POST /app_update_property HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 66
Host: api.gdxp.com:8100
device_sn=EKDB_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ring_volume=72Response:
HTTP/1.1 200 OK
{"resultCode":0,"msg":"","content":[]}And the ability to access and view images from the device also proved to be as easy as guessing the filename via the date/time stamp alongside the serial of the device:
http://britain.oss-eu-west-1.aliyuncs.com/EKDB_xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/2020xxxxxxxxxx.jpgAs outlined by the last two issues, this device in particular was riddled with poor access control flaws on the backend API.
Data sent to other countries
The following post request was discovered when investigating the ‘CloudEdge’ mobile application, used by the Victure doorbell. The privacy of the user is significantly impacted, as it was found that the Victure mobile application was sending out the user’s Wi-Fi details to a web server when viewing the feedback section on the CloudEdge application.
POST /log/putAppLog HTTP/1.1
Accept-Language: en-US,en;q=0.8
User-Agent: Mozilla/5.0 (Linux; U; Android 8.1.0; en-us; Nexus 5X Build/OPM6.171019.030.K1) AppleWebKit/533.1 (KHTML, like Gecko) Version/5.0 Mobile Safari/533.1
X-Ca-Timestamp: 1598991919706
X-Ca-Sign:
X-Ca-Key: 32f96f26-1c74-4990-9f15-6e9175ca2497-2000792169
X-Ca-Nonce: 985980
Content-Type: multipart/form-data; boundary=40b90230-0748-4f74-ae5d-cf0dc2b0e026
Content-Length: 9364
Host: app-logs.meari.com.cn
Connection: close
Accept-Encoding: gzip, deflate
Content-Disposition: form-data; name="userToken"
Content-Length: 47
--40b90230-0748-4f74-ae5d-cf0dc2b0e026
Content-Disposition: form-data; name="phoneType"
Content-Length: 1
a
Content-Disposition: form-data; name="t"
Content-Length: 13
1598991919701
Content-Disposition: form-data; name="sourceApp"
Content-Length: 1
8
Content-Disposition: form-data; name="countryCode"
Content-Length: 2
US
Content-Disposition: form-data; name="appVer"
Content-Length: 5
2.2.3
Content-Disposition: form-data; name="lngType"
Content-Length: 2
en
Content-Disposition: form-data; name="phoneCode"
Content-Length: 1
1
Content-Disposition: form-data; name="equipmentNo"
Content-Length: 0
Content-Disposition: form-data; name="userID"
Content-Length: 10
1000396085
Content-Disposition: form-data; name="appVerCode"
Content-Length: 2
81
Content-Disposition: form-data; name="logFile"; filename="1598991919682.json"
Content-Type: application/octet-stream
Content-Length: 7818
{"userid":1000396085,"model":"Nexus 5X ：8.1.0","monitor":[{"eventid":"030101","time":"20200901104946"},{"eventid":"020101","time":"20200901104948"},{"data":{"selectdevicetype":"2"},"eventid":"020102","time":"20200901104949"},{"eventid":"020201","time":"20200901104949"},{"eventid":"020301","time":"20200901104951"},{"eventid":"020401","time":"20200901104952"},{"data":{"password":"","ssid":"" },"eventid":"020402","time":"20200901104953"},{"eventid":"020501","time":"20200901104954"},{"data":{"QRCode":"s:"",p:"" ,t:"null"","des":"","resultCode":"1001","url":"https://apis-us-west.meari.com.cn/app/token/get"},"eventid":"020603","time":"20200901104955"},{"eventid":"020601","time":"20200901104955"},{"data":{"QRCode":"s:"",p:"",t:"null"","des":"","resultCode":"1001","url":"https://apis-us-west.meari.com.cn/app/token/get"},"eventid":"","time":"20200901104956"},{"eventid":"","time":"20200901105354"}
<-- Removed for bevity --> The Wi-Fi SSID and password was sent to a server located in the USA that is operated by cloud provider in China. From research into the other doorbells this behaviour was unusual, as none of the other mobile applications were seen to be doing this. It also raises more questions about why these details need to be exported at all; this data can easily be used in conjunction with open source tools to map the physical locations of the Wi-Fi networks that are being uploaded to these servers to create a map of active devices for further profiling using resources such as https://wiggle.net.
Domain logs are sent to: https://app-logs.meari.com.cn
We acquired this information using Frida and performing a cert pinning bypass on the mobile application to be able to observe the backend activity. During these investigations it was possible to see the domain name that the mobile application was directed to and communicating with, this was maerai.com.cn which redirects to https://www.mearitek.com/.
Mearitek are a separate company to Victure but seem to be the creators of the ‘CloudEdge’ app that the Victure doorbell utilises. It also seems unusual behaviour that Victure haven’t created their own application for their devices and are using another company’s infrastructure and software to host their devices.
Hardware
Ineffective Doorbell Mounting Security
The main method for these devices to be secured was using a mounting bracket that was either glued or screwed onto a flat surface and the device sat in the mounting bracket. It would be easy for an attacker to quickly release the doorbell from the bracket and steal the device in under 10 seconds and some of the devices had no method of notifying the user until it was too late that it was turned off, or moved.
Only one of the devices tested had a pressure trigger that started an alarm once the device was moved. It is possible to quickly remove the batteries or power cable and disable the device.
It would be possible to use an inexpensive 2.4GHz jammer to disconnect the doorbell from the Wi-Fi network and subsequently steal the device from its holding bracket for further analysis.
Device Analysis
All of the doorbells had the option to use a micro SD card to store recorded video and audio samples when the doorbell motion sensor was triggered. An inexpensive 128GB microSD card (approx. £20) can hold up to 72 hours of recorded material, allowing a malicious actor to profile daily occurrences in the local vicinity.
In addition to the memory card an attacker can copy the firmware from the device with relative ease. All the devices analysed used small flash chips that stored the firmware for the devices that are easy to analyse. There is a non-destructive method that would require knowing the pin layout for the flash chip and then attempting to copy data from it using a device such as a Bus Pirate. Or the destructive method which involves removing the flash chip with a hot air gun and then analysing the chip with a Bus Pirate
Once this information has been obtained it can be analysed quickly and if the firmware isn’t storing data correctly it is trivial for the attacker to not only find the Wi-Fi BSSID but also the plaintext Wi-Fi password to access a network. Once the attacker has Wi-Fi details and the knowledge of when a user will be in or out of their property they can continue their malicious activity.
Insecure Firmware Update Procedure
Once a device is “in the wild” there needs to be a method that the manufacturer can deploy software updates to the mobile application and device firmware. Usually mobile application updates are handled by the appropriate application platform (Google Play, iOS App Store, etc.) but device firmware upgrades can be more difficult to handle. The firmware is potentially some of the most sensitive information a manufacturer of IoT devices can develop as this controls the hardware (camera, physical Wi-Fi module, etc.) and needs to be protected.
During research into the mobile application and the ability for remote firmware update it was discovered that calling a specific URL would also download the binary file required for updating the firmware. In some of the cases investigated these URLs were only using HTTP and were unauthenticated, allowing anyone with knowledge of that URL to download the firmware for analysis.
Once the firmware was obtained it was possible to analyse it using a range of binary analysis tools (Binwalk, Ghidra, even Linux tools as simple as Strings) to break down the firmware structure and discover sensitive information contained within the firmware including hardcoded credentials, IP addresses and break down the firmware to understand the firmware and its potential weaknesses.
Using these methods of firmware analysis it was also discovered one of the devices hadn’t been patched and was vulnerable to the KRACK vulnerability which was released in 2017 and patched quickly because of its critical impact. This shows that the device is either over three years old and has been vulnerable while sat in storage until point of purchase, or worst case, the device has been manufactured more recently, but with negligence through use of known vulnerable (and patched) components.
Attack Scenarios
Saved QR code information leakage
Some people use their smartphones to take screenshots of different things, while most modern smartphones also automatically backup photos.
Let’s imagine a malicious actor has gotten access to a laptop or PC and has complete control over the device or has been able to obtain the credentials to log into 3rd party accounts such as Google or iCloud and access underlying data (many attacks in previous years have used these techniques) and a random QR code (from a previous screenshot / image backup) is harvested as a part of this infodump. The attacker can then quickly decode the QR code and extract the plaintext BSSID and password for the Wi-Fi network instead of having to attempt a deauth and/or evil twin attack.
Gain Persistence Access to a network
The ability to gain access to a network exists if a device can be accessed remotely via the Internet. Attackers could use the shared hard-coded username and password to log in to exposed control panels, perform a malicious firmware upgrade and create a gateway into a victim’s network.
Looking at this type of attack, it can be seen as a bit far fetched but considering the Victure doorbell could be remotely logged into, has a range of methods to upload firmware and can be enumerated on the Internet; these properties render this type of attack possible. Once the attacker is on the target network, it can be considered game over if the network is flat and has little to no protections in place.
Forensic recovery
The brackets to connect the devices to the wall are pretty flimsy, some only have a clip to connect them and are very easy to either unhook or rip from the wall. Once the device is in the hands of a malicious actor they can quickly remove the batteries or disconnect the microUSB cable that was powering the device. Some of the mobile applications did not have the functionality to notify the web app if it was removed from the clip, only one of the cloned devices had a pressure switch that would trigger the alarm, but it could be quickly deactivated by removing the batteries. Once the attacker has the physical device they can remove the SD card and view all the recorded data and then copy the firmware.
Firmware manipulation
Due to the lack of encryption for the firmware it is very easy to reverse engineer the firmware and extract not only the structure of the underlying OS but also extract the BSSID and plaintext password of a network and then log into that network; this presents opportunity to target other devices on the network. Similarly, an attacker could introduce new services to the device such as SSH or telnet to provide a remote connection; this would require the end-user to re-authenticate the doorbell with the app but potentially unknowingly connect a trojaned device to their network.
Conclusion
Cloned Devices
Which? approached NCC Group to understand if a collection of devices that closely resembled vulnerable doorbells that had been previously tested were clones or new devices with their own security issues. It can be confirmed conclusively that the majority of the devices analysed were clones of the Victure doorbell which already had a range of security issues associated with it. There was also evidence to show that the mobile applications that were being used by multiple cloned doorbells were clones of each other as well. The Ubox and Ubell mobile applications looked identical when downloaded and their general operation was very similar. By investigating the firmware binaries it was shown that the code that was being used by these devices was closely related, and that multiple copies, along with the hardware design and manufacturing of the devices were similar.
Pairing Issues
All of the QR codes that were generated exposed sensitive data, either in the form of the username and password to access the device stream or the Wi-Fi network credentials. There were also consistent issues with the doorbells using a sonic audio pairing mode that could easily be circumvented. There are more secure methods of generating QR codes that would protect the data being transferred, or there are alternative methods such as Bluetooth pairing.
Access Control
In terms of access control, the worst case was seen on an unbranded device that enabled the ability to change a volume setting without any authentication and with just the knowledge of the device serial number. Deploying zero access control shows a lack of understanding and protection of sensitive user information.
Poor Doorbell Mounting and Forensic Recovery
Throughout the investigation into the smart doorbells a consistent issue was the lack of security regarding the physical mounting of the devices that then led to additional issues. Most of the cloned devices lacked any physical switch that would be triggered upon moving the doorbell. The other devices then either had a delay in notifying the mobile application or could quickly have the power source (battery, microUSB) removed; analysis of the mobile applications suggested consistently that notifications were delayed and possibly never arrive for the end-user to be notified. Once a doorbell was stolen the forensic information contained within would allow an attacker to retrieve the Wi-Fi BSSID and password with relative ease. There could potentially also be hours worth of video and audio recordings that would allow an attacker to profile the victim’s home or surrounding areas depending on what was in view of the doorbell video.
Undocumented Features
A number of undocumented features were found to cause more harm to the operation of the device than good. For example, the Victure doorbell had the ability to manage and control the device by logging into the device. The credentials used in this attack were obtained from the flash memory which pointed to the fact that all devices running this firmware used the same hardcoded values. What makes this worse is finding a number of devices on the Internet hosting this login panel.
Overall the issues we have seen during this research have outlined a poor approach to developing secure IoT devices. There are still devices being developed, shipped and sold with an array of issues let alone these issue being cloned into knock-off, copycat devices.
Credits
NCC Group consultants who worked on this research and blog post were:
- Guy Morley
- Paul Taylor
- Dale Pavey
- Ivan Reedman
- Anna Reedman
Further Research
In part 2 of this blog series we will be covering a range of smart plugs and their use of ZigBee.
The main article written by Which? based on our research is linked below:
