Lockpicking in the IoT (33c3)

33c3 preroll music

Herald: Ray, are you ready?
Ray: I think I’m ready!

Herald: Alright he’s ready…
Let me introduce you, Ray!

“Lockpicking in the IoT”, or

“Why adding a Bluetooth Low
Energy device sometimes

isn’t a great idea”. Here we go!

applause

Ray: Okay, so, welcome everybody
to “Lockpicking in the IoT”,

or the internet of things that were
never supposed to be on the internet.

Okay. There’s a small overview of what
we’re doing. I’ll introduce a little bit

what is this about, show you some hardware
porn – for the hardware lovers among you –

then look a bit deeper in the PCBs of that
hardware – for the electronics guys –

then we look into communication on
the internet – this is this modern thing

everybody wants to have in his coffee
machine – and then we go for

the wireless interface, and see
how difficult or not difficult it is

to attack them. And last but not least
we will look into Android app hacking

– I have to say I’m mainly focusing on
Android but I’m pretty sure if you’re more

the Apple guy there’s similar techniques
available to go for your Apple app.

But for most devices there’s both
– so even if you’re using iOS you can hack

the Android app to get the infos.
And then the talk is over. Okay.

The very important thing first: the
disclaimer. Basically I want to say

I just tested this on my locks, I don’t
say it’s working on everything,

I don’t say it’s a general mistake by
somebody, might have changed,

I might be wrong, I just
show my research. Okay.

This is basically what we’re talking
about. We have some kind of

smart or not-so-smart device which is
talking over Bluetooth Low Energy

to your smart, or not-so-smart phone.
Which is usually talking, using TLS

and HTTP to the ‘Cloud’.

So it’s not just locks. The talk is called
“Lockpicking” because that’s the thing

we’re actually going to attack. But
the techniques here shown work

for basically all of these
Bluetooth Low Energy devices.

There are e.g. different light bulbs.
I found some interesting reports

on light bulbs that don’t use
any form of authentication.

So you can connect to your neighbor’s
light bulb and change a color, or

turn it on or off. So, finally,
Blinkenlights in your neighborhood!

mumbles and laughter

Then of course there’s cars. Everybody’s
talking about cars today. I just heard

a talk about cars. They’re not really
using Bluetooth Low Energy.

But still they use an app and are
controlled over the internet, so,

it’s kind of on-topic. Then there’s
vibrators. I mean, unsafer cyber sex

never has been easier. Actually I don’t
have one of those, so, if anybody has,

please bring one over to play with it.
But I’m pretty sure they have high-class

security. laughter
And then there’s button pushers.

I just learned of that yesterday and
I thought “WTF, a button pusher!?”

laughter

applause

This is a Bluetooth Low Energy device
which you can communicate to and

make it press a button. Here it’s pressing
the Delete key on my notebook.

So finally I have a Bluetooth LE
enabled Delete key on my notebook.

laughter
Very, very helpful. Of course, if you

add that to your door opener at home
you can do it again – lockpicking.

We haven’t hacked that yet because
I just saw it yesterday but it didn’t look

very encrypted. It has some secret, some
shared string, we didn’t understand.

But possibly this congress
we will look into it.

Okay, then there’s cars. I’m not
sure, who read this message that

Tesla had a big app hack? Nobody? Oh.
I thought, everybody read it because

it even was on Heise. And it obviously is
a very big vulnerability, Elon Musk has

to get better on this and
everybody’s stealing these things…

how are they called…
oh yeah, these ‘smart cars’.

And they even have colors! So who
wouldn’t want to steal one of those?

laughter

The bad news is actually that wasn’t
really a hack. What they showed is

that the app is able to start the car.
That’s in the manual.

So what they told is: “Yeah, but if I hack
your phone I can start your car!”

Then they realized, “Oh, you also need the
password because for starting the car

the app actually asks for the password
again.” – “Yeah but if I hack your phone

I can install a fake app that asks for
the password; and if you enter it

I can steal your car!” – Oh, surprise!
laughter

I mean this is not the kind of hacking
we’re talking about. And they then

suggested the app should be more
protected against reverse engineering.

What would that change in this aspect?
I can create a fake app without even

decompiling the original one. So,
of course if you don’t have security

on your phone working, if you install
apps that are not secure your data

is not secure, and your Teslas get stolen.
But I didn’t see anything in this ‘hack’

actually being a hack.
So, while talking about…

applause

Spare your applause for this one!

Talking about obfuscation. That’s really
a thing some people understand differently

than I do. I try to say [to] people:
“security by obscurity does not work!”

So if you obfuscate your app, possibly
it slows down researchers like us.

But the people doing that for money, who
want to sell exploits, they will still put

the energy into it. And sell their
exploits even more expensive.

And the exploit will even be longer out
there because the independent researchers

won’t find the vulnerabilities that fast.
The idea is: good crypto does not have

to be secret to be secure. So, no, please
don’t obfuscate your apps better.

Build your protocols better. But as said
before I didn’t see any aspects there

in Tesla. Possibly they should make it
obvious that you can start the car with it

and make it ‘disableable’, and
what… things like that, but

it’s not a security issue. Okay.

So let’s go back to locks. Because,
actually the talk is called “Lockpicking”.

So what do these smart locks usually do?
Of course they can be opened.

Usually your… with your phone near your
lock you put something on the lock

and communicate – the lock opens.
Optionally you have to press

something on the phone, so it’s
a 2-step process to unlock,

which is actually a quite good idea
because of some obvious scenarios

which will work otherwise. Then – and
this is different from normal locks –

they can be shared to friends. It’s
a big feature. They try to convince you

why these smart locks are so smart.
When I’m not at home I can send

somebody the code, and give him the
possibility to open my bike shed

for just one hour. Because I can, of
course, revoke that at time restrictions.

So that’s what the big advantage is,
compared to a traditional lock.

Except, of course, it’s to be much more
secure because you can’t pick it anymore.

And then those obviously have some
failsafe mode in case your phone breaks

and whatever. You can enter a click code,
and can enter a code by some buttons

or something to open it without the
phone. But that is nothing we’re going

to look into today. So from these basic
ideas, of course, there come some basic

attack vectors. What I could
try to do: I could try to bypass

the sharing restrictions. So possibly
go in a different time window.

I could change the time on my phone,
probably. Would that work?

Things like that. Open the lock after
it was revoked. Of course then

that’s what everybody thinks about when
talking about Bluetooth: I could try

to get the keys. From sniffing
somebody’s Bluetooth LE connection.

That’s something we’re going to do today.
Then this is what I was talking about

why the ‘2-button-press’ is a good idea.
You could relay opening codes.

If you have the ‘instant-open’ feature
I could approach you, pretend to be

your lock, your phone sends me an OPEN
command, I could relay it to your lock,

completely somewhere else, and it would
open. So I think this is something

you can’t really stop except with
some very tricky mechanisms.

Possibly ‘timing’ or some… things like
that. So this ‘instant open’ feature

is possibly not the best idea. Then
we have the option to attack the lock

or app software directly. I mean, it’s
software. So it will have buffer overflows.

It might have other weaknesses. It could
just do not verify some things. If I tell

I’m another person - does it really check
if I have the rights, and everything?

But this is something – I think the only
thing – I don’t have in this talk today.

Because the other methods
worked already. Okay.

Going to look at the hardware.
So, basically, if you’re

a lockpicker or some other reverse-
engineer, if you get a new hardware

you want to take it apart. If you
can’t take it apart, you can’t open it

you don’t own it. And here’s – if you
want to do it yourself – these tips

how to open it. The NOKE is very nicely
built. When you have legally or

legitimately unlocked your NOKE you can
disassemble it without doing any damage

to it. [You] just need a screw driver and
it completely comes apart. Very nice design.

The Master Lock – you have to
drill out 4 rivets. This is a bit sad

because after that it won’t be a very good
lock anymore. But it’s not a problem

because it isn’t before,
from my experience.

applause and some laughter

And then there’s the Dog & Bone lock,
which is a lock I just got recently.

Its a little bit tricky to open but you
don’t have to do a lot of damage.

If you have it opened you can pull out
a pin in the back – thank Jan (?)

for finding that out. And then you can
remove screws and it really comes apart

nicely. So how do these locks
look, now? This is the NOKE.

So basically you see a PCB, you
see a normal lock body like here,

with a shackle. There’s a motor at the
PCB. The motor turns some locking element

in here. And if it’s in the right position
the lock opens. For the NOKE there’s

a very nice paper by the SSDeV member
Michael Hübler. I have a link at the end

of the presentation.
And neither he nor me did find

any mechanical bypasses for that lock.
So the mechanics look okay.

Then there’s the Master Lock. It is very
similar, but I have to say they invented

this mechanism with the motor in this
locking element first. It has 4 buttons

on the PCB which you can use to enter
a code. Has 2 CPUs, pretty standard design.

And here are the rivets you have
to drill out to make it open.

The Dog & Bone is a little bit more
clumsy. It’s a bigger lock. It comes apart

in quite some pieces. What I really liked
was that motor with that gear box. I think

it’s like 1:2000 or something. So it
really gets a lot of power from the

very small motor. So what does it do with
it? It turns this element, and this element

retracts these 2 spring loaded locking
elements which are locking the shackle.

If you’re a lockpicker you will ask:
“Spring loaded? Seriously?

Have you ever heard about the term
‘Shimming a lock’?” ‘Shimming a lock’

is inserting some metal at the shackle,
and pushing back the springs.

It’s a very standard method for padlocks
in the 5 Dollar range, I would say.

Locks starting at 10..15 Dollars
or Euros or whatever, in that area

usually can’t be shimmed anymore.
When I opened the Dog & Bone lock

I instantly realized: it’s
spring loaded, it is shimmable.

A short search on Google
found out that Mr. Locksmith,

a lockpicker from the U.S. who
does some good Youtube videos,

found [that] out months before.
And of course, it’s shimmable!

You put in some thin metal sheets
– he built them from a cutaway

of a soda can, puts them
in and the lock opens.

But this is not a 5 Dollar lock. This is
an 80..100 Dollar Bluetooth padlock.

And you shim it with cut metal.
Okay. No need to go into

the Bluetooth Low Energy for that one.
laughter

And, as a small teaser: I also didn’t
say there’s no mechanical bypass

for the Master Locks. But
we’ll come back to that.

Okay. The electronics. This is the
electronics of the NOKE. Basically

you see there’s one CPU, and something
that’s called an ‘H bridge’ which is

used to control a motor. All the rest
is pretty standard electronics, so,

very simple design.
The Master Lock has 2 CPUs,

has the buttons on the PCB,
also quite simple electronics.

And this is the MCUs. The interesting
thing I see is there’s a very common chip.

It’s the Nordic nRF51822.
I find it basically everywhere.

It’s in light bulbs, it’s
in 3 of the locks I have here.

Or 4, if you count the Ivation
and Nathlock [not] as the same.

Only the Master Lock
uses MSP430, which is…

The nRF is a… basically ARM core.
The MSP430 is a much smaller chip,

it’s from Texas Instruments, and it’s
a very low power consumption chip.

It was also used in the previous
non-Bluetooth LE electronic lock.

But it’s basically also a normal
microcontroller, and you can program it.

So, program it. That means you can
just use any ARM Flash board.

I used the ST-Link interface from an
STM32 dev board we had in our hackerspace.

And interfaced it to the chip
of the NOKE padlock here.

So e.g. using OpenOCD, but…
there are different tool chains (?) but

this is one where you find some info on
the internet, how to use it with the nRF.

Using OpenOCD you get an
interface to connect to the chip,

and then you can issue commands
like ‘Probe the Flash in it’;

you could read the Flash, you
could write a new firmware to it,

and stuff like that.

With the old Master dialSpeed padlock
which is pre-Bluetooth-LE but

already electronic, a few years ago,
I think 4 years ago we presented

about that one, that was not read
protected, you could change the firmware,

you could actually get the codes from
reading the flash, and you could access

the Flash content without opening
the lock. So that was really funny.

Not usable as a lock, but I re-flashed
it to a Simon Says style game where

you have to repeat the sequence it shows
you. Funny lock for your hackerspace.

Unfortunately, or fortunately…
No, I would say ‘unfortunately’,

the NOKE firmware was read protected.
Because there’s no need for it.

The NOKE firmware Flash ports can’t
be accessed without opening the lock.

So you don’t lock somebody out
by read protecting it, except for

the legitimate owner. But okay, it was
read protected, and I was saying: “Oh,

decompiling firmware, that’s hard
work anyway, let’s skip that one.”

But of course you could use these flash
interfaces to write own firmwares

to these locks. Possibly make them open
source one day. Or do something else.

Or just use them as cool dev
boards. With some actors on it.

So, let’s go for the first
interesting thing, I would say.

The communication with the ‘Cloud’.

So your phone speaks to some servers
which is provided by the vendor

of your hardware usually. And
it’s usually a TLS encrypted link

using HTTP. Over this link the application
on your phone sends login data,

gets back from the cloud the information
about the lock. So you can install

your app on a new phone, enter your
login credentials and instantly use

all your locks. Or the locks that were
shared to you. Usually these apps also

send events to the cloud, when you open
your locks. So if you share the lock

with someone you can see on your other
phone that he opened it, and possibly

where he opened it. And things like that.
And of course also data is edited,

if you add a new code to it or something.
So this is sent over the link.

So, some people would say: “Oh,
but TLS encryption is secure, isn’t it?”

Of course, usually it is. There are flaws
which you hear about from time to time

at these conferences. But that’s not the
problem here. The problem is – but

it’s not a problem, it’s nice for us
researchers – you own the phone

with the app. You control the app. You can
even modify the app. But owning the phone

you control the TLS trust store,
with the certificate authorities. So

you can install a new CA and trust your
own servers. People could try to

prevent this using key pinning in the app.
But, again, you also control the app.

You can change the app, you can remove
the key pinning. So, basically, breaking

into this TLS is something the vendor
has to expect. It’s your device,

it’s your communication. You can
listen to it. So, and the nice thing

– and this is what I’m trying to tell all
of you here in this talk – these things

are not difficult. There are nice
available tools; and if you have some apps

which do some things you want to know –
install such a tool, watch your app doing

transferring data, and look what your
apps actually communicate. Actually it’s

quite interesting to see what your phone
communicates to Google all the time.

I realized it: one of these apps is
telling Facebook when I started,

every time. What the Fuck?? But you easily
see it. What you do is you install e.g.

mitmproxy, it’s a small hell of Python
dependencies, but it’s usually installable

on a Linux, and even on a Mac machine.
Haven’t tried it on Windows but

I’m pretty sure there’s options for that.
And you install it as a web proxy, so,

you change the internet connection of your
phone, and say: “Oh, this Wi-Fi has to use

a proxy, enter the IP of your proxy…”
And mitmproxy creates fake certificates

on the fly. So whatever side you access
it creates a new certificate looking

the same, signs it with the fake CA, and
you can install the fake CA just

by going to http://mitm.it/
So, man-in-the-middle it.

And there’s a link to install a fake CA
on your phone. So that’s actually really

[done] in, like, 5..10 minutes, with
compiling of the Python stuff 15 minutes,

and you have a working man-in-the-middle
setup and can watch your communication.

This is what the app looks like. So
we see here a few POST requests

to the NOKE app. We get replies;
actually we see funny 403’s here.

I’m not sure why it’s doing that. But
okay. But this is what the NOKE app

does on startup. And of course we can
not just see the requests, we can look

into the request itself. And it’s e.g.
a good way to recover your password.

Possibly I should have blurred it here.
So if you have forgotten your password

you just sniff your communication. It
also works for your Play Store password,

usually. Usually they use a token
but some time it’s renewed.

So every app that has a password
and sends it to the cloud – you can

recover it with that. And from
this login you get data back.

And in the NOKE app it’s
usually done like I send

login, with user and password,
and I get a token back.

And then all following your request
I just have to send this token, and

then I’m authenticated. So that’s
an okay mechanism I would say.

So. What do we get also? We
have a GETLOCKS key, and

when we call ‘getlocks’ we get
the information about our locks.

So this basically is an ID of the lock.
This is a lock key. There’s something

to remember: 0137 – we’ll see that later.

You see the MAC of the lock,
you see a picture URL

where the application shows me
the lock – if I have multiple locks

I can assign different pictures
to it. And this is a quick open code

where I can push on the
shackle to open this lock.

So this is all no hacking because
this data I’m supposed to know.

It’s my lock, I can know the information,
then it’s not a big problem.

But it’s interesting to see what it’s
doing to understand how it’s working.

Then we have the next
thing, the ‘shared locks’.

This is more interesting, possibly because
I see: “Oh, I’m allowed to use it all day,

starting at that day,
starting at that time,

ending at that date, at that time”.
And this lock has a key,

and there’s another key.
And another MAC.

So, the nice thing is, the
lock does not have a time.

The lock does not know
when I’m allowed to open it.

So all I need is this key. And the nice
thing also is I don’t have to manipulate

the app in any way. I can use Mitmproxy
to change the data on the fly.

So I just tell Mitmproxy,
please change 2016 to 2066,

then the reply comes back, and then the
NOKE app thinks “Oh, he’s still allowed

to use that”. Of course the NOKE people
were clever and do an online check.

Which actually means you can only
unlock a lock if you have a shared lock.

Your own lock you can use offline. But a
shared lock you can only use when you

have internet. Not good if it’s the cellar
or something. But it does an online check,

it asks: “Can unlock?” and the cloud
answers: “Yes, success, can unlock”.

Of course I can also fake that! So this
is completely bogus; it’s unnecessary

to be online. I could do it offline. If
I want to hack the lock I can do it

in the cellar. Only the legitimate
user has to be online.

So the sharing feature of the NOKE already
is broken just with the Mitmproxy tool.

Really, that’s not big hacking. They
could have thought about that. But okay.

So, once somebody shares
a lock to you, a NOKE to you,

you have this key and you can
use this key from then forever on.

Using the original app. That’s the nice
thing. You don’t have to change it.

One thing which is positive about the
architecture here, the key that they use

for sharing is a different key than you
have to operate your lock. That means

with this sharing key I can not
modify the lock. I can’t re-key it,

or change the click code, or things
like that. So I just can open it.

And they have an option to change the
key of the lock. So I can go to my lock

and say “Re-key!”, and the they do a new
key. But for that I have to go to my lock.

So that’s nothing if I share the lock to
you from Congress, and the lock is

somewhere in… Salzburg! Then that
doesn’t work. So not really helping.

Possibly one time keys or something like
that would be a better option, or just

some challenge/response mechanism.
If you have to be online, why not.

But that’s something for the future.
Currently lock sharing is not very secure,

and I would advise you to keep that in
mind when you use the Sharing feature.

Oh, regarding dumping firmware: as I said
before a firmware was not dumpable

from the NOKE. The Dog & Bone I didn’t
even try to dump the firmware because

it was shimmable. But they sent me
an URL in the CONNECT where I can

download the firmware.
And if you… laughs

laughter and applause

Again, I don’t consider this
a vulnerability. I think if I own the lock

I should be allowed to read the firmware.
If you download that it’s an actual

hex dump of the firmware. It looks like
directly what you would flash on the chip.

So if you want to do some firmware
reverse engineering that’s a very easy

starting point to get the firmware from
the internet, disassemble it, play with it,

flash it possibly to your own dev
board without even owning the lock,

to play with it. Why not. Okay, so,
so much for the app communication.

You can do quite a lot with it already.
But we want to go a little deeper.

We want to go for the Bluetooth Low
Energy level. So the communication

between my phone and my lock.
Or my vibrator. Or whatever.

So Bluetooth Low Energy is newer, but
actually easier to sniff than Bluetooth.

There’s a talk called “With Low
Energy comes Low Security”

if you want to have an introduction to
that. You find it on Youtube. Basically,

it has 3 security modes. But the most
common used are NON and ADHOC

which is like almost none security. And
the third one would be pairing with a code

which is usually a 6-digit number.
If you listen to that pairing you also

own everything. This improved with
Bluetooth Low Energy 4.2, or Bluetooth 4.2

which includes a new Low Energy standard.
But this is not implemented very commonly

today, and won’t be in the
very near future. Because

not so many devices support it. So for now
Bluetooth Low Energy is an easy target

to get into research. There’s available
tools for it like the Ubertooth One

by Mike Ossmann. The Adafruit
BTLE sniffer for… very cheap.

And you can build your own one by flashing
a firmware available from Nordic

directly to any dev board
with this chip you have.

So this is the hackerspace entry point.
If you have this stuff lying around…

Otherwise I would recommend going
for the Adafruit Sniffer. It’s orderable

even in Europe, very easily.
So not a big problem.

But the very cheap option is:
get a 3..5 Euros dev board

like this from China,
use your STM32 programmer.

I have another board here which is
a serial interface. But you could use

your normal FTDI USB-to-Serial,
also. And then this board

is identical to the Adafruit Bluetooth
LE Sniffer, for like 5 bucks.

Okay. Talking about this research.
This is nothing nobody did before.

Somebody like e.g. Rose & Ramsey did it at
DEF CON and presented quite a nice talk

where he analyzed a lot of locks. He had
like 15 locks of it, and 12 of them broken.

So it was really plain text passwords
on the Bluetooth LE, for the Quicklock,

iBluLock, Plantraco Phantomlock.
I hope that’s correct.

I don’t claim that to be true. But he told
[it] in the talk. He found replay attacks

on these locks. So you can just resend
the same code that you saw before,

even without understanding it. But he
stopped where it became interesting.

And instead of that posted
this slide. Which I hate.

He wrote about uncracked locks. And
the first one was the NOKE padlock.

And for the time line: at that point
I already had disclosed to NOKE

our findings. Which you will see today.
So the NOKE company knew about

the lock being completely broken on the
crypto layer [at that time]. But they see

this talk by Rose & Ramsey and post
a blog post: “NOKE just one of the few

Bluetooth locks to pass hacker testing”…
SERIOUSLY?? They were notified!

And they… we had active communication
about them changing the crypto protocol.

Possibly the social network people are
not so close with the technical people.

But okay. So, let’s crack it. Using the
Nordic Bluetooth LE sniffer firmware,

which is… unfortunately the easiest way
to use is on Windows. But you can use it

with Python also on Linux. And
Wireshark integration isn’t that nice…

So if you have a Windows, or Windows
VM it’s the more easy entry point.

Here you have a text interface where
you say: “I want to sniff to this device”,

then you get a lot of lot of lot of packets
here. Mostly ‘discovery, discovery, discovery’.

You have to look for the bigger packets.
This was a bigger packet with some payload,

and it contains a very long string
which looks completely random.

So I see from phone to NOKE there’s
random; from NOKE to phone there’s random.

Looks actually encrypted. And NOKE
is claiming they are using AES128.

So I didn’t even try to understand
what I see here because

if it’s AES encrypted you
won’t find any meaning in it.

So let’s put the sniffing aside for
a moment. We can’t sniff to the data.

We can get this communication off the air.
But for the NOKE we can’t do anything

with that. So let’s go for app hacking.

There are different approaches. One
– the easiest… not the easiest but

the first one we did –
is manipulating the apps.

So you can get an APK from your phone very
easily with ADB. You don’t have to have

a rooted device for that. You can just
enable Devel mode and copy the APK over.

There’s lots of tutorials on the internet
how to do it. It’s basically 3 calls

on the shell. And those APKs can easily
be disassembled with a tool like SMALI.

You can change things in it, like
a URL. You can change values.

Then you can re-assemble it, self-sign it,
and put it again on your phone.

One thing you can do with that is
change the app to use a different URL

for its communication. And that’s actually
quite a nice idea. Because we saw before

we can completely understand this
protocol. It’s not a complicated protocol.

It’s sending some requests, and it’s
getting some JSON responses. I can

write this in a Python script with a few
100 lines, and fake their server.

So I actually could run my NOKE lock – if
it would be having good crypto, but okay –

on my own server. Not connected to their
cloud, but build my own NOKE app and

have it communicate with my NOKE server.
Why not. Possibly in the far future

NOKE doesn’t exist anymore, who knows?
It happened before to other companies:

the servers are gone – your hardware is
gone. If you understand the protocol,

if you have sniffed it before you can
reimplement it and continue using

your hardware. Except for that I wouldn’t
like to have my locks in the cloud!

We actually used this method during
the analysis of the NOKE lock

to change a random number generator
in the app to always return ‘42’.

Thanks to Sec for that one. He did
a binary patch on the MIPS binary on it.

We just put it in and had a nice
random number to spot it easier

on the communication. The other thing
is you can decompile these app APKs.

You get it, again with ADB. Run it through
a decompiler like Jadx which you can

install on your PC. You can download
it from Github. Or if you just want

an easy decompile you go to
an online decompilation service.

They say: “Please only use it for
legitimate purposes”, but we do!

And yesterday Sec was very annoyed
by the Adblocker blocker they have.

But if you ignore that then it’s
very easy to just upload an APK,

get back the source code. And then,
basically, you have Java source

which you can read, you can search,
you can grep… Oh! You can grep.

So. We were looking for AES!
laughter

applause

Yeah, everybody is laughing at that
slide. But there’s 2 things to mention.

First of all this is not all of our
research. This is just the beginning.

Then it became difficult. The other
thing is this key of course is very silly.

They actually use 01 to 15
as an AES encryption key.

But if they would have used a real random
pre-shared key I still would have found it

that way. So, actually, it’s not really
less secure. It’s just possibly left over

from development. I have no idea
why you would use that key! But still

– even a better key, I would have found
it in the source code. Because it’s

a pre-shared key. The lock knows it.
The app knows it – has to know it

because it’s pre-shared. So, yeah…
But still it’s very funny that they have

this silly key in there. And we were
actually wondering quite a lot:

“Oh, but what blockchaining mode
do they use? How do they use AES?

Is there an initialization vector?”.
I don’t know.

Took us quite a while until we realized:
it’s simply just one block! If we use

that thing that we sniffed earlier
and just run one AES decryption

with the key 0001 etc. we get something

which includes our 42 numbers. Oh!
Our ‘random’ numbers turn up!

How are the chances for that? No.
So, actually this key decrypted the thing

we got from the wire. So we thought:
“Success!” and NOKE is cracked!

Unfortunately it only worked for the
first 2 messages, and all we saw

in these 2 messages is our ‘random’
number, and in the answer

another obviously real random number,
because we didn’t patch the lock.

The next messages from that on
again were completely scrambled.

So we had to do some
more reverse-engineering.

Unfortunately, or fortunately – to make
it a little more interesting for us –

this APK from NOKE doesn’t
only include the Java source.

It has some shared object files.
So, binaries, which are compiled

with some other compiler, probably C.
Luckily those were in there for Android,

for multiple architectures. And one of
those – I don’t know who is using Android

on x86, but obviously it exists – so
we had all the libraries also in x86.

Which we could run through a commonly
available disassembler. I started doing

this object dump, and things (?) a little
bit. But it’s really hard to read, and

you don’t come so far with it. So,
big thanks again to Sec and to e7p

who helped me a lot during Easterhegg
this year, which was a quite nice event,

where we did some lock hacking. And they
were staring with me at IDA Pro dumps

all the time to find the key exchange,
and finally, it worked out.

So, all the assembler is very hard
to read, I think. But we see there’s

a parseCmd function we found.
Actually they had the labels in there!

Which again is not the vulnerability,
it just made it easier for us

to spot the stuff. I don’t think
that’s bad from them. It’s okay.

So we found this parseCmd. It actually
calls an AES decrypt function.

It gets a little bigger and bigger
and bigger. There we find

– I actually can’t read it from here very
good – this was the Create Session key.

This sounds very promising. It was
called ‘CreateSessionKey’. Hm.

Might have something to do with the things
we saw before. And it has this in a loop.

And this loop is actually something people
could understand if they can read some

x86 assembler. It’s a loop of
4 iterations. And it’s XORing values

from one array to another.
So it’s basically XORing 4 values.

And this is the core component of the key
exchange. This is the 4 byte numbers

that we saw earlier. My 42 42 42 42…
and the other one coming from the lock,

are XORed together, and then there’s
some more magic done. So basically

the app sends a random number to the lock,
the lock sends a random number to the app.

And from that there’s a session
key calculated by adding XOR

of these 2 numbers to the
middle of the original key.

So you have this original
key which we saw before.

And you add this result onto it. So.

We saw from the app our 42 44 42.
Of course if you have the real app

running that would be still real random.
But this doesn’t make a difference.

It just was easier for us to see
it’s the same every time, so…

It helped a little bit, but not too much.
So the lock sends the key, those 2 values

are XORed together; and then they are
added onto this silly pre-shared key.

I don’t know why they’re doing that!
I mean, they could have at least added it

to different parts of it, and they
would have more entropy in it, or…

I’m not sure who sits in the cell and
does some coding, and thinks:

“This is a good key exchange!”?
You can’t really look into these minds.

But okay, so, we can do something
in our head. We see here is 0xFD,

we add 0x05 to it. So it rolls over. This
is why here’s the Modulo operation.

And get the 0x02. We have 0xBB
here. We add 0x06 to 0xBB.

If you can calculate hex you see it comes
to 0xC1. Etc. So everything that changed

in the key is the middle 4 bytes.
Which is actually another vulnerability.

Because it means even if for some reason,
which I really can’t imagine because

this exchange is done everytime you
open your lock. It’s not something done

on the first time or done once per phone
or something. Everytime somebody opens

this NOKE this whole sequence is run
through. It connects to the lock, sends

a random number, receives a random number,
the session key is calculated, and using

the new session key the rest of the
communication is done. But just in case

you did miss the first packets for some
reason: if you have a real attack scenario

where you can’t replay it it might happen
that it’s scrambled. Then it’s still

4 bytes changed in the key, so we can
brute-force the new key. By knowing

the old one and brute-forcing those
4 bytes. So I think that’s doable

on a modern machine without
bigger problem. So really,

not the cleverest key exchange.
But even if it would be better

it wouldn’t really help. Because there’s
no asymmetric crypto in it, there’s

nothing preventing us from following it.
If you exchange a session key

over a pre-shared secret, somebody
knowing the pre-shared secret

will always be able to follow it.
So, they have to do some big changes

there to make it proof against sniffing.

We have this new session key and of course
we have to verify what is happening.

We have the next message on our
wire. We’re decoding it with the new

– very cool – key we have. And we
get something that doesn’t look

completely random. We do it with multiple
ones and see some structure in it.

It’s always… strange guttural noises
I think I pasted the wrong thing here,

actually. Very sorry for that. You have
to imagine a different message here.

Encrypt that using that key and you
would see what would be up here.

But here would be this random we got
from the air. We de-crypt it with that,

and get this. And this dissects into an
op code which is always at the third byte.

And after the op code we actually see
the lock key which you remember from

one of the first slides – 013755 –
this is the key from my lock.

So we now got the key from the air,
and have full access to the lock.

Bad luck for NOKE.

applause

So 06 is just one of the op codes. When
you browse through the Java source

you see much more op codes that might
happen. So e.g. there’s the Rekey option

which you send to the lock, and the lock
starts to re-key to regenerate the key,

send back the new keys. You can
unlock – which is what we just saw.

Get the battery level. Set a new Quick
Opening Code. Can reset the lock.

Can do a firmware update. That looks
promising! I have the idea, we will see

this op code in the near future.
And you can enable ‘key fob’

which a small device is which you can
use to open the lock without a phone.

So you can send commands
to pair those, and add them,

and get locks of this (?). So this is just
a few, we haven’t played with all of them.

The SetQuickCode,
I think I sniffed a few…

Yeah, but that’s basically the things you
can do, and you can decode all of them

with the message shown before.

So some history of
the vendor notification.

We did this on the Easterhegg [2016].
Everybody knows Easterhegg is Easter.

So this was in April [2016].
Possibly it wasn’t

the best idea to send
them on April, 1st. But…

laughter

No, they replied and took it seriously. So
they actually very instantly told us they

like the research and everything.
They knew their crypto isn’t perfect,

but the product has to get out. And they
were working on a new protocol, they sent

a few details of that. We don’t have full
details so far, so we can’t really tell

if the new protocol is very good. But
it looked, from the idea, a little better.

They’re bringing out a Bike U-lock which
is not out yet. And it’s supposed to have

the new protocol from shipping.
We will see. A thing which I found

very funny is I downloaded a new [NOKE] app
in November, and it has a major update

in the screen: the ‘Rekey’
button is now hidden!

So, remember, that’s the only button
which saves you from someone

you shared a lock to, to lock him out.
So this button now is hidden.

Possibly not the best idea. Possibly
people weren’t understanding it.

But it can be enabled in the ‘Advanced
Settings’ menu. So, no problem.

But they just recently told me that
they’re planning to actually fix that

in January. So we’re actually
really in a Zeroday here.

So the locks are still vulnerable.
But 8 months, sorry… I…

the conference is now, we couldn’t
change that! laughter

Ray laughs
applause

If you use such a NOKE lock I still
want to say I like the hardware.

It’s quite a nice hardware. Possibly
write an open source firmware for it,

build your own crypto, during
the time. Or just don’t use it

for real valuable things. Or use your
Aluburka or other shielding while

opening it, I don’t know. But just be
aware if someone sniffs your communication

using his 5 Dollar dev board
he probably knows your codes.

So, yeah. So much for the NOKE.
This is not really the end, it’s just

the beginning of the end section. Because
we still have one mechanical bypass left.

You remember that earlier I mentioned
also the Master Lock doesn’t have

no mechanical bypass that we found. If you
remember Chaos Communication Congress

4 years ago – you can remember from
the Rocket standing exactly here –

points to picture on slide we did
a presentation on this first Bluetooth…

not Bluetooth, on this first electronic
padlock by Master Lock, where we had

a nice mechanical magnet attack,
which was found by Michael Hübler

by very cleverly drilling a hole,
observing the motors, acting with magnets…

and found this special move
which opens the old Master Lock.

And we reported that back then.
So 4 years ago we told Master Lock:

“Oh, your padlock can be opened
with a magnet, this is not very good”.

But this was a 30 Dollars padlock, and…
oh my god, could be done with a magnet.

So this is the new one, and they changed
something. Actually it’s something they

told us back then that they’re planning
to do. They added a shielding metal.

So, this very big, thick shielding
here which I would use to block

all the radiation from whatever
it is, around half of the motor

is supposed to help. Let’s have a look.

silent video starts
So this is the Master Lock.

We have a bigger magnet. I have to admit
you see it’s a much bigger magnet.

Those magnets are illegal to possess
all over Germany, I hope, soon!

And we have a different move. We’re
now rotating the magnet. We were

shifting it before. – And it’s open!

laughter and applause

This also is not really Zeroday because
as you saw before on the slide

by Rose & Ramsey he also told
the Master Lock is unpickable.

And after the talk at DEF CON I, in
the Q&A section somehow mentioned

that I doubt that. I didn’t tell
what to do exactly because

I wanted to give Master Lock some
response time. But directly after the talk

somebody approached me: “That’s very
interesting, I’m with Master Lock!” laughs

laughter
And I actually showed him this and he

filmed it with his mobile phone.
So I consider the vendor notified!

laughs
laughter and applause

So I would say: “Works for me!”

laughter and applause

So I have a message to all these vendors
and kickstarters and lock makers:

“Don’t try to be smart, be smart!
And disclose your crypto protocols!”

There’s really no need to make
a secret crypto protocol. And if

your development department tells
you: ”No no, we can’t disclose that,

that’s a really silly idea to disclose our
crypto!” you probably have bad crypto,

and they know it!
laughter

And, of course, if you build a new
thing like a hardware, like a lock e.g.

try to get your hardware in the hands of
experienced lockpickers, or locksmiths.

The shimming bypass, of the
Dog & Bone padlock, really,

every locksmith in the
U.S. would have told them:

“You can’t build a 100 Dollar padlock
which can be shimmed with a soda can!”

Especially if you’re an electronics
company what those Dog & Bone people

obviously are: Don’t trust on your
electronics knowledge. The hardware

also has to work. And please, if you give
this hardware to people don’t try to get

any NDA’s, or “Oh you can’t disclose”
– because then they won’t do it, and

you will wait just for the product to come
out, and disassemble it then. So really…

Actually, I must say the
NOKE people which I…

the lock isn’t working that good but
I think the company is doing quite well.

They sent us one of their
locks for mechanical analysis

after our Master Lock presentation.
So we tested their lock

on our magnetic attack and that didn’t
work. And still doesn’t work. So

that thing they did good. The other thing
is that they didn’t get the crypto right.

But okay. People are learning.
some laughter

So if someone really wants to be smart
– and we also tried to tell that [to] NOKE

in the kickstarter campaign –
try to become the first one.

And this is really ‘WTF’. Why is
there no – at all – open source lock?

Or light bulb? Or vibrator?
I have no idea. But…

I think you want to sell the hardware! Why
don’t make the software open source

and make it auditable?

applause

Oopf… What’s that slide? Oh
yeah, there’s Hacker Jeopardy!

If you want Hacker Jeopardy to happen
next year please send content!

laughs
applause and cheers

I heard from that Sec guy and that
Ray guy that they’re really old,

and they don’t know the things that the
young generation wants to have asked

in a Jeopardy. And what Pokémons
you have to ask, and stuff like that…

So send a few ideas! There’s a German
page, but Hacker Jeopardy will be German

next year. So, sorry for that. A German
page which tells you how to submit ideas,

how to make good ideas. And if you
send enough content possibly next year

there will be Hacker Jeopardy, again.

applause

So, we have some links. Actually, this
is the Zeroday tool we are releasing,

by e7p. It’s not on there yet, I think.
Or possibly he’s sitting in the audience

and uploading it right now. It’s a small
Python script. It needs Python3.

And it implements this crypto session
exchange. So what you basically do is

you get the values from your Wireshark,
which is all these Hex strings,

put them to a file, start the
decode-NOKE tool and it will tell you

what keycode is in there, what things are
set. Currently it only supports, I think,

the ‘Open’ command mainly, and the
‘Read Battery’ possibly. But we’ll try

to add a few more codes as we decode them.
But it’s enough to get the lock code

from the air. So with this tool
– but you could implement it yourself –

you easily can crack the locks.
And there’s a blog entry by MH

who did a nice paper about the NOKE’s
hardware and everything. If you really

want to look inside the lock look at this.
And then there’s of course the link

to the Nordic RF sniffer software.

This is one of the decompilers which
has the Adblocker blocker on it.

And there’s an article from Sec’s blog
telling you how to decompile and recompile

an app. Which I found quite
helpful during the working.

So okay. So, thanks for listening.

Please, if you have smart things
around, and want to play with that,

I have one of these dev boards left. So
I have 2, one for me and one I can lend

to someone who wants to sniff to his/her
hardware. Come to the MuCCC assembly

and tell me what you want to attack,
and I’ll give you my RF sniffer board.

Or leave the things there, and we play
during Congress. Not today, possibly,

but tomorrow I’ll be in the assembly, or
someone will be there. And I think

now I have basically exactly 10 minutes,
and I hope there are some questions.

Otherwise I was too quick! Thank you!

applause

Herald: leise: Hallo! Mikro wär’ schön!
Rufender: Musst’ nur anmachen!

Herald: Is an!
Ray: He wants a microphone for the questions!

Herald is told how to switch on microphone

Herald: Hah, wer lesen
kann ist klar im Vorteil!

Ray, thank you very much!
Do you have some time later?

I might need to ask a favour! Did I told
you about that friend that I’m having

with the Bluetooth enabled coffee
machine? We, we speak later!

We have some questions, and we have some
questions from the internet. So here we go!

Signal Angel: Yes, thank
you. Ray, are you aware

of any secure Bluetooth locks?
With decent crypto?

Ray: Actually… not! What I can’t tell is

if the crypto of the Master Lock, or
the crypto of the Dog & Bone are good,

because we really haven’t looked into
it. But it wouldn’t really help because

the hardware is broken. The NOKE people,
as I said, are bringing out a new firmware

in January [2017]. I’ll try to make them
tell me what they’re doing. Because

I’m not really going to reverse-engineer
it again. I do that for a vendor once.

We don’t have to do it a second time. So I
hope they just tell me what they’re doing,

and we can have a look if it looks
promising. But at least they react.

So, possibly, the NOKE is becoming a
more secure padlock. But besides that

I don’t know any, so far. You can find the
talk by Rose & Ramsey on the internet.

It’s unusual for DEF CON talks but this
DEF CON talk is online. So you see lots of

locks there which he attacked, and they
all were worse than the ones we had here.

So, sorry, no. Which I could recommend.

And I wouldn’t recommend it, anyway,
because if it’s not open source you

don’t know if it’s secure! You just
know it’s currently uncracked. So,

possibly stick to your old ones!
laughs

But thanks for the question.

Herald: Then we’re gonna
hop over to microphone no. 2!

Question: Thank you. That was quite
a bit of ‘Fremdschäming’. Fun talk. (?)

Just one thought: You said that
it’s about selling the hardware.

Well, maybe it’s not. Because from what
I understand most of those devices

are cloud-enabled. So I’m pretty
sure they collect all the data,

and maybe it’s about mining
that, for them. I don’t know.

Ray: Actually, yes. The NOKE has a Pro
version where they sell a company license

where you can have a company software
to the cloud, and have more features like

sharing other’s locks. But still you can
make it open source, and make a license

that disallows commercial use, or
something like that. Open source

doesn’t have to mean it’s free to use.
And if you have very complicated logic

for your company portal, or something,
possibly keep that closed-source.

But enable me to follow your
communication, to understand

how keys are generated, and stuff
like that. This is not your secret.

This is something… this
is the elementary function.

People should be able to understand an
audit. And especially in a commercial

environment, if you ask a locksmith
or some other security expert:

“Would you recommend this device?”, if he
can’t look into it he can’t recommend it.

So I think also for selling appliances, or
selling services open source algorithms

or open source protocols would be the best
solution. But especially in the lock industry

that’s very very uncommon. I had
really bad experience talking to

normal lock manufacturers about open
sourcing their stuff. It’s an idea they

don’t understand. They’re about secrets,
I don’t know. Let’s hope for the future!

laughs Another…
Herald: Okay, we had…

No. 1 is just coming up! He was queuing
at ‘3’ but covering the camera, and then

the camera man got a little bit disturbed,
and… it’s a long story. ‘1’, we go!

Question: I was wondering if you knew
about the new locks which advertise

their existence, like broadcast
things, or things like that?

Could you like walk through the street and
know there are Bluetooth locks around you?

Ray: No, those locks usually don’t broadcast
because it would use too much energy.

So usually you have to push the
shackle of the lock or something.

And then it broadcasts. There are actually
if you go back to this DEF CON talk

I was talking about – and I think that’s
enough shaming of Master Lock here –

video playback stops
if he has door locks and stuff like that,

those possibly are connected to [the]
power [grid] and advertise all the time.

So he did some lock wardriving.
But for the padlocks that doesn’t work.

But of course you can go and click
them, and then… get the idea.

And of course you can do the other thing:
you could walk around and pretend

you’re a lock, and see if someone has the
app running, and connects back to you.

That might work!

Herald: And over to
microphone no. 2, please!

Question: I was wondering
about that strong encryption,

meaning AES, and on the other
hand the very weak, or vulnerable,

or flawed key exchange: do you
think that might be due to out-tasking,

like they have specified that they
want encryption, and have not specified

how key exchange is to be handled,
and that might be the reason why

it takes them 8 months
or more to fix that?

Ray: This is basically 2 questions.
Of course I can only speculate.

It might be out-tasking, it might
also be that they just had the time…

if you follow the NOKE kickstarter
campaign – it was all funded

in a kickstarter – they had a lot of
problems in delivering on time.

So there’s lots and lots of comments
“I’m waiting for my lock, oh. Oh god,

another delay, now you’re claiming
manufacturing is difficult…”, so, many,

many people saying “you have to come out
with that”. So it might be time pressure,

it might be out-tasking, and of course
it might be that they just specified:

“Oh, we want to use AES”. And that’s
the other thing, everybody says:

“We disclose what we’re using. We’re using
AES!” Here we have a very good example,

yes, it really is using AES. And it’s
using a correct implementation.

We actually found it’s a TI example
implementation of AES that they’re using.

So it’s completely valid AES128,
but still it’s completely insecure.

So people just claim they’re using AES, or
“We’re using SHA-somesing or somesing”.

Isn’t enough. You have to know the whole
protocol. And that wasn’t the case here.

laughs
Herald: Okay, then we’re gonna go over

to the internet, again!
Ray: The internet… of…

Signal Angel: Thank you. Actually it’s a
follow-up question for the previous one:

would it be sufficient to have
a hardware-accelerated AES

on these Bluetooth thingies?

Ray: Actually hardware-accelerated AES
doesn’t have to do anything with that.

That might be helpful if you have
a chip which is a crypto chip,

if you have things like side channel
attacks. If you would have a key fob

which has a secret key in it which should
not be extractable, those keys can be

extracted with electronic attacks, side
channel attacks, power measurements.

Against these attacks a crypto chip could
help because it has a good implementation.

But for this… AES is AES. As I said
the implementation of AES is valid.

So an accelerated chip wouldn’t help.
And they’re not doing bad crypto

for performance reasons. It’s only one
AES operation. They’re doing it because

it’s more difficult to do it right. And it
possibly would need asymmetric crypto.

That could need acceleration,
on the other hand.

But it doesn’t have to do with the chip.

Herald: Are you queuing there, on ‘5’?
lowered voice: Well, then here we go!

Question: Okay, two little questions,
more hardware related. First one:

How could you build a lock which
isn’t susceptible to the attack

you showed in the video,
like flipping the magnet?

That’s the one, and the second one
is that Trelock, or ABUS I think,

says they have an electronic bike
lock which doesn’t have any battery,

and I’m quite confused how they
will do it. Have you any idea?

Ray: Actually I don’t know – starting with
the second question – the ABUS lock

at all, I must admit. But there are e.g.
also Cyberlock is it called, they have

battery in the key, and you put the key to
it. If it’s a Bluetooth lock I don’t know

how they’re doing it. It might be possible
that you push something and it starts

a generator. I’ve seen buttons which you
press and they generate the energy to send

while you press it. So it might be
that, but I don’t know the products.

The other question, I must admit I didn’t
really understand what you want to know.

Can you repeat the first one?

Question: Of course. I was just
asking how to protect the lock

so it can’t be opened by flipping
a magnet, like you did in the video.

Ray: How to protect it, that’s a very
good question. I think we know

how NOKE did it. And the thing is
I don’t think NOKE did it intentionally.

It just happened to be in their design.
We can’t open the NOKE because

the rotating actor they have is also
magnetic. So if I put my magnet there

I lock the lock. In the Master Lock it’s
some cast metal which is not magnetic.

So changing this to magnetic would
possibly help. Using a completely

different approach, like the motor in The
Quicklock, or which needs more power,

or works differently like a servo would
help. But would be a completely

different design. But it’s really a tricky
part. There have lots of different locks

in the past, also door locks, been
attackable by hardware attacks.

So building a good, really good mechanic,
or electromechanic isn’t easy.

Herald: And I think we have time
for the last one, at microphone 5.

Question: So this isn’t a question,
it’s just a precision. At one point

during the presentation you talked
about open source smart appliances,

and you said, nobody really does
that. And you urge people

to be the first to do e.g.
open source sex toys.

And it happens that someone is doing that.

So on Github it’s Q-dot,
if you want to learn more

about what they’re doing.
They have, you know,

several public repositories about
‘teledildonics’. So, you know, just,

if anyone wants to check
that out, just saying.

Ray: Okay, thanks for your
self-advertisement. laughter

And I was mainly talking about locks, I
must admit. I don’t know the other fields

so well. But locks is really difficult
to get open source. If you have

more questions I’ll be at the MuCCC
assembly. I’m waiting for you to bring

devices, get the dev board, hack the
stuff. And thanks again, for listening!

applause

postroll music

subtitles created by c3subtitles.de
in the year 2017. Join, and help us!