Smart Doorbell Security (Part 1) (Threat modelling)

Having acquired a ‘smart’ doorbell, I wanted to assess whether it was safe for general usage.

This series will detail my analysis of the device and its security controls. I do not intend this article to cover all areas of the device’s security, but rather a focused review on key areas of interest (to me). Surprisingly, this device uses encrypted flash and contains an custom U-Boot handler to perform hardware decryption via AES, which I uncovered during this analysis.

Let’s start with an introduction of the device and its associated Android application.

Device Overview

The device looks like this:

It’s comprised of the following visible components:

• A camera
• A motion detector
• A speaker
• A microphone
• A pressable ‘bell’ button
• A TF card slot (presumably for storage of video/image)
• A micro-USB charging port
• 2x Lithum rechargable batteries
• A ‘reset’ button, located on the back of the device
• A square button that ‘alerts’ if ‘de-pressed’ so as to signal removal from a wall mount, for example
• Two power-points to allow an external power supply
• A plug-in chime
• A number of LEDs

Both IOS and Android applications are available to interact with the hardware.

The doorbell itself is designed to allow viewing of the device’s camera, as well as the use of its other components, such as the microphone from both over the internet and within the local network.

Turning on the device, it works as follows:

• The LEDs light up
• The doorbell audibly notifies you that it is awaiting pairing data, in form of wireless credentials.
• The application transacts wireless credentials via wave format/sound to the doorbell.
• The application allows you to register an eight character password, to interact with the device.
• The application allows you to ‘connect’ to the device, either locally via LAN or via Cloud and given the earlier set password, view its settings, firmware version and change password, update firmware etc.

Application overview

The Android application offers a fairly simplistic user interface:

Within the interface are small number of functions via the settings menu, some more notable than others, including:

• Firmware version checking and updating
• Toggling Cloud storage/back up
• Changing password

In terms of version, we’ll be using is “XBell_v1.0.106”.

Threat modelling

Having used the application for a while, I understood that it allowed communication with the device both over the Internet, via the local network (LAN) and allowed firmware updates. With this in mind, I wanted to threat model to ensure I don’t miss key areas during my analysis.

For threat models, I usually diagram a given system’s architecture, noting what’s known and what I’d like to see in terms of security controls, using Micheal Henriksen’s Draw.io threat modelling libraries, which can help to highlight areas of concern.

I’m primarily concerned about poorly designed authentication mechanisms, credential exposure and potential backdoors, given the device sits outside of a secure perimeter and is externally accessible. My threats are malicious actors within the same local network as myself, as well as those that could physically use the device to access sensitive data, such as wireless network credentials for example.

Of course, the device also uses Cloud storage and push notification services, cloud functionality is, however, outside the scope of my assessment.

In the next part of this series, we inspect the pairing and authentication mechanisms to determine their robustness in line with the concerns outlined above.