Taking Bluetooth lockpicking to the next level
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Subtitle |
| |
| Title of Series | ||
| Number of Parts | 102 | |
| Author | ||
| License | CC Attribution 4.0 International: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/43243 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
Chaos Communication Camp 201944 / 102
1
6
8
14
17
18
19
20
25
27
28
29
30
34
35
36
39
41
47
52
53
54
55
58
59
63
65
67
71
79
81
84
85
86
87
91
92
93
94
95
96
97
98
99
100
101
00:00
Chaos theoryTelecommunicationOffice suiteMultiplication signPerturbation theoryJSONXMLLecture/Conference
00:39
Information securityExecution unitPresentation of a groupBit rateHand fanQuantum stateInformation securityInsertion lossTelecommunicationComputer animation
01:56
Dew pointRevision controlTrailSmart DeviceHacker (term)System programmingFood energyInternet service providerContent (media)Form (programming)Presentation of a groupVulnerability (computing)Hacker (term)BuildingPlastikkarteBand matrixFood energySystem programmingComputer animation
02:34
Smart DeviceHacker (term)System programmingFood energyPresentation of a groupExecution unitComponent-based software engineeringPlastikkarteInternetworkingSmartphoneInternetworkingSmartphoneVulnerability (computing)Process (computing)BitDependent and independent variablesSystem programmingPoint (geometry)Food energyECosComputer animation
03:20
Computer hardwareVibrationInternetworkingSmartphoneVector graphicsMobile appDew pointVirtual machineVector spaceKey (cryptography)Computer hardwareSystem programmingDecision tree learningPower (physics)TelecommunicationInternetworkingSmartphoneMereologyWeb 2.0Presentation of a groupServer (computing)Mechanism designSurjective functionFront and back endsMathematical analysisPoint (geometry)Connected spaceFlash memoryAuthenticationImplementationVulnerability (computing)Web serviceComputer animation
04:46
Dew pointVirtual machineVector graphicsInternetworkingSmartphoneMobile appFood energyMereologyTelecommunicationBit ratePersonal digital assistantExecution unitInformation securityOSI modelComputer configurationMusical ensembleVorwärtsfehlerkorrekturAnwendungsschichtVirtual machineTelecommunicationVector spaceSystem programmingPower (physics)Exterior algebraPoint (geometry)Food energyMereologyClassical physicsComputer configurationInformation securitySmartphoneBit rateCASE <Informatik>IP addressElliptic curveCartesian coordinate systemMeasurementConnected spaceRoutingCurveMeeting/InterviewJSONXMLUMLComputer animation
06:25
Asynchronous Transfer ModeAndroid (robot)Installation artPublic key certificateDew pointGroup actionComputer configurationSpeech synthesisMobile appFile systemTimestampGroup actionComputer fileAsynchronous Transfer ModeMenu (computing)Public key certificateCuboidMultiplication signSystem programmingDiscrete element methodMeeting/InterviewComputer animation
07:14
Group actionCommunications protocolAttribute grammarLengthDependent and independent variablesLocal ringFrame problemLie groupProof theorySequenceExecution unitConnected spacePlug-in (computing)TelecommunicationComputer fileEvent horizonData streamCommunications protocolProof theoryVideo gameMereologyComputer virusSequenceSet (mathematics)Computer animation
08:48
FirmwareSpywareBitFirmwareSpywareMultiplication signWhiteboardConnected spaceLecture/ConferenceComputer animation
09:38
Proof theoryQuantum stateExecution unitSoftware frameworkMereologyComplex (psychology)Power (physics)AuthorizationComputer animation
10:20
Software frameworkRootkitPublic key certificateAndroid (robot)Point (geometry)HoaxSystem programmingMobile appAxiom of choiceInformation securityOnline helpPublic key certificateRootkitAndroid (robot)outputRevision controlInternetworkingVirtual machineConfiguration spaceSoftwareData storage deviceSet (mathematics)Different (Kate Ryan album)Computer animation
11:51
Digital signalCodePublic key certificateView (database)NumberRaw image formatChainPeer-to-peerLogic gateAndroid (robot)Revision controlIntercept theoremSystem callPublic key certificateMobile appMeasurementSign (mathematics)System programmingDigital photographySound effectRevision controlMathematical analysisObject (grammar)Cartesian coordinate systemCodeOnline helpComputer fileComputer animation
13:31
Run time (program lifecycle phase)Execution unitScripting languageSequencePublic key certificateHacker (term)Mathematical analysisInformation securityCommunications protocolMobile appSoftware developerConnectivity (graph theory)Object (grammar)RoutingServer (computing)Android (robot)Type theoryRootkitPersonal identification numberInformation overloadSpacetimeOnline helpDot productMereologyInformation securitySystem callArmGreatest elementTerm (mathematics)CASE <Informatik>Exception handlingLecture/Conference
15:15
Proxy serverSuite (music)Dependent and independent variablesEvent horizonExecution unitVariety (linguistics)Line (geometry)Transportation theory (mathematics)Execution unitProxy serverAndroid (robot)Event horizonFirmwareRoutingMessage passingDataflowSystem programmingOrder (biology)Control flowLecture/ConferenceComputer animation
17:11
Inclusion mapElectronic mailing listSequenceAbsolute valueRevision controlAdvanced Encryption StandardData structureEncryptionRandom numberSystem programmingCommunications protocolData transmissionEncryptionMedical imagingServer (computing)Front and back endsPasswordRandomizationBitCartesian coordinate systemSmartphoneArmLecture/Conference
18:55
Dew pointCommunications protocolOrdinary differential equationCodeCloud computingCommunications protocolFlow separationRow (database)Multiplication signFront and back endsMereologyCASE <Informatik>Communications protocolDependent and independent variablesLecture/ConferenceComputer animation
19:48
Cartesian coordinate systemSoftwareMetropolitan area networkConnected spaceMathematicsLibrary (computing)Mixed realityMeeting/Interview
20:33
Formal verificationSystem programmingCommunications protocolWritingKey (cryptography)LeakDew pointSmartphoneInternetworkingMobile appPhysical lawFuzzy logicTerm (mathematics)Vulnerability (computing)Communications protocolCartesian coordinate systemKey (cryptography)Front and back endsMathematicsCASE <Informatik>Communications protocolSource codeSystem programmingCompilerComputer animation
21:54
Source codeAndroid (robot)CodeJava appletInclusion mapComputer fileBinary fileArmCodeCartesian coordinate systemSource codeJava appletAndroid (robot)Helmholtz decompositionProcess (computing)CryptographyArmComputer animation
22:39
CryptographyAndroid (robot)Point (geometry)Java appletService (economics)Android (robot)Order (biology)Cartesian coordinate systemState of matterHypermediaVideo gameSymbol tableComputer animation
23:20
Dew pointJava appletCodeAndroid (robot)Symbol tableMobile appWritingComputer animationMeeting/Interview
24:03
Peer-to-peerInformation securityCommunications protocolMessage passingMathematical analysisSystem programmingProof theoryAuto mechanicCodeDew pointAttribute grammarDecimalHexagonWindowData transmissionPasswordTablet computerCodeExtreme programmingArchaeological field surveyEncryptionComputer animationXMLUML
24:59
CodeCommunications protocolAttribute grammarDecimalHexagonEmulationDew pointRamsey theoryHexagonString (computer science)DecimalRight angleCodeMobile appMathematical singularityOpen setPresentation of a groupVulnerability (computing)RandomizationMessage passingMassComputer animation
25:55
Execution unitRamsey theoryTelecommunicationOpen setBlock (periodic table)
26:34
Ramsey theoryPresentation of a groupProjective planeRevision controlComputer animationMeeting/Interview
27:10
EncryptionInformation securityTerm (mathematics)Key (cryptography)Advanced Encryption StandardElectronic data interchangeCommunications protocolOperator (mathematics)Mechanism designKey (cryptography)Recurrence relationOpen setMultiplication signVulnerability (computing)Different (Kate Ryan album)Speech synthesisInformation securityBitDisassemblerComputer animation
28:01
Heat transferEncryptionExclusive orModulo (jargon)Staff (military)Computer hardwareMobile appSoftware development kitBitKey (cryptography)Product (business)MereologyMobile appCodeVideo gameAuthenticationMechanism designInformation securityCartesian coordinate systemCryptographyChainOperator (mathematics)Complex (psychology)System programmingECosSocial engineering (security)Shared memoryNumberPlastikkarteNetwork topologyGroup actionQueue (abstract data type)Proxy serverVibrationHeat transferSequenceComputer animation
30:23
Demo (music)EncryptionAdvanced Encryption StandardSystem programmingReverse engineeringVector spaceCASE <Informatik>Normal (geometry)Proxy serverSystem programmingKey (cryptography)CryptographyPerspective (visual)Exception handlingDirection (geometry)Front and back endsTelecommunicationRevision controlMobile appCommunications protocolLoginCore dumpPhysical lawVector spaceSystem callJSONXMLUMLComputer animation
31:54
Computer clusterSystem programmingFitness functionDependent and independent variablesCommunications protocolAttribute grammarElectronic data interchangeMathematical analysisStability theorySocial classFigurate numberMultiplicationTheoryGoodness of fitComputer animationSource codeXML
33:02
Cyclic redundancy checkMathematical analysisDew pointScripting languagePolynomialExclusive orParameter (computer programming)Message passingCalculationSequenceExecution unitoutputTelecommunicationPointer (computer programming)Row (database)MultiplicationMessage passingArmLine (geometry)MathematicsTerm (mathematics)Reverse engineeringScripting languageBitForcing (mathematics)Mixed realityDirection (geometry)CodeExclusive orPolynomialSystem programmingCartesian coordinate systemFront and back endsCalculationMultiplication signRight angleProjective planeInitial value problemComputer animation
35:32
Dew pointNumberPeripheralPort scannerRootkitScripting languageTouchscreenData transmissionLaptopTraffic reportingRow (database)CASE <Informatik>Hecke operatorScripting languageReal numberHacker (term)Classical physicsComputer animationLecture/Conference
36:11
View (database)LaptopSuite (music)Scripting languageLecture/Conference
36:48
Scripting languageTelecommunicationElectronic data interchangeChainProduct (business)WebsiteCommunications protocolCalculus of variationsCyclic redundancy checkPiSystem programmingScripting languageMobile appChainNumberCommunications protocolCalculus of variationsDigitizingReal numberMathematicsNetwork topologyCodeBinary codeComputer animation
37:58
Address spaceKey (cryptography)Real numberFitness functionComputer configurationInformation securityService (economics)Software testingMeeting/InterviewComputer animation
38:40
Computer clusterScripting languageSimulationComputer hardwareMobile appKey (cryptography)Scripting languagePhysical lawComputer simulationComputer hardwareLaptopException handlingMultiplication signComputer animation
39:25
Execution unitDependent and independent variablesFeasibility studyCodeProof theoryVulnerability (computing)Software development kitSystem identificationSystem programmingProof theoryDifferent (Kate Ryan album)TelecommunicationEmailMobile appLatent heatState of matterOffice suiteCASE <Informatik>CodeECosVideoconferencingDependent and independent variablesRight angleComputer animation
40:44
System programmingBitPlastikkarteMobile appState of matter2 (number)Lecture/Conference
41:25
Dew pointSoftware development kitSystem identificationMobile appElectric currentOSI modelCommunications protocolProcess (computing)BitDesign by contractSystem programmingPresentation of a groupCommunications protocolMeasurementOnline helpInformationChainWordCommunications protocolMobile appSlide rulePoint (geometry)Information securityBuilding2 (number)Field (computer science)KälteerzeugungComputer animation
43:01
2 (number)Multiplication signComputer animationLecture/Conference
43:36
Radio-frequency identificationSystem programmingGroup actionPlastikkarteField (computer science)Different (Kate Ryan album)QuicksortCloningMagnetic stripe cardComputer animation
44:49
QuicksortSystem programmingInformation securityMultiplication signView (database)Exception handlingDigitizingCartesian coordinate systemEncryptionChainLecture/ConferenceMeeting/Interview
45:35
Finite element methodTouchscreenCASE <Informatik>InternetworkingInternet der DingeLecture/ConferenceComputer animationJSON
46:11
Computer animation
Transcript: English(auto-generated)
00:48
Welcome to our presentation about Bluetooth lock-picking. Who of you did a short raise of hands to give a big round of
01:03
applause for the people who don't know us? I'm a security researcher, lock-picker, interested in technology, and for some reason, I spent too many nights in hotels which led to this research.
01:23
I'm a security researcher, lock-picker, interested in Hi, I'm Michael. I'm basically a lock nerd. I have been collecting locks since I was a little child, and never stopped doing that. When I was young, of course, they were mechanical, so I started lock-picking. I joined Sporzweiner Spärtechnik. We also have a tent here in the village, so you can
01:44
improve your lock-picking skills there. But then all the new locks basically became electronic, so I became an electronic engineer, and continued to do that, and, yes, this led to Bluetooth, finally.
02:01
Yes, we already had this presentation in an earlier form at a small conference in Vegas, but we were a little worried about their bandwidth capabilities, so hopefully now, with MediaCCC, we got a good provider to get this content out to the open world. So what is it about? We're talking about smart devices, or so-called smart
02:20
devices, using Bluetooth Low Energy, and we will show you how to analyse them, how to hack them, and, probably, if you're building such things, how to build them in a better way. And, of course, we will tell you about vulnerabilities we found that way, starting from cheap padlocks, some prior research, and then go to hotel systems, which is the newest thing we just covered here.
02:44
So, we give a short introduction about Bluetooth Low Energy, how to analyse them, and, at the end, also tell you a little bit about the responsible disclosure process we had with the hotel vendor affected by this vulnerability.
03:03
Okay, so how does such an ecosystem look like? You basically have a lock, and this is communicating to your smartphone using BLE. But, of course, the smartphone is also communicating to some back-end in the internet where it gets key data, or permissions, or stuff like that.
03:21
So, what are the attack vectors on such a system? There are various. For one, you can attack the hardware itself. So, on the lock hardware, you have electronics, you can read out firmware, you can do side-channel attacks, probably power analysis to get out AAS keys and stuff like that. You can insert wires sometimes to get to the contact
03:42
points for flashing or reading out the flash without opening the device. And there are mechanical attacks like vibration, shocking hammering onto it, magnets and stuff like that attacking the mechanics itself. On a smartphone, I think this is something many people here are familiar with. There might be malware, and there might be distance fraud.
04:03
That means you have your smartphone somewhere, and someone is relaying your data somewhere else to attack your lock. And, of course, on the internet API, there is a web server. Web servers have weaknesses, API implementations have weaknesses, there might be wrong authentication or no authentication at all.
04:22
This is also a big part. Lots of research has been done there, but this presentation is not covering a lot of this end of the ecosystem. What we will be starting looking at is the connections here. So, we have a BLE connection between the lock and your device, and we have an internet connection
04:41
between your smartphone and the backend API. And both of those can, of course, be sniffed. You can machine in the middle attack them, and you can do impersonation of one of the two sides of the communication. So, taking this all together, there's quite a few attack vectors in such a system, and surprisingly, those systems often fail in some way.
05:04
So, BLE in a very short introduction, as I said, is Bluetooth Low Energy, and it was designed as a cheap alternative to classical Bluetooth. So, it consumes less power with devices running on battery and stuff like that. It is part of BT 4.0, so it's out there for quite a while,
05:23
and for people familiar with classical Bluetooth, it's quite different. So, the use cases are mainly devices connecting so-called IoT, but usually they don't have an own IP address, they communicate with a smartphone or other device having an IP address. So, the various things like locks, light bulbs,
05:43
we heard about sex toys, I think, at Congress, heart rate sensors, stuff like that is using BLE. But what's about the security of BLE? I think there's also a lot of prior research on this. One of the first papers on the Woot 2013 conference was called, with low energy comes low security,
06:02
and that's basically true. So, there are secure options like an out-of-band or BT 4.2 elliptic curve pairing, but they're very uncommon. So, usually, you can just sniff these connections with easy measures. And so, the application has to provide the security
06:21
for the system, which often fails. So, how to find out these vulnerabilities? So, we're looking at the BLE layer now. First, if you have such a device yourself, you install the app on your phone, and you can yourself analyse your device, speaking to your lock or whatever.
06:40
So, on Android, there's a very easy option. You just enable the debug mode and activate in the debug menu the HCI Snoop lock. So, then it writes a BTLE pickup file to your file system. On iOS, there's a similar possibility you can download a Bluetooth debug certificate from Apple. This is for a few days valid.
07:00
You install it, and your device starts to lock the BLE traffic. So, what you then do is you use your app like you normally do. You open your lock, you activate your light bulb, stuff like that. And I would recommend writing down timestamps of various actions. So, like, at two minutes, whatever, I opened the lock, then I closed it. So, you can later correlate that to your Bluetooth event.
07:23
And then you get your lock file from the phone, and you can just load it into tools like Wireshark. Wireshark, I think many people here know, has support for BLE. So, it will help you decoding it. You can see here the sender and the receiver side. And it decodes the Bluetooth protocol stack. So, it shows you what kind of request is it,
07:42
where in the layer is this packet, and also shows you, which is mostly interesting part, which data is written to which Bluetooth handles. So, here you find the data of the Bluetooth communication. So, that's what you do with your own device. But if you want to attack a system, or if you want to see if it's a real possible attack,
08:01
you have to sniff the BLE from the air. So, it's relatively easy, because there's only three advertising channels, where you have to listen to, to get the connection. And there's cheap sniffers out there starting at like $25, like the Adder Bluefruit, which I'm pretty sure many people here have,
08:21
or the UberTooth One, which has a few more capabilities. Both of those support a Wireshark live view. So, if you have the plugin installed, you just get a live data stream in Wireshark. The drawback of these devices is, you only have one advertising channel, and if the device you're sniffing doesn't use a standard hopping sequence,
08:41
you probably miss the start of the connection. So, these tools are perfectly fine for proof of concept, if you want to see, okay, I really can sniff this data. But if you want a more reliable attack, our favorite tool is Beteljack. Beteljack by Damian Cockwell was released, I think, at Black Hat, and it provides firmware for cheap BLE USB devices
09:03
like the BBC Microbit. So, those can be bought for like 15 euros or something, and it flashes in firmware on it, or the BLE 400 board, or even the Adderfruit tool. So, it supports three devices connected to USB, setting each one to different channels,
09:20
so you now monitor all advertising channels, and basically get every connection, every time, quite reliably. And these tools can do much more than just sniffing. They can, for example, hijack attacks or relay data, but we focused on sniffing here. So, if you set this up, or I set it up like a very creative way that works, basically,
09:43
Michael thought that looks ugly and built a quite nice setup using a Raspberry Pi. So, this is an autonomous sniffing setup running on a battery. You could fit it into a smoke detector, put it somewhere, have it running for a few hours, and collect data. There's also a new tool out there called Mirage.
10:01
It is the author said he looked at the other tools and tried to build something better. It has probably some more capabilities, especially in the part of mental attacks or something like that, but with powerful tools, there comes complexity. So, for starting, we still recommend using the Beetlejack tool,
10:21
but if you hit a point server, it doesn't help you have a look in Mirage, it might be a tool of choice. So, now we know how to look at the Bluetooth layer. What about the back-end link? So, it usually is TLS encrypted with modern apps. There's very, very few apps still using plain HTTP
10:41
to talk to the back-end. But if you're analysing it on your own device, of course, you can just install a fake root CA and just machine the middle tools, which create certificates on the fly. So, you direct your internet traffic through your tool, have the fake CI installed, and then all your TLS traffic is readable for you.
11:04
To make that clear, this is not an attack you do on other users. This is something you do to get your own traffic of your own app analysed, and I really can recommend you doing that just to look what all your apps are doing in your system. So, using such a fake CA is quite easy on iOS.
11:22
Yes, you just install it and say, I trust the CA. It was the same in Android, but starting with version 7, Android apps don't trust the system certificate store anymore. So, you have to, or they differentiate between two certificate stores. So, you either have to root your device
11:41
and just replace the original CA store, or you can, if you for some reason can't root your device, modify the app. So, you have to unpack the app, add a network security config to it, telling it I want to use the user certificate store, rebuild the app, sign it, install it, and then you can also manage the middle traffic on a non-rooted phone.
12:06
So, usually that works, but there are a few apps trying to prevent this by measures like key pinning, and Mike will tell you about that. Yeah, this is an example we found at the conference hotel in Vegas. We didn't hack the system, of course.
12:21
We just wanted to see what it's doing, and this is a very nice example because the app actually tells you what went wrong. It says, code certificate pinning failure. So, basically this app was like, okay, you cannot trust this Android device anyway. I have to check the certificate myself. And that usually doesn't mean the end of this analysis
12:44
because there's other ways. The first one is really basic and simple, but we think it's a good advice. It often turned out app vendors usually do at least two apps, one for iOS, one for Android, and really often one of the apps doesn't do the certificate pinning,
13:04
so just try the other one. Or, for Android, you can easily get an older version of the app from the internet and try that. But if that doesn't help, then you could modify the application and re-sign it,
13:21
and we'll come to how to look into what to modify. We'll come to that later. You could also use a tool called Frida and potentially the objection framework, and that's a really powerful tool. For a mobile application, it's kind of scary if you're an app developer
13:41
because this tool allows you to basically change everything. Just a quick example. In this 45 minutes, we can't do this in detail, but there's good tutorials. What you would do is, in the example of an Android device, you have a rooted Android device, you run a server component there. Then you could try this objection, as I said.
14:03
Here's an example. I think it was the Master Lock B app, where you just use objection and type in Android SSL pinning disable, and you would get that. If not, I mean, if objection doesn't help, you would have to analyse the app.
14:21
You would have to write a small JavaScript file, like shown here, and this basically overloads the check method of the OK HTTP framework, and it always just returns and does not throw an exception, and it locks out something.
14:41
In the end, basically at the bottom, you see one of the tools showing the traffic. In this case, you see the non-encrypted traffic. So, our opinion is it may be nice to protect the user from rogue CA that somehow got installed on the device,
15:01
but if you want to do a secure protocol, that's much better than trying to hide it through this method. Don't rely on SSL pinning. People will be able to analyse it. OK, now, when it works,
15:21
there are tools you can use. For example, on the Unix command line, you can use the mitten proxy. On Mac, I like Charles proxy, but there are many more available, like burp and fiddler. The example of the mitten proxy on the command line is shown here. You can see a flow of the messages,
15:40
and you can scroll up and down. When you zoom in, it will nicely decode the message for you, show it, and this is actually an example we will also come to later. Our advice for you would be to use all these tools
16:02
when you unbox the system, because you will probably otherwise lose important events like the first firmware update, and maybe the last firmware update was easier to analyse. And it is really advisable to have an old Android device,
16:21
and they are not that expensive, route it and use it for that. OK, so now that we know how to get to the data, let's have a look how to analyse it. Basically, you get a lot of bytes, right? What to do with that? We brought an example here. This is a very small, very cheap padlock.
16:43
It's not really mechanically sound. You can probably just bite on it, and it will break, something like that, but it's a very nice puzzle. It's cheap. You get it for not much more than $10 from Amazon or from Alibaba or something like this, and it's a nice puzzle. Basically, you can spend a weekend analysing it.
17:04
Interestingly enough, we found that this company sells other locks, for example bike locks, and there is our friends from Radforschung. They do the bike-sharing system here at the camp. They also encountered this, because basically this also comes as a bike lock or a scooter lock.
17:23
It's also integrated into some e-scooters that now pop up on the streets. It's interesting to look at the protocol, and we have to be careful here. This was last year, and the company did improve this in the meantime.
17:41
For example, in 2018, they did not use HTTPS, so all the mitten stuff was not really that difficult. You could just listen to the transmission. You would see the password in plain text. If you look closely,
18:03
you would also see in the transmission from the backend server to the application, you would see 16 bytes that are called lock key. 16 bytes is 128 bits, and it's a very easy assumption to think, well, maybe this is AES128,
18:21
because that's used in many systems today. When we looked at the Bluetooth traffic on the left side of the image between the lock and the smartphone, initially it was all random. You just saw randomly looking bits, so you couldn't find out anything.
18:45
Then we just had a lucky shot on this and used AES decryption. You find even online tools to do that. Now it doesn't look random anymore. If you look at this closely, you see many zeros. This is obviously not encrypted,
19:01
so we got the right way to decrypt it with the lock key from the backend. Then, what do you do? How do you find out more about this? Basically, to analyze that, you open this lock several times and record several sessions, compare them, and here we underlined bytes that are of interest.
19:25
If you do this for a few sessions, you will find some obvious pattern, like now it's requesting something get a response. There is a session ID, in this case four bytes, sometimes only three bytes.
19:41
That is always the same. Basically, this is an example where you can deduce the protocol from just looking at it for, let's say, two hours. In this case, what we can see, there is a replay protection. There is a random, or nonce basically, a random value that is created by the lock
20:03
and changes every session. But, as you can see, it does not change within the session, so there is no counter or something like this. With tools that can actually hijack a connection or that do man in the middle, and you can replace and replay things,
20:20
this may be an interesting attack factor. What would be the next step after you have analyzed this? You could write a software that mimics the application. We use Python for that on a Raspberry Pi, and there is Blue Pi, for example, as a library, and then you can basically emulate the application
20:40
and try it yourself, and then you can modify small things and see what happens if I modify the session ID. Will it still work? Will the lock reject it? What happens? And use fuzzing. Doing this, we didn't find any obvious weakness, except for things like, if you share this secret key with somebody else,
21:02
then you cannot revoke it because you cannot change it. You also want to look at the whole system, of course. Maybe, if somebody integrates this into scooters, do they use a different key for every scooter? Or does this backend really work as you would expect it?
21:23
Is it a scooter that does not give you other users' keys? Of course, in this case, you have to respect the laws. That was a protocol that is not too difficult to understand. What do you do if the protocol really doesn't make sense at all?
21:41
Next step could be to reverse the application. This also has legal implications. You may have to check the laws. There are certain reasons why you can do this legally protected, but check that. When you recompile an application, you get source code, and you can analyse the source code.
22:02
For Android, that is not too difficult because it's Java, and Java can be recompiled rather easily. In some Android applications, there is native code, C++ code, and then you need tools that recompile this. There is, for example, the Ghidra tool by NSA that does that,
22:21
or Ida, many of you know. For iOS, it's very similar, but you have to get the application first in a decrypted way. And then you could also use Hopper, for example, to decompile ARM code. When you have that, what do you do? You will start searching for anchors like Android or Bluetooth.
22:45
If you find something that's Android or Bluetooth, or Bluetooth get characteristic, that's where the data is sent or received from the device. You probably also search for things like AES or key. The second example that's a real example,
23:02
if you find a key like this, zero, one, two, three, four, five, you may want to look closer because there may be other things hidden, and Ray will come to that soon. The one thing that often happens also
23:21
is that the app is obfuscated, and even though there are symbols in the application, they are just like C00001. And that's extremely hard to read. It is not really difficult if you use a tool that's made for that, like Android Studio for Android. In this example down there, you see there is an array. On the array, if this is null,
23:44
then key data is null, is presented, and this wasn't obfuscated, so then you just replace key data everywhere, and then you go back from this anchor to getting something more readable. On obfuscation, we have a very strong opinion. It doesn't make sense to do that.
24:01
It makes review harder, but it makes review harder for people that are friendly and will do responsible disclosure. Criminals will still do that, and they will not inform the vendor, so don't do that. Do a proper secure protocol,
24:20
and then you don't need to hide it. Okay, so what did you find so far using these techniques? Yes, so a short recap of things probably already published in the past. One very easy example, also something you can try out for getting started is a cheap padlock by the company Anbout. It has a shim-proof mechanic, so unlike very cheap locker locks from the US,
24:42
you can't shim it, but the passcode is transmitted in plain text, and to our knowledge, it is still the way today, so consider it a zero day, but we assume the vendor knows he is not using encryption, so we didn't have to notify him about that. So if you just look at the transmission here, you will find a hex string.
25:01
This hex string translates to decimal. Decimal is the key you have entered for your lock in the app. You sniff it over the air, you enter this code in the app, and you can open someone's airless lock. So this is the quality of these Chinese locks, but I'm pretty sure this is one singular example, right? Who thinks this is a singular example? Yeah, one hand.
25:21
Okay, so there was a presentation at Defcon two years ago, or three years into meantime, by Rosen Ramsey, and they tested 16 locks, and 12 had vulnerabilities like that one. So either you could fuzz them, you could simply read the pass code, you could replay data, something like that.
25:41
Then, of those 16 locks, 14 were padlocks, and two of those padlocks remained unbroken in this very broad approach. So these two padlocks were something by random. We looked into closer. The first one was by the company Master Lock, and we played around with it a little. So we had a similar attack on an older Master Lock,
26:02
but for sure, like building a new modern Bluetooth lock, they fixed it. So we used an attack tool which is called a so-called magnet. You might have heard about it. And it manipulates the motor from the outside. So by this movement and changing the polarity, we rotate the motor inside the lock
26:21
without using the electronics at all, and your $80 padlock opens. So that was easy, but not wireless lock-picking. So let's look at the other ones. The other one I have talked about already at the 33C3.
26:43
So this is just a short recap for people who didn't see that. If you're more interested in this, just look up lock-picking in the IoT and you'll find the old presentation. So the Nokia padlock was one of the first Bluetooth padlocks ever created. It was a Kickstarter project, and what I'm showing you is, of course, for the old version,
27:01
they did a firmware update after our disclosure, so now this is fixed. We haven't looked into the new one more closely so. So this local padlock actually used 128-bit AES back then, and it also used different keys for yourself and for the friends you shared it to, not different AES keys but different secrets inside the lock,
27:23
but the time restrictions were only enforced in the app, so that was the first weakness, but that's more like a minor weakness compared to the rest. The main problem was that they used individual session keys for each opening operation, but the session keys were created in an unsecure manner.
27:41
The only security relied in the secrecy by obscurity of this mechanism. So if you know how to use the disassembler and you'll find operations like XOR and look a bit around it, we found out it's a very simple protocol. It sends anons encrypted with this pre-shared 1, 2, 3, 4, 5 key.
28:03
The lock sends you anons. Those are added together. They are added to the centre of this 0, 1, 2, 3, 4, 5 key. Don't ask me why. So 32 bits in a 128-bit key get changed with data you can reconstruct, and you've got the new session key which is used to open the lock.
28:21
So, when following this, you could just break the whole encryption and read out the data. So this was a more complex lock but still an achieved product, so now for the interesting part, hotel keys. So before that, we always had things like padlocks, vibrators, other cheap toys. Now we account for this in the real life.
28:42
Why do they actually do that? This is really a smart idea. Of course, the main purpose of that is get rid of personnel. No, making the experience for the customer more pleasant, I mean. So you can do self-check-in. You don't need a keycard anymore. Your mobile phone is your key to your hotel room. So it might be that it's less personal interaction,
29:02
but of course, in a hotel with big queues, it might actually be an advantage for you if you just check into the app and don't have to go to the front desk, just walk to your room. So what are the challenges of these systems? This is not your lock, so you don't pair to this lock getting a code from the packaging or something. There's no big chance to do a big pre-shared secure pairing or something.
29:24
Then, of course, those hotels are there for quite a while. The locks are probably old, and they have to retrofit the Bluetooth stuff. So they probably don't have the most modern crypto chips in there. And then, of course, it's a complex ecosystem of the booking companies, of the hotel operators,
29:42
of the application writing companies, of the lock manufacturers, which have to interact somehow to get a good system out. So how does it work? So you have normal booking. You link this booking somehow to your account. What we found is often not very secure mechanisms of authenticating.
30:02
For example, you need to know a name, a date, and the booking number, which is a sequentially increasing number, and then you can create your mobile key if you know this data. So, for social engineering, this actually might be a way to get a key easier than walking up to a front desk. But in the normal way, you do online check-in,
30:21
and the mobile key is transferred to your app, and then you use the app to open your hotel room. So this actually was not taken at the Black Hat Hotel. We just used the mitten proxy to replace the logo. So this is something you can also do with these TLS tools. But you open your door, and the door opens, so that's the normal use case. We actually looked into this in two different hotels.
30:41
The first hotel, we call it the Hotel H. We found a system that we did not break. We looked into it, analysed it, and found out it was quite using cryptography. So, from our perspective, it looks like the vendor has a secret key KS, which is never getting known to us as a user. The backend sends us a key for our stay K,
31:03
and an encrypted version of this key K we call K*. So now our app sends to the log K*, and the log uses this vendor key KS to decrypt K*. So now, as well, the app, as the log knows the key K,
31:21
and they can do securely AS encrypted communication. This is the protocol at least somehow working. We didn't find a direct attack vector, except for probably extracting the secret key from the physical log. Like there's lots of talks about getting firmware dumped and stuff like that. That would be possible, but I don't do this in a hotel where I stay as a normal guest.
31:42
So we didn't also not really experiment more into this because the system for some reason went down after our first day. So, no implications here. We switched to another hotel having logs by the manufacturer M. So this we found early 2019 in the quite upper class hotel,
32:01
so talking about four stars, not really five stars, which uses the mobile key basically everywhere where you also can use your normal key. And we analysed the TLS traffic and the BLE traffic. So when I link my booking to my app, I get some data, and in this, I find something called mobile key having a DT array of lots of bytes.
32:22
We see only the first five bytes here, but it's more like 40 or something. When looking at the BLE traffic, I figured out I see all the bytes I get as a mobile key also on the air. So that doesn't really look good. Is it really just a replay attack? I looked at the data and found out, no, there's quite some handshake happening before this transmission,
32:43
but after some four-byte signature or something, the whole key gets transferred. So that didn't really look like it will withhold our analysis, but we first had to understand the other bytes happening before that. So Michael will tell you about that. Exactly. So we did the same thing again as we did with the small padlock.
33:03
We looked at this. We looked at several sessions. You just open the door multiple times, record all this. We found there is something at the end that changes, 32 bits. We made the assumption that half of this may be something like a nonce. The other half would be a CRC. And for the first three messages, we were right with that assumption.
33:25
So you can see underlined at the end the CRC value. You will find tools to reverse engineer CRCs. For example, CRC Refang. We, however, just used a custom Python script to try out many CRCs.
33:40
There is always a seed value that can change. There is an XOR value that can change. Direction can change back and forth and so on. But there is not so many. And basically brute force isn't the right word, I think. We just tried them and then we found the right polynomial.
34:02
And it turned out that the seed, the initial value, was something that is constant within a hotel. It's called SC, probably system code or something. And that's also sent from the backend. We've seen that in the message that was sent from the backend to the application. So we knew how to create the first three messages.
34:21
You always need as a seed the last CRC. But then in the middle, the last of these CRC or whatever, we didn't know at that time. And that was more complicated. There were like six bytes, always zero, and then two bytes that changed.
34:41
And we had to play with that. There were some values to play and try and play around. But essentially it's like this. There are the values from the previous calculations I used together with the data behind that.
35:01
And then this used the CRC value that was transmitted by the real application. And now we knew how to create that ourselves. So that was a major breakthrough in this project. We prepared a Python script again using blue pi that calculates these CRCs.
35:24
Of course you need the key somewhere. We tried that as well again. So you can see our sniffing attack here. In this case we did it from inside of the room, not to confuse the roommates and so on. But you can see the three little recorders there.
35:44
And one of them was linking because it actually found the transmission. And on the laptop screen you can see the key data. Insert this into our Python script.
36:02
And well then. Then I thought let's try this out for real. I went with my laptop and a classical hacker outfit outside of one of the rooms we had. And let's try it out. So there's the Python script running on my laptop using the data we sniffed. On the actual hotel door you see the light is turning to green.
36:20
And we enter a room and suddenly it turned into a quite nice hotel suite. Because it was actually in the 37th floor of the luxury hotel.
36:45
So much for Chinese padlocks. Okay, so after we had that running we thought let's play around with it a little more. And Michael created a Python script emulating the lock. So we had the other target, the other side of the system. And we could use the real app to play with our simulated target.
37:04
And we were wondering how big is this problem. We found this in one hotel. But we found out the names of these locks are base64 encoded binary data that we can understand. So we could just by looking at advertisements from BAE locks find out if they belong to the system we analyzed or not.
37:20
We found another hotel chain and a third hotel chain using the system. After booking a room in one of these chains we found an even more simple variation of this protocol. So this basically tells us, okay, this is a bigger problem. And from this we also could deduce that the vendor of these locks called Messerschmitt system, the German company, is the origin of this protocol.
37:45
And even so they have like 2,000 hotels all together. The system is only deployed in like, I'm not sure, but a smaller three digit number or something of them. Because we talked to them and they're very early in adopting this. And also they don't put this into their five star houses because they don't want mobile keys basically.
38:04
But in other houses it's getting popular. So we thought, okay, this might be something real and we have to find out can it really be used in a real attack. So we know we can reliably sniff it, but where could you sniff it? Doing it at the door might be a problem because you have to know which lock you are sniffing.
38:21
So our first way was, oh, probably there's a way people go there without much security considerations. In such a fitness centre there might be options like plastic containers that are unnecessarily hidden somewhere. Having this nicely set up and letting our test guests enter the fitness centre, we found out mobile key was down for the fitness centre.
38:45
I'm not sure if they wanted to spoil us or whatever, but there's a second place where everybody uses this key. And this actually seemed better for sniffing because if you want to enter your floor, you have to activate the elevator using your mobile phone app. So this is a place where you can very unsuspiciously work with your backpack,
39:03
have a sniffing set up or even place it somewhere and everybody has to use his keys there. And if you have the simulator script we built, you don't even need special hardware. You just emulate the elevator lock, advertise more heavily and the app of somebody will connect to your laptop and you can complete hardware-less attack except for your laptop to get a key.
39:23
And, of course, our tool dumps the key for your convenience use. So, figuring out this is a real issue which can really be exploited, we thought would be a good way to disclose this to the vendor, and we started this in April. We told them, we told them, yes, this is a problem, and nicely we got an immediate response,
39:43
probably because we did some research in who to write to, we sent him technical detail. First reaction was, ah, that looks very interesting but it can't really work like that. So we sent a very specific mail telling, believe me, we did this in a real hotel. We didn't send the video, so, but we sent proof of concept code, they acknowledged it,
40:04
and all the communication went very, very well. They never tried to prevent publication or anything and they started to work on the update. The challenges, of course, in such an update is you have to update a whole hotel system, a whole ecosystem. So we found out that the lock in the first hotel where we saw the nice video,
40:22
this is a modern hotel being completely online. They can actually remotely update the whole system from their office. In other hotels, they will have to walk from door to door to door with what I understand is an infrared update device, so this will be some work. And, of course, the different app vendors will have to integrate the fixed system into their APKs
40:44
independently of the update of the lock system. So, actually, the state of now still is a zero-day exploit, and we had some discussions also already at Black Hat if we should really publish it, but figuring out that you can still use your normal key card if you figure you're in such an affected hotel
41:03
and giving the fact that actually not very many people actually use it so far because it's quite coming up now, we thought it's okay. But one important lesson we learned is you have to really identify all the parties because we informed the vendor very early, but the app vendors and the hotels,
41:21
and actually a second vendor which we only heard about two weeks ago, were notified a little bit late about that. But, still, this is what was quite interesting to see contact to the vendor side, and they told us they are in the process of rolling it out starting end of August.
41:40
Probably this is a little bit delayed now because we haven't really heard of the new protocol yet, but they're working on it, and we hope this turns out quite well. So, what are the takeaways you should take from this presentation? One, of course, is particularly, I'm sure everybody should know by now, the BLE link layer usually can be sniffed reliably with simple tools
42:04
unless special methods like out-of-band pairing are taken. And whoever should build this, I'm not addressing this to you, but probably to the vendors looking into this talk, please don't hide your secrets in apps. Build secure protocols. These whole things we analysed are all obviously built on the assumption
42:23
that you can do things like that and it works out. No, it doesn't. And the thing we learned in this is BLE is not just used in toys anymore. It's getting to the real world. Now it's in hotels, probably it's always getting to really important things like your moto refrigerator, so these things are worth looking into and worth analysing,
42:44
and I hope that with these entry points here, and I can really recommend downloading the slides because all the blue words you saw in the links to more information help you to get into this research field, and you can help us make this a safer world by hacking all these things.
43:01
So, thanks for your attention, and now we have like two minutes, 50 seconds for questions. Yes, we do have time for some questions,
43:23
so raise your hand if you have one. No, your microphone is wired, so you need to come to this lovely angel in the centre here and ask your question in his microphone.
43:40
Yes, there is a question over there. Am I supposed to ask a question? Okay, hi Ray, I'm Michael. I have a question about other transports,
44:01
like is NFC or RFID ever used in hotel door locks? An RFID is the standard way today. Most hotels you have an RFID card today. NFC I have not seen, but we have for example seen Bluetooth locking systems where you actually have to near your phone to the lock
44:20
before the lock activates the Bluetooth, but this is not what we looked into, and as I said, RFID is very standard, and of course these cards can clone and everything, but it's a different field of research. Bluetooth became popular in popular smartphones, so that's the technology they all go for now, but of course all the cards you get in the hotels.
44:41
Previously, some years ago, they used magnet stripes, but now they are RFID. Thanks a lot for this answer. Do we have another question? Yes, up there, go ahead. Are there some Bluetooth locks that perform some sort of pairing? We have not seen that, and that's really inconvenient
45:01
because you would have to spend too much time to do that, so basically all the lock systems, except for very few that you put in your front door, all of them use just unencrypted link layer and then do the encryption or whatever they think that's appropriate,
45:21
they do on the application layer. The only high security device where I found pairing so far was a luggage bag showing a digital bag tag that used pairing. Thank you for your answer. Do we have any more questions?
45:41
I don't think that is the case, if I'm not mistaken. Screen now. No questions on the internet? Okay. Or on the internet of things? No, okay, then thank you again, and please get into hacking these things.