BLE Sniffing 101
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 |
| |
| Alternative Title |
| |
| Title of Series | ||
| Number of Parts | 322 | |
| Author | ||
| License | CC Attribution 3.0 Unported: 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/39678 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Communications protocolInformation securitySoftware developerSoftware frameworkComputer iconPhysical systemDigitizingMereologyPresentation of a groupFood energyVulnerability (computing)Disk read-and-write headSoftware maintenanceVirtualization
01:21
SoftwareFirmwareSoftware-defined radioParameter (computer programming)NP-hardFrequencyOpen setInformation securityMechanism designConnected spaceSoftware suiteMultiplication signPattern languageSoftware-defined radioSoftwareOrder (biology)Communications protocolInformationCASE <Informatik>Parameter (computer programming)Instance (computer science)Principal ideal domainTelecommunicationFirmwareLevel (video gaming)LinearizationMathematical analysisMereologyModule (mathematics)Flow separationSoftware bugDiallyl disulfideBoundary value problemSystem callElectronic data interchangeBand matrix
07:10
Metropolitan area networkService (economics)Metropolitan area networkConnected spaceParameter (computer programming)Multiplication signInstance (computer science)Service (economics)Characteristic polynomialDifferent (Kate Ryan album)InformationAddress spaceLatent heatMultiplicationMereologySystem on a chipOrder (biology)Revision controlPresentation of a groupComputer animation
09:35
Military operationComplex (psychology)ComputerEvent horizonOSI modelMotion captureType theorySource codeIntercept theoremComputer hardwareOpen sourceComputer wormData structureRegulärer Ausdruck <Textverarbeitung>Side channel attackInformationData modelCyclic redundancy checkAddress spaceLarge eddy simulationSystem identificationMusical ensembleJava appletMetropolitan area networkMoment (mathematics)Address spaceOrder (biology)Multiplication signVirtual machineSoftwareTest-driven developmentLevel (video gaming)NeuroinformatikComputer hardwareLink (knot theory)MereologyEvent horizonCodeProcess (computing)Connected spaceCommunications protocolAdaptive behaviorInformationInformation securityMotherboardCharacteristic polynomialTraffic reportingMeasurementRevision controlCountingAuthorizationLimit (category theory)Software developerDigital photographyFirmwareComputer iconParameter (computer programming)Open sourceType theoryFreewareData managementHypermediaView (database)Instance (computer science)Data storage deviceReading (process)WritingComputer fileBitPoint (geometry)Complex (psychology)Server (computing)Latent heatVideoconferencingSource codeCausalitySource codeXML
16:43
Address spaceCyclic redundancy checkData recoveryLarge eddy simulationSequenceLevel (video gaming)MeasurementSource codeIntercept theoremOSI modelPattern languageParameter (computer programming)CASE <Informatik>Connected spaceAlgorithmSoftware2 (number)Order (biology)Level (video gaming)Normal (geometry)Multiplication signSequenceContext awarenessTable (information)Instance (computer science)Moment (mathematics)NumberLatent heatSubject indexingLimit (category theory)Insertion lossPrice indexSpherical capComputer programmingSynchronizationProcess (computing)Marginal distributionStability theoryProof theoryOpen setTelecommunicationMathematicsRevision controlMaxima and minimaGeneric programmingNeuroinformatikMeasurementHydraulic jumpSinc function
23:38
BitOnline helpInstance (computer science)Student's t-test
24:39
Demo (music)Beta functionSheaf (mathematics)Integrated development environmentDemo (music)Videoconferencing
25:29
Beta functionAsynchronous Transfer ModeNetwork socketRevision controlAddress spaceCyclic redundancy checkCurve fittingParameter (computer programming)Connected spaceVideoconferencingRow (database)Link (knot theory)Address spaceCodeValidity (statistics)Latent heatComputer configurationReading (process)Level (video gaming)Parameter (computer programming)WritingCharacteristic polynomialBeta functionSource codeTableXMLComputer animation
26:45
File formatComputer-generated imageryPeripheralConnected spaceKey (cryptography)Flow separationComputer fileParameter (computer programming)EncryptionMultiplication signCodeControl flowBeta functionFile formatLatent heatSheaf (mathematics)Personal area networkVulnerability (computing)Form (programming)2 (number)VideoconferencingProcess (computing)BitInheritance (object-oriented programming)CodePrincipal ideal domain
29:11
Flow separationConnected spaceVideoconferencingLatent heatLine (geometry)Centralizer and normalizerSoftwareGame controllerMultiplication sign
30:56
MultiplicationAsynchronous Transfer ModeConnected spaceOnline helpLevel (video gaming)Parameter (computer programming)BitOverhead (computing)Order (biology)Error messageArrow of timeSource code
31:39
Revision controlMetreDistanceOpticsCommunications protocolCartesian coordinate systemConnected spaceDistanceState of matterRevision controlBitMetreTelecommunicationFood energy
32:56
Data modelRevision controlMultiplicationSoftware testingVideoconferencingConnected spaceLevel (video gaming)Electronic signatureSmartphoneMusical ensembleComputer animation
33:48
Data modeloutputSmartphoneGame controllerConnected spaceVideoconferencingComputer wormAsynchronous Transfer ModeTime zoneProgram flowchartComputer animation
34:37
Term (mathematics)Hand fanStatement (computer science)SmartphoneSlide rule
35:46
SmartphoneString (computer science)VideoconferencingVibrationGame controllerBeta functionConnected spacePoint (geometry)BitCharacteristic polynomialMultiplication signSpecial unitary groupLevel (video gaming)
37:06
AuthorizationAuthenticationProxy serverLeakInformationConnected spaceAnwendungsschichtRevision controlSpywareData recoveryConnected spaceSoftware bugInformation securityCommunications protocolCharacteristic polynomialRevision controlRange (statistics)AuthenticationMetreLatent heatSpywareFood energyCartesian coordinate systemLevel (video gaming)NeuroinformatikDenial-of-service attackMechanism designEncryptionCASE <Informatik>Message passingInjektivitätSmartphoneCodeInformationReading (process)Data integrityBitPrincipal ideal domainState of matterTask (computing)Instance (computer science)Computer fileMultiplicationSet (mathematics)
Transcript: English(auto-generated)
00:01
give a warm welcome to Virtual Labs. Thank you very much. So, uh, today I'm going to talk again about the Bluetooth Low Energy Protocol and, uh, about also new vulnerability I've
00:20
found in this protocol. So, um, who am I? I'm the head of Research and Development at EcoNOCOM Digital Security, not the digital security in Russia, obviously. Um, I've been studying Bluetooth Low Energy, uh, about four years now, uh, three years now. And, uh, I'm the developer and maintainer of Beta Juice. Uh, maybe you, uh, you've heard about it.
00:42
This is, uh, one of the framework, uh, I worked on. And, uh, I'm having, uh, a lot of, um, with, uh, Nordics semiconductors system and chips. So, let's start with the, the agenda. So, uh, we are going to go through the BLE sniffing 101. For those of you who don't know how to perform BLE sniffing, then, uh, we are, I'm going to present
01:05
Beetlejack, which is my new tool for BLE sniffing and much more. Uh, we are going to see, uh, what, uh, what is inside this tool, why, why this tool. And, uh, the next, last part of the talk I'm going to disclose a new attack on BLE. Alright, so, let's
01:23
start with some, uh, BLE sniffing. Just one minute. So, BLE sniffing, uh, uh, BLE sniffing 101. So, uh, basically, if you, uh, nowadays want to sniff, uh, BLE connections and BLE communications with two devices, you need some tools. Uh, and
01:41
there are, uh, you're lucky there are a lot of, uh, chip tools out there. So, you may want to sniff with, uh, Uber tools, one, uh, sniff BLE connections. Or you may want to, to use the Adafruit Bluefoot LED sniffer, which is also a nifty tool. Or you may want to do it the SDR way, with the, uh, GNU audio software suite. So, let's
02:05
start with the, the first one, the Uber tools one. So, um, this is a tool that allows, uh, anyone to sniff existing and new BLE connection. I mean, if you, uh, use this tool, you can find existing connections between, between devices and also listen for
02:23
new connections that happen on the, uh, on the target device. Um, it did not support channel map, channel map updates. So, um, it did not. Because obviously, they updated the firmware yesterday, through the, uh, DefCon release. And, yeah, uh, so they,
02:41
they updated the firmware and it's not, not supported by the, uh, Uber tools. So, this is cool. If you, uh, have one, just, uh, use this new firmware and try it, uh, with, uh, try it by, you know, sniffing some BLE stuff. But, the fact is that the, even with the new firmware, the Uber tools one has some issues sniffing on existing connections. And,
03:03
last but not least, it costs 120 bucks. So, it's, um, it's cheap, but not so cheap. The Bluefoot Edi Sniffer made by Adafruit, so it's based on, uh, uh, specific software written by Nordic Semiconductor. So, it's, uh, uh, proprietary firmware that is used
03:22
here. Uh, it was, uh, last, uh, uh, it was updated in November, uh, in November, last year. So, it's, uh, quite, uh, quite maintained. But, this, uh, sniffer only, uh, allows, um, new connection sniffing. You cannot, um, you cannot sniff an existing
03:40
connection with two devices. Already established connection, I mean. So, this is, uh, very interesting for, um, you know, security analysis. But, if you want to hack into existing devices or already connected devices, you cannot do this with this, uh, Bluefoot Edi Sniffer. It costs around, uh, 30 or 14 bucks. So, it's, uh, it's, uh, affordable. And,
04:03
if you want to do the, the SDRware, uh, you are going to, to have some issues because, um, the SDR, uh, modules existing with, uh, GNU audio are only able to get the BLE advertisements sent by the devices. So, you cannot follow any BLE connection with this,
04:25
uh, this approach. Um, this, the reason is very simple because of the latency. There is some kind of latency between the, uh, you know, the software and the SDR device you are using. And, it, uh, do not allow to jump very quickly over all the channels used
04:42
in the BLE connection. And, last but not least, it requires a 2.4 gigahertz compatible SDR device that costs, uh, some, uh, hundred of dollars. So, uh, it's, again, affordable, but, uh, it's, uh, more expensive than the, the two previous one, uh, I talked about. So, just
05:03
to summarize this, uh, BLE sniffing 101 part of my talk. So, BLE basically is designed to make sniffing difficult. And, it, it's working, you know. Uh, it's, uh, not so easy to sniff BLE connections. Why? Simply because this, uh, protocol uses three separate
05:20
advertising channels spread across the bandwidth. So, you cannot listen to these three channels at the same time. You got to be, uh, listening on each channel one after the other to get, to get all the information or maybe to use three devices to listen to these three channels at the same time. The, this protocol also uses some kind of
05:44
frequency hopping mechanism. So, channel, but what you can also call channel hopping. So, this, uh, channel hopping, uh, mechanism makes also sniffing very difficult because once a connection is created between two devices, the, these two devices are going to jump from
06:01
one channel to another. And then you, you need to, to get the pattern they are using to, to synchronize with this connection and get all the packets. So, this is not very easy when you are dealing with existing BLE connections. And, both devices can also renegotiate some parameters at any time. So, when you are trying to figure out what
06:24
these parameters are in order to, to sniff an existing connection, they might change between the, what you are measuring, what you are trying to, to recover these parameters. So, this will mess your sniffing. So, two cases here, you may have a lot of
06:45
money, and you can afford, uh, a lot of devices and make your sniffing on the, the, all 40 channels, for instance. Or, if you want to do it the cheaper way, uh, you got to struggle with the BLE sniffing. You, you won't be able to sniff, uh, very easily
07:02
your connection for the first time. For instance, you got to wait, uh, multiple connections to get your, your, your data. So, two years ago, I took another approach for the, the, for capturing BLE packets. Uh, I, I tried some kind of man in the middle approach. The idea, uh, of this man in the middle approach was to have some kind of
07:25
device in between your phone, for instance, and, uh, a device it's connected to, and then capture the packets. So, basically the same, uh, the same approach that we, uh, all do when, uh, we are going to perform some TCP man in the middle, for instance.
07:42
So, how it works. First, you have to discover a target. You get, you get to, to find a, a target device. So, obviously, this device is advertising itself. So, it's not, uh, there is nothing connected, uh, to this device. So, it's, uh, advertising, announcing, uh, it's, uh, it's present and so on. So, you can connect to it, get all the information, all the
08:03
services, characteristics, and so on, in a way that you can, uh, then impersonate this device. You connect to this device, it's not advertising anymore because, uh, because of the specifications. Uh, for BLE version 4, uh, once the, the device is, uh, when, uh, when,
08:22
uh, when, yeah, once the device is connected to something, it only supports one connection at a time. Most of them, most of them do this. Um, there are a few devices out there that only, uh, accepts multiple connections. But it's very difficult for the system on chip that handles all the, all the radio parts to, um, to handle 2 or 3
08:44
connections at a time because, uh, it requires to jump on different channels and with different setup, different parameters. So, this is, uh, not very easy. Well, you are connected to this device, it's not advertising anymore, so you can create, uh, a clone device with the exact same parameters, exact, exact same services, characteristics, even
09:06
the exact same Bluetooth address, so you can just, uh, spoof the device, in order to say this, and, uh, you wait for connections. Once your phone is connected to your fake device, you're, all you have to do is just to follow, forward the data between your
09:22
connection with the device and the connection with the phone. So, you are in between and you capture everything. So, this, this approach has been implemented in Bitajous, one of the tools I was talking about in the introduction, and also in another tool called Gattaker, uh, written by, uh, Slavomir, Slavomir Jazek. And, uh, these 2
09:42
tools implement, uh, the, uh, man in the middle approach. Well, so, it was working pretty well until the last few years, um, and it has a lot of advantages because you can get rid of the, uh, free advertising channel problem. Uh, I mean, if you are using this
10:02
man in the middle approach, you are controlling the advertising of your device, so you are quite sure to get the connection and not miss it. You can see every video portion performed. If there is some kind of, uh, characteristic write or read or discovery, you can get all of this and, uh, you see everything. And also, you can
10:26
compare the data on the file. Since we are in between the 2 devices, we can just change data on the file, making, uh, changing some bytes and, uh, causing some, uh, some troubles, uh, in a security point of view. But, there are a lot of issues too. One
10:48
year after having developed the Bitajous software, I got a lot of issues on GitHub with, uh, people saying, ah, I cannot use your tool, it's, um, it's quite complex to install because it requires one virtual machine and one host computer and some kind of
11:04
network setup to make these machines communicate with, uh, each other. So, it was, um, a quite complex setup and, uh, a lot of people had a lot of issues, um, putting, uh, all of the software, uh, on, on the computers and making, making it working. The other problem
11:25
we have, uh, is that we only capture HCI events because we, um, work at the, uh, adapter level where we don't get any link layer BLE packets. So, we are one way upper, uh, we are, we are, we cannot get all the information and especially, um, all the
11:44
pairing packets. Uh, so, this approach, the man in the middle approach does not support all types of pairing and this may cause, cause a lot of trouble when you are trying to intercept, uh, encrypted connections. And, obviously, it's also compatible only with
12:01
4.0 adapters, or maybe you have heard about the Cambridge silicon radio USB adapters that are some kind of Bluetooth device address spoofing. Well, we got some troubles to, with the latest version of the USB adapters, or even the, um, adapters provided in,
12:21
within the, with the motherboard of your computer. So, the stock adapter of your computer may cause trouble, um, with the, the softwares. So, these are the counts of the, the man in the middle approach. So, basically, we are doing it wrong. Ubertos BTLE, okay, it works, but it still has some, some limitations, even with the,
12:44
uh, firmware update, uh, released yesterday. Nordic semiconductor sniffer is closed source and may be discontinued. So, we don't know if, uh, this software is going to be maintained and we don't know if, uh, if, uh, what, what, what will happen if, uh, Nordic semiconductor decides to, not to, uh, continue the
13:04
development of this, uh, of this, uh, software. So, maybe a problem. And, uh, the man in the middle approach is great, but very, it's too much difficult to use and, uh, cause a lot of trouble for users. And, also, it cannot get all these, uh, link
13:21
layer packets because we are, uh, limited by the, uh, solution we opted up, we opted for. So, it's time to improve the BED arsenal. So, basically, what would be the ideal tool to sniff BED connections? Well, we need a tool able to sniff both existing and new
13:41
connections. We also need a tool that uses cheap hardware in order to make it affordable, you know, to lower the, the, the ticket for BED sniffing. And, of course, we need open source software to, uh, be able to maintain it, to contribute, for allowing other researchers to, to push, uh, new features, for
14:02
instance. So, this is, uh, something very, very important here. This tool needs to sniff new connections. I'm going to go, uh, deeper at the protocol just to show you how it works in the internals very quickly. So, for new connections, the goal is very easy. We
14:23
need to get the connection request PDU, which is, in fact, a dedicated packet sent by your phone, for instance, when you, when you are trying to connect to a, uh, BED enabled device. And in this packet, there is everything, everything we need to, uh, monitor the, or to follow the BED connection. We got the, uh, CRT value, we got also the
14:44
channel map and so on. So, if we capture this packet, we, we are able to follow the connection and, and then sniff, to sniff the packets. But, for sniffing this packet, we got to be at, uh, very specific moment, listening on the specific channel when this
15:02
packet is sent. And as we saw this, uh, previously, there are three advertising channels. So, you must just listen on one channel to another, hoping that, uh, that this packet will, uh, arrive at, uh, specific moment. Or you may want to sniff on these
15:22
three advertising channels at the same time in order to, to get this packet. So, in order for this to work, we need this, uh, situation. We need to release, uh, at, uh, the same time to these three advertising channels. So, this one is, uh, quite easy to sniff,
15:40
to sniff, uh, new connections. The trickiest part is, uh, active connection sniffing process. So, in order to sniff active connections, you don't have all of these parameters. You don't know the, uh, connection parameters. So, you, you have to get them. And in order to get these parameters, we made, uh, we are going to make some
16:01
measures. Mike Ryan, the author of Ubatros BTLE, so the, the tool, uh, uh, I cited just before, uh, created his, uh, his own technique to get, to recover these parameters. Um, his technique is the following. First, he tries to identify what, uh, the protocol calls, uh, an
16:25
access address. An access address is a 32-bit value used to identify a link between two devices. So, this, uh, access address is, uh, used, uh, to identify a specific connection. Once the access address is known, we can recover the C or C init value, uh, that
16:46
is used to compute C or C. Uh, this is some kind of seed used to compute the C or C for every packet. And this can be done very easily. Then, we need to get the hop interval. The hop interval is basically the time, the, uh, the device we spent on each
17:05
channel. So, how do you, uh, how do we do that? Very easily. We just sit on a specific channel. We are measuring the time between two consecutive packets on this channel. And we divide it by 37, since there are 37 data channels used for the channel
17:24
hopping, uh, pattern. And, of course, we can also recover the hop increment, which is, uh, the number of channels added to, uh, the channel index each time the, uh, connection jumps from one channel to another by using some kind of lookup table. So,
17:47
we are able to, uh, the, the, the, for instance, measure the time between two consecutive packets on a channel 0 and 1. By using this, uh, this technique and the lookup table, we are able to recover the hop increment value. So, this is MagRion's technique as it was
18:06
implemented in the, uh, the software. And it's still the case, uh. Even with the, uh, And of course, Mike made some assumptions back in 2013.
18:24
He made the assumption that all the 37 data channels are used, but it's not the case. Now in 2018, most of the BLE devices don't use all of these 37 data channels.
18:41
And they determined these data channels by using some kind of channel map. This is a parameter sent in the connection request PDU that specify which channel are going to be used and which will not. So if not all the data channels are used,
19:01
then you have to keep a 37 channel sequence. And to do that, some of these channels will be remapped, will be reused if you prefer. So if you have a look at a hopping sequence in this specific case, you will see, for instance, that the channel four is used twice in the sequence.
19:22
But normally, you will find only, it will be found only once in the normal sequence if it's not reused. So by modifying the sequence order and making this channel appears twice, if you just measure the time between two consecutive packets on the channel four,
19:44
we will get two values, two different values. And this makes max technique useless. This does not work anymore. So how to deduce all of this based on this new behavior?
20:03
First thing to do is to deduce the channel map. So it's very easy to deduce. We just iterate over all the channels. We are looking for packets. And if we see some packets sent by the device, okay, the channel is used. If we don't see any packet, it's not used.
20:21
So there will be some kind of time that you have to implement to get these values. And it can take sometimes, for instance, four times 37 seconds to complete. Well, this is a limitation of this approach. Once you get the channel map, you can deduce the hop interval by finding a unique channel
20:42
that is not repeated in the hopping sequence. And then you measure the time between two packets and you divide it by 37 and you get the time spent on each channel. And then deduce the hop increment based on this. But we don't use a precomputed lookup table.
21:02
We are going to generate it based on the channel map. And then we are going to measure and deduce the hop increment. So this is basically a more generic version of Mike's technique, but it works pretty well. There are a lot more details in the proof of concept
21:22
or get the fuck out, number 17, where I write a paper with all the algorithms and the math behind this technique. Well, and all of this is going to be implemented in Beetlejack. There is also another trick here
21:41
for sniffing this connection. In the specification, there is a parameter called the instant. You know, when the device updates on some parameters, say the channel map, for instance, it's in the packet telling the device that the channel map will be updated
22:00
at a specific moment in the connection, but not now, later on. But we don't know this value. We don't know this instant value when we are attacking existing connections. So this might be a problem since it's used for updating the channel map. And if the channel map is updated, we may lose our synchronization.
22:22
We may lose the signal and lose packets. So the fact is that we don't really care. We don't really care because once a channel update packet is issued by your device, whoops, sorry.
22:42
So once a channel packet is sent by the device, at a specific instant we don't know, the hopping sequence will change. And then we are going to sniff on channel 11 in this case while the sequence will go to channel one.
23:02
So obviously, we won't get any packet on channel 11. So this may be an indicator that the channel map has been updated. And we can deduce the new hopping sequence and resynchronize with the communication. So by using this little trick,
23:21
we can just follow any connection and support the channel map update process even if we don't know the instant value for this precise connection. So all of this is implemented in Beta Jack. And so I decided to create this new tool.
23:41
And I'm very proud to present it at DEFCON this year. This is a brand new tool based on Microbit. Again, this is a tiny device, so some kind of Arduino sponsored by the British Broadcasting Company. The original goal of this device was to help UK students to learn how to code.
24:01
But in fact, we can turn it into some kind of packet tool. And it's pretty cool. It costs only 15 bucks, so it's quite affordable. And you can buy more of them, three of them, four of them for the exact same price for like the Bluefoot, Adafruit Bluefoot LED Sniffer, for instance.
24:21
You can also stack them and create some sniffing rig. She wanted to do this. So basically, I modified a cluster art for Raspberry Pi. This is just a USB 2, USB hub. But it's quite useful.
24:41
I have to find a name, obviously. So since I'm not a very creative person, you know. You see, it's called Beta Jack because of the new vermability I'm going to present in the next section.
25:01
But anyway, this tool is quite useful. But I won't do any live demo because I know you first. I know if I put some kind of built-in device you are going to connect to it, and I won't be able to do my demo. And of course, this is a very noisy environment
25:23
here at Defcon. I made some sniffing during some talks yesterday, and it was very noisy. So I got videos. So the first video shows the sniffing of a new connection. So I specified the Bluetooth device address in the parameter, and as you can see,
25:42
we are able to intercept this connection and get all the link layer packets. We also get the access address, the CRC need value, and so on. So sniffing new connection, no problem. Sniffing an existing connection for a specific device. First, you have to identify a valid access address.
26:01
So there is an option in the tool to scan and identify this address. I pick a target here with the specific access address, and then Beta Jack will recover all the required parameters to be able to follow the connection, and then to a sniff packet. So it recovers the CRC need value,
26:23
the channel map, obviously, and then it deduces the hop interval and hop increment. It's synchronized, and if I do some read or write on various characteristics and get all the packets.
26:40
So again, existing connections, well, not really a problem with Beta Jack. And to offer some, you know, some other features, there is a pickup export possible. So if you intercept packets with Beta Jack, you can export these files into a pickup file. Well, obviously, it was expected for this kind of tool,
27:01
but it also supports the specific format for the pickup file that makes it able to use with Quackity. Quackity is a tool designed by Mike Ryan to break the encryption keys, when some kind of pairing is used between two BLE devices. So this may also be useful
27:22
if you want to break encryption keys or pairing codes for BLE. So when I was developing this tool, this new sniffer, I read the specifications a lot. I went in all of the details of the specifications,
27:43
and I stumbled upon a very specific, you know, not a weakness, but something, you know, made me feel bad. I don't know what it was, but I found I was reading the section about the separation timeout in these specifications.
28:05
And just to summarize it a bit, so the separation timeout is provided by a device in the connection request PDU.
28:22
So this is a parameter assigned in the connection request PDU, and basically, it defines the time after which a connection should consider a connection. A device, sorry, should consider a connection lost. So basically, if you try to connect your phone
28:42
with, say, your smartwatch, your phone is going to tell the smartwatch that if no valid packet is received, or is received after 20 seconds, then your smartwatch and your phone should consider the connection lost. And so this separation timeout is enforced by both devices.
29:04
And I had quite an idea about it. Yeah, was that time or time? What if we jam some specific packets or specific times? Let's see.
29:21
So there is three lines in my slides, the central, peripheral, and attacker. Central is your phone, the central device, the initiator of the connection. The peripheral is obviously your smartwatch or your medical device, anyway. So your phone sends regularly packets to the device,
29:40
and there is some kind of a keep-alives packet that are sent just to be sure that the connection is still alive. So many packets, and we decide to jam the packet sent by the peripheral to the central device. And since then, the central device
30:00
consider the connection not lost, but with no valid data. So it starts a timer, and we do this sometimes, until the separation timer is reached. And then the central device consider the connection as lost.
30:22
But the fun fact here is that the peripheral still gets packet from the central device. So it's not disconnected, and then we can have some fun. By impersonating the central device, we can get the connection.
30:41
So it's based on jamming. First of all, I implemented the jamming feature in the Beteljack. So this is just a short video. I don't know how many times, okay. Okay, so I'm connecting to a specific device, and I'm using Beteljack to jam the connection.
31:02
I don't know if it's gonna, it's gonna be all right. So in order to jam the connection, you get to recover all the required parameters to know all these CRC in each channel map, hop interval, hop increment, and so on. And once Beteljack is synchronized with the connection,
31:22
it starts jamming by sending back packets. And this will cause some CRC errors on the phone side, and the phone is disconnected. I don't know if it's really easy to see, but here it's disconnected. So jamming works pretty well.
31:41
So the idea of this attack, which I call it Beteljacking because of the tool, but anyway, this attack abuses BADC version timeout to take over a connection. So basically, we get our hands on the, sorry, we get our hands on an existing connection.
32:04
So without changing the internal state of the device itself, there is no disconnection at all. So it avoids some troubles. It works on all versions of the Bluetooth low energy protocol, versions 4.0, 1, 2, and 5.
32:21
But it requires proximity because you need to be close to the target to jam it. If you are not close, about five meters, five meters is good, you can jam the target. And I will demo this attack with some example devices. We are going to start with something everybody loves, drones.
32:43
So I found a drone on Amazon, and this drone uses BAD for the communication between the small application you install on your phone and the drone. So I decided to test it in my test bed.
33:03
It's too loud, I guess. Yeah. So as you can see, it's difficult to keep it in the, you know, on video.
33:22
But anyway, I start with a jack, and I'm going to hijack the connection by using this tool. So we got to recover this, your signature and map and so on. Then we are jamming the smartphone to disconnect the smartphone,
33:42
and it gets disconnected quite soon. So yep, smartphone is disconnected. The owner of the drone cannot pilot anymore the drone, but I have the control over the connection, and I can make it land.
34:09
Well, I know this is not impressive. So I made another video. So this, in this video, I'll trigger the emergency mode.
34:23
That causes a cut off of the motors, so yeah, but. So it's basically the same attack with two payloads. And I also played with, with some other devices,
34:45
and especially sex toys. I'm not a very great fan of sex toys, but anyway. Why sex toys? Because Penta's partners made some research last year. They coined the term screw driving. They were performing some kind of wire driving
35:00
and found this ash from love ants. And they wrote a complete post on their website stating that this is completely crappy and not secure and so on. Obviously, the vendor of this sex toy saw this article, saw this post and thought back.
35:22
They issued a statement saying that if your sex toy is on, but if your smartphone is connected to this sex toy, you're okay. Since it's not advertising anymore, nobody can connect to this sex toy.
35:43
I guess, you know what will happen in the next slide. So the sex toy is connected to my smartphone. Just to make the video short, I had to cut it off, to cut it a bit.
36:01
But in fact, disconnect the smartphone by taking over the connection with beta jack. Take some time. There is a little pop up on the smartphone. Yeah, this is disconnected. So the smartphone has no more control of the sex toy. And since it's UART over BLE,
36:22
it's quite easy to make it vibrate. There is no sound here, just to, you know. But it's still visual. You'll get my point. I found the characteristic and I wrote to this characteristic, a special string vibrate semicolon two.
36:41
There are 10 levels. So I don't know if some of you wear this kind of stuff.
37:04
Maybe, yeah, turn it off. So what are the impacts of this vulnerability? So you get unauthorized access to a device. So obviously, this was the case for the sex toy. Even if it's already connected, of course. If there is some kind of authentication
37:20
performed at the start of the connection, then you can bypass it. So this might be cool for some smartphone and so on. And also, since there is absolutely no modification of the internal state, since there is no disconnection of the device, this may leak valuable information.
37:40
If some characteristics are available in, you know, for read and write, you can make, get back some data that have been written to this characteristic. So this may be interesting. How to avoid this? Well, the BAD specification provide,
38:03
provide some kind of secure connections by using pairing. So if you're using the pairing mechanism and the encryption mechanism provided by the Bluetooth specifications, it should be okay. There is some kind of injection protection.
38:23
There is a message integrated code added to all the packets that avoid this kind of manipulation or this kind of, you know, consequences. But the fact is that the keepalive packets don't have this message integrated code.
38:42
So basically, you can take over the connection even if you are using this secure BAD connection. Well, you can do some kind of denial of service or I don't know. Or you can do it at the application level by using some kind of HMAC, some kind of authentication
39:02
for the data you're going to exchange. So there are some countermeasures, but yeah, it's up to you to use them correctly. So the tool is available online. It has been released this morning on GitHub.
39:21
You can also install it with PIP if you want. It's also this particular, oh yeah, I'm French. It's also available on PIP. So this BitObject tool is able to sniff already established connection and new BAD connections.
39:41
It's also able to jam connections to perform a takeover, hijacking, like we saw. And it's able to export in pickup and there is also a multi-sniffer support. I mean, if you connect two of them or three microbits to your computer, it will use them to parallelize some tasks. The channel map recovery is sped up
40:03
if you are using a lot of microbits with your computer. You know, we got the 37 channels split in four, for instance, if you are using four of them and it speeds things a lot. So to conclude, BitObject, well, maybe not in one solution for BLE sniffing.
40:23
If you want to have a look at this tool or to try it, you are more than welcome. Also, if you want to post some issues or if you find bugs and so on, I will handle them. So it performs BLE sniffing, jamming, and hijacking.
40:40
Hijacking works on all versions of BLE. Insecure BLE connections, as we may all know, are prone to sniffing and hijacking. So it might get worse with further version of BLE because the Bluetooth dig is trying to extend the range of the Bluetooth low energy protocol. So the Bluetooth 5 version of the protocol
41:02
is available, yeah, is capable of about 800 meters connection. So it's quite impressive and they might, you know, extend this range in the future version of this protocol. So if you're some kind of BLE device vendor,
41:22
you're more than welcome to secure your BLE connections. Yeah, do it. Thank you very much.