In October 2017 Amazon announced a new service called Amazon Key for Amazon Prime customers.  The service offers to securely deliver Amazon Packages inside members’ homes. The delivery person will unlock and lock an external door using a compatible smart lock and Wifi-connected Amazon Cloud Cam — which captures the transaction. The Amazon Cloud Cam could be considered a security feature since users can watch the deliveries live and replay the delivery at a later date.

On November 16, 2017, our team at Rhino Security Labs demonstrated that by using known security vulnerabilities in WiFi, we could launch a successful Denial of Service (“DoS”) attack against the Amazon Cloud Cam and Locking components, preventing both the video recording and streaming functions. The technique used in the demonstration is a known and viable attack for all Wifi-connected devices that simply disconnects the device from its router. Amazon Key is a connected device that provides interior access to people’s homes, and when the device is disabled, the Amazon Key application does not alert the user to any error, issue or failure. In fact, if a user watches the camera view from within the app during the attack, it appears as if the Cloud Cam is merely buffering.

What piqued our interest in Amazon Key is the simplicity of the attack and the potential security implications it could have for users.

Before Amazon Key was publicly available concerns arose around its security but there were no specific details or demonstrated attacks to add legitimacy to the security unease. Even before we received the device, we hypothesized many possible attack vectors that are already known problems with Wifi connected devices. It was only after external verification that we were able to validate the failure of the Amazon Key’s security controls.

This security-related oversight of the Cloud Cam device (Amazon Key edition) is alarming. There doesn’t appear to be fail-safes for when the camera is not functioning. For example, a potential fix for the problem could be including local storage on the camera to continue filming while a connection is lost.

To summarize the security flaw, an attacker sends a command to de-authenticate the Cloud Cam device from the wireless network. The camera is then considered offline and it attempts to reconnect to the wireless network. This simple action renders the camera useless while it recovers its connection.

What makes the Amazon Key case interesting is that the Amazon Cloud Cam itself functions as the router for Amazon Key. The cam will route commands to the door deadbolt, record deliveries, and give a real-time view of events. Because the Cloud Cam is necessary to send Amazon Key instructions to lock the door, an attack on the Cloud Cam can be considered an attack on the Amazon Key because it affects Key’s functionality.

While the camera is offline, there is no immediate notification or recorded log to inform the user that the camera was down. At the time of our tests, the app does send a notification that the camera is offline roughly 5 minutes after the device loses its internet connection. As the camera recovers, the application displays a previously recorded image while it appears to be buffering — but without indicating that anything is actually wrong with the device. Additionally, the camera doesn’t record and store video locally. Therefore, anything happening in front of the camera when it is offline is not recorded.

When the Cloud Cam is offline, not only does the camera fail to display what it is seeing, but it also cannot route commands to lock or unlock the door. This could pose a problem if the Cloud Cam is disabled during key moments of a transaction where a third-party doesn’t have an actual key to lock or unlock the door.

Amazon advertises three compatible locksets with the Amazon Key service. The Kwikset 914 Smart Code and Yale Assure locksets each have an externally facing keypad and lock button to manually control the locking mechanism of the door. So, even if the Cloud Cam is disabled, a third-party could still feasibly operate the locking mechanism externally.

The Amazon Key compatible Kwikset Convert does not have this functionality. The Convert attaches to the back of the existing door deadbolt. From the outside, a user must have a physical key to lock or unlock the door if the Cloud Cam is offline. Without a physical key, an authorized third-party (delivery person, SMS authorized user) that unlocks the door would not be able to relock the door if the Cloud Cam is nonfunctional during the delivery.

In our demonstration video, we simulate an authorized third-party entering a home and delivering a package. Upon closing the door, the third-party disables the Cloud Cam. With the signal jammed and video feed frozen, the now intruder re-enters the home and gets out of view before stopping the signal jamming attack, allowing the Cloud Cam to recover. The door then locks with the intruder still inside the home.

The user will see the trusted party initially entering and leaving, which is recorded along with a valid unlock and lock with the application logs. However, the user will not see the attacker reentering the home. The only indication that something might be wrong is the brief time the camera freezes. But this is normal functionality and wouldn’t always be seen as malicious.

Cloud Cams (and other devices) can be narrowed down by reviewing the first 6 characters of a MAC address, indicating the manufacturer ID. The Cloud Cam – and all other Amazon network connected devices – begin with FC:A1:83, identifying them to anyone within Wifi range. The example below, you can see the MAC Address of our Cloud Cam on the wireless network.

Because this is an attack on 802.11 and the Wifi framework, the attacker does not need to authenticate to the network to identify the devices — or bring down the Cloudcam, for that matter.

Using the open source, publicly available tool Aircrack-ng, the attacker sends a command to de-authenticate the Cloud Cam using the Mac Address of the Cloud Cam and the wireless router it is connected. You can read more about Aircrack-ng and de-authentication on the Aircrack website.

A single de-authentication command will disable the camera for a brief window of time. Our tests (as of 11/15/2017) showed it took anywhere from 20 seconds to 3 minutes for a camera to reconnect. However, it is possible to carry out the same attack repeatedly to disable the camera for longer. The de-authentication command includes a value that the attacker can set to repeat the number of de-authentication packets to send to the device.

The issue presented above can’t entirely be fixed with a software patch, as the hardware relies on a protocol with a known weakness (Wifi). One proposal is to notify users sooner once the camera is disabled. However, Wifi is known to be unreliable and sending a notification when it is down could annoy users. The better choice to fully remediate the underlying issues requires changes to the hardware. By adding local storage to cache videos when the signal is interrupted would prevent the attack above.

At Rhino Security Labs, we believe that consumers should know the risks associated with their purchases and make a determination if they’re willing to accept those risks. To reduce or remediate the risk this vulnerability imposes would require local storage on the camera to cache video while the camera is disconnected.