Interesting, but if that is the actual lock (from their twitter video) then it seems like it would be trivial to cut with bolt cutters.
Sure, but that isn’t quite as elegant is it? :)
Nope, but definitely quicker, cheaper, and simpler :D
I really enjoyed your write-up of this, but I also (strangely, enjoy) find that Occam’s razor is still relavent sometimes.
I’m reminded of the fingerprint lock that is “invincible to the people who do not have a screwdriver”.
That one is also distinguished by the way it broadcasts its key to everything nearby and that they made the location of every lock publicly accessible online https://www.pentestpartners.com/security-blog/totally-pwning-the-tapplock-smart-lock/.
I do wonder how you “know” if you’ve built a properly secure device. I guess something like TLA could help you write a spec saying something like “in order to change ownership you need to have existing login access”?
The modeling is probably the most difficult part, but I don’t know what tool would be best to ingest a model with some constraints here
That’s the crux of the issue. We know exactly how regular locks work, how lock picking works and how to mitigate that with modern locks. As the final line says, “Do not buy a smart lock”, the attack surface is enormous and a lot of these companies are only “security experts” on the surface.
I get the impression that it’s pretty hard indeed. There are always things you don’t model (with timings as an obvious example). Of course, this thing seems to be broken in a more obvious way.
2nd July, 2019: CVE-2019-13143 reserved
No response from vendor
2nd August 2019: Public disclosure
So… This is essentially an invitation to start using the exploit in the wild?
No? What about it reads that way to you?
Nothing (and of course you don’t mean it that way), but I’m just not sure if it’s a good idea to disclose an exploit if it’s not fixed yet. At the same time, I’m not in security and I don’t know the common accepted practices. I was hoping that someone would patronizingly explain why it’s OK to do so in response to my deliberately provoking comment ;)
I believe the general idea is that you give the vendor time to fix it before you disclose it publicly, but if the vendor does nothing at all, then it is better for the user to know about the vulnerability, so they can attempt to mitigate it (e.g. in this case by not using the ‘smart’ ‘lock’).
u/Thra11 has answered this, but to add to that, public disclosure acts as a ditch effort to get the vendor to notice the issue and hopefully, address it. It’s a hard choice to make, especially when releasing exploits that could compromise thousands of user accounts. But at the same time, the users (at least a few) will learn of it and stop using the lock.
There’s a good likelihood for any vulnerability that’s disclosed that there are people who already are aware of it and are presently exploiting it. Disclosure allows people to avoid being exploited and takes power away from those who hope to use it.