Airbnb's preferred smart lock vendor accidentally bricks 500 door-locks

Re:Airbnb's preferred smart lock vendor accidentally bricks ... by joshribakoff on Monday August 14, 2017 @03:10PM (#15011696)

our app updates via the app itself. This gets regularly bricked but we have a Cronjob where we can put bash commands in a .txt file and upload that to our server, and devices will execute it regularly. This has always saved the day but apparently the past developers before me used to drive around with a USB stick on a regular basis, to re-image bricked devices.

I can also confirm the wifi problem. Not knowing if a device is bricked or just on bad wifi is a huge problem you have to somehow account for. It was terrifying before I built tools to keep track of which devices those are

[ Parent | on HN ]

Re:Airbnb's preferred smart lock vendor accidentally bricks ... by mysterydip on Monday August 14, 2017 @04:17PM (#15012434)

Your end devices execute arbitrary code put in a specific url on your website? I assume this is a purely in-house device and not one in the hands of consumers?

[ Parent | on HN ]

Re:Airbnb's preferred smart lock vendor accidentally bricks ... by agwa on Monday August 14, 2017 @04:28PM (#15012552)

Executing arbitrary code put at a specific URL on a website is exactly how software updates work. As long as it's properly authenticated, it's fine.

[ Parent | on HN ]

Re:Airbnb's preferred smart lock vendor accidentally bricks ... by ramses0 on Monday August 14, 2017 @06:00PM (#15013402)

Slightly, but not exactly. Any remote code execution could lead to "example.com/run_this.txt" being filled with "evil_hacker.sh". However if "run_this.txt" were somehow signed and verified prior to downloading (with signing keys kept off the distribution box) then it's much safer.

Practically, there are tons of instances where executing code downloaded from URL's is how software is updated, but again most of those instances are human-driven, not automated.

[ Parent | on HN ]

Re:Airbnb's preferred smart lock vendor accidentally bricks ... by joshribakoff on Friday August 18, 2017 @02:08AM (#15043955)

Our main issue is if someone tampers with content stored on the server, which gets copied to devices. For example someone replaces a JPG with the wrong JPG that is something offensive.

If someone gains access to our server, its already game over. Being able to execute code on the devices is then moot because we were already hacked & potentially lost all credibility in the industry.

To everyone saying not to execute code at URL, this is how oh my zsh, and many other open source projects are installed. And SSL should prevent any kind of MITM attacks. The point about keeping keys off the server is a good idea, but is not always possible when the server needs to dynamically send content down to the device. The server would need to access the private key in order to sign this content dynamically. For statically built executables this is a good idea though.

[ Parent | on HN ]

Re:Airbnb's preferred smart lock vendor accidentally bricks ... by com2kid on Monday August 14, 2017 @05:44PM (#15013265)

Normally there is a bit of code signing involved.

Just in case the domain name lapses. (Or for any of a hundred other reasons why having a system that reads plain text commands from the network is a bad idea)

[ Parent | on HN ]

Re:Airbnb's preferred smart lock vendor accidentally bricks ... by joshribakoff on Friday August 18, 2017 @02:33AM (#15044033)

If someone is not competent enough to keep their domain renewed, what's to say they're competent enough to keep private keys secured, and not lose or leak them. Then again I saw something on here recently about someone hijacking the whole .io TLD, so what you're saying is a real issue.

[ Parent | on HN ]