
IoT Smart Lock Vulnerability Spotlights Bigger Issues - axsharma
https://www.tripwire.com/state-of-security/featured/tripwire-research-iot-smart-lock-vulnerability/
======
neom
While not IoT - Lock Picking Lawyer has a bunch of "smart" locks that he owns
with very little effort. [1] My favourites are these RFID locks [2][3] and
this fingerprint lock.[4]

[1]
[https://www.youtube.com/c/lockpickinglawyer/search?query=sma...](https://www.youtube.com/c/lockpickinglawyer/search?query=smart)

[2]
[https://www.youtube.com/watch?v=z4lVylO7y5U](https://www.youtube.com/watch?v=z4lVylO7y5U)

[3]
[https://www.youtube.com/watch?v=XXW27KKHtc8](https://www.youtube.com/watch?v=XXW27KKHtc8)

[4]
[https://www.youtube.com/watch?v=pTys_WYBOLE](https://www.youtube.com/watch?v=pTys_WYBOLE)

------
nullc
It's really a shame that "IoT" locks are destroying the reputation of
electronic locks.

A well constructed electronic lock can be considerably more secure against
non-destructive attack than any mechanical lock. Yet IoT locks continually
have gross vulnerabilities that allow undetectable bypass-- and issue that
even moderately good mechanicals locks don't really have (even picking usually
leaves evidence).

~~~
bsder
> It's really a shame that "IoT" locks are destroying the reputation of
> electronic locks.

Original funding from IndieGogo. LOL. Yeah, that's a bunch of folks who know
_lots_ about security. And as soon as I see MQTT (or any other abstraction
layer above UDP or TCP/IP) I know that doom follows.

The worst part about this is that making secure locks when cloud connectivity
is available just isn't that hard. Use a Curve25519 library. Everybody (lock,
phone, cloud) generates their own keys and exchanges public keys facilitated
by an originator set of keys from the cloud installed at manufacture time
(this prevents getting man-in-the-middled at configure time without having to
go through complicated public-key exchange algorithms that might get cracked).

Commands are always encrypted using public keys and always involve the cloud.
Return no ACK (your ACK is that the lock unlocked) so you can't brute force.
Done.

If you really want to be paranoid, the lock and phone should exchange a
separate set of public keys that encrypt the commands uploaded to the cloud
that get forwarded to the lock. Now, even compromising the cloud doesn't let
you unlock the door.

A secure lock without Internet connectivity is quite a bit harder because you
have no unimpeachable "oracle" to present a point of "truth" that can be
relied on.

~~~
CorrectHorseBat
It's not that easy: Now the lock doesn't work when either your phone or your
lock has no internet connection, or the cloud is down. Also, when the
manufacturer gets hacked they can remotely open any lock. (And you need to use
a phone that is manufactured by the same company as the lock?).

I'd say there are better ways to prevent man-in-the-middle attacks during set-
up, which are IMO not really a problem anyway. You have bigger problems if
that is a part of your threat model.

>If you really want to be paranoid, the lock and phone should exchange a
separate set of public keys that encrypt the commands uploaded to the cloud
that get forwarded to the lock. Now, even compromising the cloud doesn't let
you unlock the door.

But now you're doing public key exchange which you wanted to avoid, why then
involve the cloud at all?

~~~
bsder
The point is that you break the process into two pieces:

1) Key exchange is mediated, encrypted and authenticated by the cloud.

2) Command exchange is always encrypted and uses the already exchanged keys
between the phone and lock. The commands may or may not go through the cloud
as an intermediary.

> It's not that easy: Now the lock doesn't work when either your phone or your
> lock has no internet connection, or the cloud is down.

I don't find the requirement for the pairing process to be cloud mediated to
be very onerous. After the pairing process, you can decide if the reliability
requires the lock to operate if the cloud is offline.

And you probably need at least intermittent internet connectivity or you can
never revoke access.

> And you need to use a phone that is manufactured by the same company as the
> lock?

It's called an app. And generally, yes, the manufacturer makes you use their
app to open the lock.

> I'd say there are better ways to prevent man-in-the-middle attacks during
> set-up, which are IMO not really a problem anyway.

I don't agree. The problem is that pairing is _ALWAYS_ annoying and nobody
wants to put a button on the lock to change its mode (or want to be able to
automate the addition of people to the lock control). An attacker being able
to arbitrarily activate the pairing process locally gives a _much_ bigger
attack surface--forcing this process to involve the cloud cuts that surface
down significantly.

> But now you're doing public key exchange which you wanted to avoid, why then
> involve the cloud at all?

It's not a public key exchange. It's a private, encrypted key exchange with
keys that got mediated by the cloud. That's a _much_ harder system to attack
from the point of view of an attacker.

~~~
CorrectHorseBat
> I don't find the requirement for the pairing process to be cloud mediated to
> be very onerous. After the pairing process, you can decide if the
> reliability requires the lock to operate if the cloud is offline.

If the cloud is gone you're still stuck. Companies do go bankrupt or get
hacked. Anything that requires an app or cloud access is a big no for me. I'm
trying to make my life more secure and comfortable. Relying on a zillion
different companies and their (buggy) apps is the opposite of that.

> I don't agree. The problem is that pairing is ALWAYS annoying and nobody
> wants to put a button on the lock to change its mode (or want to be able to
> automate the addition of people to the lock control).

You're still going to need that button for pairing with the bridge and/or your
local Wi-Fi.

If someone has local access to the buttons inside the lock they don't need to
crack my lock, they are already inside. I consider the risk that someone
spends the time figuring out my lock system, somehow gets access to the
pairing button and breaks in on another point in time lower than that the
cloud gets hacked with the access to all their locks with a list of the
addresses sold to a bunch of burglars.

------
cortesoft
No lock keeps out a determined attacker. I bet fewer people could carry out
this attack than people who can pick a normal lock.

~~~
nullc
There is a big difference between attacks usually that leave signs of
tampering and attacks that leave no evidence.

Picking normal locks leave easily discovered evidence. I once even detected a
lock at my office had been picked when I put my key in the next morning and
noticed it felt different!

(I learned it had, in fact, been picked-- because after that happened I asked
on the company chat and one of our security people responded that he'd picked
it the night before for reasons)

~~~
RHSeeger
I'm curious about the specifics. From my experience, picking a normal lock
works very much the same as using a key; you're just relying on the fact that
the inside of the lock is the same "shape" as the key to put the tumblers in
the correct location.

~~~
nullc
Normal lockpicking technique has you put tension on the lock so that (ideally)
one pin is under sheer and the rest are free. You use your tool to push the
binding one to the position allows the cylinder to turn slightly then move to
the next. So this usually leaves marks on the pins than you can see if you
take the lock apart.

Usually while picking you'll also scratch up the pins and keyway in a way that
a key won't. You can also end up with the pins a bit cockeyed.

You can also turn it in directions that it can't turn with the key in it, and
on some cylinders you can turn it the wrong way and have all the pins fall
out!

You in many locks you can also end up with it 'locked open' where you have to
pick it again to be able to get a key into it.

I think in the incident I mentioned the cylinder was left in slightly askew
which made it feel odd to insert the key. I'm not sure if someone who hadn't
picked a lock before would have recognized something was unusual just from the
feel.

~~~
SAI_Peregrinus
If you know what you're doing when picking you shouldn't be leaving externally
visible marks for most locks (though heavy tension with a loose bottom-of-the-
keyway or improperly-sized top-of-the-keyway tension tool will mark the lock).
And it's pretty easy to re-lock the lock afterwards to be identical to a lock
that's never been picked.

Of course you can take a lock apart and examine the pins & chambers for signs
of picking, but that is a bit extreme if you don't suspect it.

So while it is possible to leave external signs of picking, it's not
_necessary_ , and often indicates something went wrong with picking.

~~~
nullc
Right. But when stuff goes missing there is a big and insurance relevant
question if the stuff was taken by someone with authorized access or someone
who broke in... having a locksmith disassemble and inspect the lock is useful.

Maybe extremely careful picking would pass, but at least my efforts always
mark up the pins. :)

Compromises in electronic locks tend to be a lot cleaner.

------
jmrobles
This is the funny part:

"the [cloud] server does have strong security” --> oh, good

"and that users’ data have been encrypted by the MD5 algorithm --> WTF???

~~~
antihero
How are these people even in 2020?

------
tehlike
Homeassistant + yale zigbee/leave lock. No need for cloud at all. If you care,
you can vpn to your house.

------
axegon_
I've fiddled with IoT very little, yet with the little experience I have, I
must say, I'm not surprised at all. And I think the main reasons are the
ecosystems around IoT: they are a mess - no standards, no common communication
protocols, none of that. So it is a bit of a "every man for himself" kind of
thing. I have a few smart devices at home and it really boggles my mind how
much they differ from one another when they connect to the wifi. Some fire up
a tiny http server which I would assume is used as a rest api, some use udp
connections, each one uses the most random port you can imagine, the developer
documentation for all of them is nothing short of crap. I think the security
vulnerabilities will start going down once:

1\. Everything goes open source.

2\. Everyone settles on a standard way of communicating between those devices.

Sure, vulnerabilities won't disappear completely but they will go down. At
this stage, I feel like they aren't exploited due to lack of interest rather
than good will or lack of opportunities.

~~~
red_admiral
I'm pessimistic about the open-source part. The lesson I took from
OpenSSL/Heartbleed is: even if something's very widely used and people could
spend some collective effort on it (or just contribute some funding), that
doesn't mean anyone will. The Linux Core Foundation funding after that, and
google contributing its own expertise through BoringSSL, made OpenSSL a lot
more secure but it took a wake-up call.

~~~
Nasrudith
The sad thing is OpenSSL with heartbleed unpatched would still be an
improvement. Even though the entire related class of buffer bugs shouldn't be
a thing.

------
exabrial
> and that users’ data “have been encrypted by the MD5 algorithm”

Literal head-desk. They ought to be sued. There is so much wrong with that one
statement.

------
axsharma
Got an IoT smart lock? Watch out for hackers unlocking it from anywhere!

A security vulnerability discovered and responsibly reported by Craig Young of
Tripwire exposes flaws in U-Tec UltraLoq locks, among other devices.

