*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!*