Blink XT2 Camera System Command Injection Flaws

James Sebree
Tenable TechBlog
Published in
5 min readDec 10, 2019

Blink home security camera systems, owned and operated by Amazon, contain a number of security flaws that could allow attackers or other actors to compromise the devices.

Blink’s home security camera solutions are some of the more popular offerings in the IoT security space today. Marketed as budget-friendly and long-lasting, these cameras are intended for use by everyday consumers and small businesses. In a security advisory posted recently, we disclosed a number of security related-findings regarding the Blink XT2 home security camera systems.

In short, Tenable Research discovered three-ish vectors of attack that allow a full compromise of the sync module, which could potentially allow attackers to take further action against an end user’s entire account and associated cameras. The discussion below provides an overview of these findings and their impacts.

Vulnerability Details

To start, compromising the devices via physical access is trivial. As we’ve covered in the past when looking at similar devices, it’s common for vendors and manufacturers to leave debug ports and other such connectors enabled for production runs of the devices. While intended for developers, there is nothing preventing someone else from connecting to these interfaces.

Generally speaking, this isn’t the biggest deal in the world. It’s useful for researchers, homebrewers, and other people that like to modify their devices or poke around a bit. In Blink’s case, however, we want to emphasize the ease of connecting to the sync module’s debug port.

For many devices, to access these ports, you’d need to disassemble the whole device, solder wires to some internals, and then make all your connections. For Blink, connecting is as simple as popping off the front cover and attaching to the already provided header pins. From there, connecting is as simple as supplying some hardcoded credentials, which happen to be “root” and “willoXXX” where XXX is the last 3 digits of the devices serial number (easily found in large text on the device itself).

See header pins in the bottom left
Shell available via serial connection

Next up, we found some command injections on the sync module via the cloud communication endpoints for providing updates or obtaining network information. When checking for updates, the device first obtains an update helper script (sm_update) from the web, and then immediately runs the content of this script with zero sanitation.

Retrieval of helper script and immediate execution

If an attacker is able to MitM this request (either directly or indirectly — through some sort of DNS poisoning or hijacking), they can modify the contents of this response to suit their own needs or desires.

Similarly, a function called “get_network()” exists in other helper scripts on the device. While this function does not appear to be used during the course of normal operation, if it ever is, another command injection point exists due to failed sanitation. We have manually triggered this function in order to verify this flawed functionality. Below is the full context of this function as it exists on the device.

Vulnerable “get_network()” function

Finally, we disclosed some additional command injections via the wireless network configuration parameters. As above, the flaws here are simply due to a failure to sanitize user-supplied input in some of the internal management scripts.

Sample entry-points for command injection via wifi parameters

These parameters are all passed and executed without sufficient sanitization, which allows command injection as the root user. The “sanitize()” function seen in use above is easily bypassed. For example, entering the following from the settings prompt in the mobile app is enough to start an SSH server on the sync module:

What does this mean for consumers?

In terms of the first flaw mentioned, which requires physical access to the device, this isn’t a major concern for everyday consumers. In order for an attacker to exploit this flaw, they need to be able to directly interact with the device for at least a few minutes. The most obvious attack scenario for this flaw would be some sort of insider threat — babysitters, house or petsitters, Airbnb guests, or anyone else with somewhat privileged access to your home.

Similarly, the flaws disclosed regarding WiFi configuration parameters are unlikely to be abused by a malicious actor because they would require access to these parameters at the time of device setup. These flaws, along with the unprotected UART interface, are more likely to be abused by researchers or tinkerers rather than someone with wholly malicious intent.

The other findings, though, do have a significant impact. While remote exploitation of the command injection via network endpoint flaws is theoretically possible, it’s highly unlikely due to many external factors. These attacks are most likely to happen directly from a user’s home network. The best thing consumers can do here is to keep tabs on the devices that are connected to their network and check on any irregularities that may crop up.

What can consumers do to protect themselves?

The biggest thing consumers can do to protect themselves from these flaws is to make sure their devices are always updated to the latest versions. Due to the way the Blink cameras and sync modules connect to and communicate with the Blink cloud infrastructure, updates are generally automatic and strictly enforced.

Unfortunately, detecting already compromised devices is tricky since it is possible to bypass or fool these update checks. Other than manually inspecting the devices for rogue functionality or verifying firmware integrity, there isn’t much the typical consumer can do on their own to check if they are already compromised.

Looking Forward

Throughout our research process, Tenable’s Zero Day team dug into the Blink API to enumerate useful endpoints and commands that can be utilized to control cameras, view stored pictures and videos, add rogue devices to a user’s account, disable or remove devices, and obtain potentially sensitive information. Additionally, we developed methods to intercept and manipulate commands used in radio communications to and from the cameras/sync modules.

We will be releasing this information as well as a more detailed write-up of the above findings sometime in the future.

Conclusion

As we’ve said time and time again, IoT surveillance devices are a new norm. From video-enabled doorbells to internet-connected baby monitors, consumers need to be aware of the tradeoffs and risks these devices introduce if they choose to welcome them into their homes.

--

--