And a story of a frustrating disclosure process with Amazon
Amazon Key — the smartlock product that requires you to disable your home alarm system for the service to work.
Background and poor disclosure experience
At the end of January, I postulated a fun way to weaponize the deauth attack that Rhino Security Labs found and disclosed last year. Especially after seeing how much Amazon downplayed the existing research. It didn’t take much imagination to figure out how to go from “it requires an evil delivery driver” to “anyone with a raspberry Pi.” A professional researcher saw this and reached out to me, offering to broker a disclosure with Amazon. Unfortunately, this attempt failed. Amazon turned down the offer by demanding a working PoC be made for them. In the same breath, they also said that they have no bounty or other reward pathways. I wasn’t interested in a reward, but this level of arrogance was off-putting.
So, I made the PoC.
PoC video: https://twitter.com/_MG_/status/960269383774842881
I automated the attack into a raspberry pi that would detect Amazon Key hardware and attack when a door event occurred. I also added a bit of deception into the attack by replaying the sound of the lock motor to add to the illusion of a successful re-lock. In the process, I found that there was another remaining vulnerability if you adjusted the specific time at which the deauthentication attack was executed. It seems that Amazon didn’t really think about the disclosure from RhinoSec, they just found a way to stop the PoC. The adjusted timing caused the consumer app to incorrectly fall back to displaying a “locked” state.
I posted the PoC video with technical details redacted. Amazon reached out to me the same day and I started helping them understand the attack. I was impressed with the security response team. They would later ask for code, which was a bit frustrating in context of the initial “lol we won’t give you anything but do work for us” interaction with Amazon. This team could do a lot more if Amazon structured their disclosure process better. There was a window of time I didnt hear back for about half a day, meanwhile Amazon PR started talking about the attack and saying it was a non-issue. Annoying.. But I promised Amazon that I would withhold technical details until they released a fix. A day later, PR would completely explain the entire attack to Forbes even though a fix wasn’t rolled out.
Technical
And that brings me to now, a few hours after Amazon dumped the info. There is nothing left to the imagination anymore on the technical side. Amazon also says this issue isn’t really a risk. So here is the breakdown of the attack:
- Scan for wireless frames that contain the known OUI of the amazon wireless camera. The OUI is the beginning of the hardware address that identifies the manufacturer of a network interface.
- Once found, sit and monitor the rate of frames coming from the camera. A delivery event turns the camera on, which creates a flood of frames. Monitoring for this does not require you to be connected to the network.
- Once the frames increase, you send a specifically timed deauth to the camera, disconnecting it (and the lock, which uses ZigBee to talk through the camera). The accuracy of this would likely be increased by monitoring from ZigBee traffic instead.
- If the timing is right, you prevent a response from the lock informing the consumer app from knowing that the lock event was successful. For whatever reason, the app was not created to handle this error condition. The UI is also nonresponsive, which opens up the opportunity for an inattentive app user to believe they actually pressed the button requesting a re-lock.
- For added deception I decided to replay the sound of the lock motor re-locking at the appropriate time.
- Optionally, the dropbox can send a notification back to the attacker over a 3G connection or nearby wifi network to alert the attacker that the house is open.
Conclusion, Threat Models, and Amazon Response
At this point, the lock is left open until the Pi is powered off to stop the deauth. Amazon says the driver app is different than the consumer app. It has more security added. I’d be happy to audit the driver app, but why doesn’t the consumer side have the same security? Amazon says the fact that the homeowner gets quickly alerted of a disconnect is a sufficient safeguard. How is that alert actionable? Can I call the police to do a wellness check on my lock? What happens if I randomly deauth the Amazon Key throughout the week to generate alerts that desensitize the homeowner? Amazon says there is process for the delivery driver to prevent abuse. Why are you putting so much responsibility on low wage workers to be the last gate in a bad security model? How often has this process been audited for completion rates or holes? Amazon doesn’t talk about the consumer use of this app either. My PoC showed off a delivery driver opening the lock, but this could easily be a homeowner or guest dropping something off in their house or even just quickly running back in to grab something before driving off. Amazon also doesn’t talk about the fact that they require your house’s alarm to be turned off for a driver to use the Amazon Key without issue.
