 So please just give a warm welcome to virtual labs. Thank you very much. So today I'm going to talk again about Bluetooth low energy protocol and about also new vulnerability I found in this protocol. So who am I? I'm the head of research and development at Econocom Digital Security, not the digital security in Russia obviously. I've been studying Bluetooth low energy about four years now, three years now, and I'm the developer and maintainer of Beetlejuice. Maybe you have heard about it. This is one of the framework I worked on, and I'm having a lot of fun with Nordics and my conductors system on chips. So let's start with the agenda. So we are going to go through the BLE sniffing 101. For those of you who don't know how to perform BLE sniffing, then I'm going to present Beetlejack, which is my new tool for BLE sniffing and much more. We are going to see what is inside this tool, why this tool, and in the next last part of the talk I'm going to disclose a new attack on BLE. All right, so let's start with some BLE sniffing, just a minute. So BLE sniffing 101. So basically if you nowadays want to sniff BLE connections and BLE communications between two devices, you need some tools, and you're lucky there are a lot of chip tools out there. So you may want to sniff with Ubatus one, sniff BLE connections, or you may want to use the Adafruit's Bluefoot 80 Sniffer, which is also a nifty tool, or you may want to do it the SDO way with the GNU Audio Software Suite. So let's start with the first one, the Ubatus one. So this is a tool that allows anyone to sniff existing and new BLE connections. I mean, if you use this tool, you can find existing connections between devices and also listen for new connections that happen on the target device. It did not support Channel Map updates. So it did not, because obviously they updated the firmware yesterday through the DevCon release. So they updated the firmware and it's not supported by the Ubatus tool. So this is cool. If you have one, just use this new firmware and try it by, you know, sniffing some BLE stuff. But the fact is that even with the new firmware, the Ubatus one has some issues sniffing on existing connections. And last but not least, it costs 120 bucks. So it's cheap, but not so cheap. The Bluefoot 80 Sniffer made by Adafruit, so it's based on a specific software written by Nordic Semiconductor. So it's a proprietary firmware that is used here. It was updated in November last year, so it's quite maintained. But this Sniffer only allows new connections sniffing. You cannot sniff an existing connection between two devices, already established connections, I mean. So this is very interesting for, you know, security analysis. But if you want to hack into existing devices or already connected devices, you cannot do this with this Bluefoot 80 Sniffer. It costs around 30 or 14 bucks, so it's affordable. And if you want to do the SDR where you are going to have some issues because the SDR modules exist in with GNU Audio are only able to get the BLE advertisements sent by the devices. So you cannot follow any BLE connection with this approach. The reason is very simple because of the latency. There is some kind of latency between the GNU Audio software and the SDR device you are using. And it do not allow to jump very quickly over all the channels used in the BLE connection. And that's why not least, it requires a 2.4 GHz compatible SDR device that costs some hundred of dollars. So it's again affordable, but it's more expensive than the two previous ones I talked about. So just to summarize this BLE sniffing 101 part of my talk, BLE basically is designed to make sniffing difficult. And it's working. It's not so easy to sniff BLE connections. Why? Simply because this protocol uses three separate advertising channels spread across the bandwidth. So you cannot listen to these three channels at the same time. You got to be listening on each channel one after the other to get all the information or maybe to use three devices to listen to these three channels at the same time. This protocol also uses some kind of frequency-hopping mechanism. So channel, but what we can also call channel-hopping. So this channel-hopping mechanism makes also sniffing very difficult because once a connection is created between two devices, these two devices are going to jump from one channel to another. And then you need to get the pattern they are using 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 these parameters are in order to sniff an existing connection, they might change between what you are measuring, what you are trying to recover these parameters. So this will mess your sniffing. So two cases here. You may have a lot of money and you can afford a lot of devices and make your sniffing on the all 40 channels, for instance, or if you want to do it the cheaper way, you got to struggle with the BLE sniffing. You won't be able to sniff very easily a connection for the first time, for instance. You got to wait multiple connections to get your data. So two years ago, I took another approach for capturing BLE packets. I tried some kind of mandimiddle approach. The idea of this mandimiddle approach was to have some kind of device in between your phone, for instance, and a device it's connected to, and then capture the packets. It's basically the same approach that we all do when we are going to perform some TCP mandimiddle, for instance. So how it works. First you have to discover a target. You get to find a target device. Obviously this device is advertising itself. There is nothing connected to this device. So it's advertising and it's present and so on. So you can connect to it, get all the information, all the services, characteristics, and so on, in a way that you can then impersonate this device. You connect to this device. It's not advertising anymore because of the specifications. For BLE version 4, once a device is connected to something, it only supports one connection at a time. Most of them do this. There are a few devices out there that only accept multiple connections. But it's very difficult for the system on chips that under all the other radio parts to handle two or three connections at a time. Because it requires to jump on different channels and different setup, different parameters. So this is not very easy. Well, you are connected to this device. It's not advertising anymore. So you can create a clone device with the exact same parameters, exact same services, characteristics, even the exact same Bluetooth address. So you can just spoof the device in order to say this. And you wait for connections. Once your phone is connected to your fake device, all you have to do is just to forward the data between your connection with the device and the connection with the phone. So you are in between and you capture everything. So this approach has been implemented in BitAdjust, one of the tools I was talking about in the introduction. And also in another tool called Gattaker, written by SlavoMir Jasek. And these two tools implement the mandemodal approach. Well, so it was working pretty well until the last three years. And it has a lot of advantages because you can get rid of the three advertising channel problem. I mean, if you are using this mandemodal approach, you are controlling the advertising of your device. So you are quite sure to get the connection and don't miss it. You can see every bit you should perform. If there is some kind of characteristic write or read or discovery, you can get all of this and you'll see everything. And also you can tamper the data on the file. Since we are in between the two devices, we can just change data on the file, changing some bytes and causing some troubles in the security point of view. But there are a lot of issues too. One year after having developed the BitAdjust software, I got a lot of issues on GitHub with people telling me, I cannot use your tool. It's quite complex to install because it requires one virtual machine and one host computer and some kind of network setup to make these machines communicate with each other. So it was a quite complex setup and a lot of people had a lot of issues putting all of this software on the computers and making it working. The other problem we have is that we only capture HCI events because we work at the adapter level where we don't get any link layer BLE packets. So we are one way, we cannot get all the information and especially all the pairing packets. So this approach, the manual approach does not support all types of pairing and this may cause a lot of trouble when you are trying to intercept encrypted connections. And obviously it's also compatible only with 4.0 adapters. Maybe you have heard about the Cambridge silicon radio USB adapters that allows some kind of Bluetooth device address poofing. Well, we got some troubles too with the latest version of the USB adapters or even the adapters provided within the motherboard of your computer. So the stock adapter of your computer may cause trouble with these software. So these are the accounts of the manual approach. So basically we are doing it wrong. Ubuntu's BTLE, okay it works but there are still some limitations even with the firmware update released yesterday. Nordic's micro-conductor is closed source and may be discontinued. So we don't know if this software is going to be maintained and we don't know what will happen if Nordic's micro-conductor decides not to continue the development of this software. So maybe a problem. And the manual approach is great but it's too much difficult to use and cause a lot of trouble for users. And also it cannot get all these link layer packets because we are limited by the solution we opted for. So it's time to improve the BAD arsenal. So basically what would be the ideal tool to sniff BAD connections? Well, we need a tool able to sniff both existing and new connections. We also need a tool that uses cheap hardware in order to make it affordable, you know, to lower the ticket for BLE sniffing. And of course we need open source software to be able to maintain it, to contribute for allowing other researchers to push new features for instance. So this is something very important here. This tool needs to sniff new connections. I'm going to go deeper at the protocol just to show you how it works in the internals very quickly. For new connections, the goal is very easy. We need to get the connection request PDU which is in fact a dedicated packet sent by your phone for instance when you're trying to connect to a BLE enabled device. And in this packet there is everything we need to monitor or to follow the BLE connection. We got the CR30 value, we got also the channel map and so on. So if we capture this packet, we are able to follow the connection and then to sniff the packets. But for sniffing this packet, we have to be at a very specific moment listening on the specific channel when this packet is sent. And as we saw this previously, there are three advertising channels. So you must just listen on one channel to another hoping that this packet will arrive at a specific moment. Or you may want to sniff on these three advertising channels at the same time in order to get this packet. So in order for this to work, we need this situation. We need to listen at the same time to these three advertising channels. So this one is quite easy to sniff a new connection. The trickiest part is the active connection sniffing process. So in order to sniff active connections, you don't have all of these parameters. You don't know the connection parameters. So you have to get them. And in order to get these parameters, we are going to make some measures. Mark Ryan, the author of Ubato's BTLE, I cited just before, created his own technique to recover these parameters. And his technique is the following. First, he tries to identify what the protocol calls an access address. An access address is a 32-bit value used to identify a link between two devices. So this access address is used to identify a specific connection. Once the access address is known, we can recover the CRC init value that is used to compute CRC. This is some kind of seed used to compute the CRC value 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 device we spent on each channel. So 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 77 data channels used for the channel hopping pattern. And of course, we can also recover the hop increment, which is the number of channels added to the channel index each time the connection jumps from one channel to another by using some kind of protocol. So Mike Ryan designed a pre-computed lookup table. And the Ubuntu BTD, for instance, measured the time between two consecutive packets on channel zero and one. By using this technique and the lookup table, we are able to recover the hop increment value. So this is Mike Ryan's technique as it was implemented in the Ubuntu BTD software. And it's still the case. Even with the update made yesterday. And of course, Mike made some assumptions back in 2013. 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. And they determined these data channels by using some kind of channel map. This is a parameter sent in the connection request PDU that specifies which channel are going to be used and which will not. So if not all the data channels are used, 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. But normally, you will find only once in the normal sequence if it's not reused. So by modifying the sequence order and making this channel appear twice, if you just measure the time between two consecutive packets on the channel four, we will get two values, two different values. And this makes MaxTechnique useless. This does not work anymore. So how to deduce all of this based on this new behavior? Well, 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. So there will be some kind of time that you have to implement to get these values and 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 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 you then deduce the hop increment based on this. But we don't use a precomputed lookup table. 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 the more generic version of Mike's technique. But it works pretty well. There are a lot more details in the proof of concept. I'll get the fuck out number 17. I'll write a paper with all the algorithms and the math behind this technique. And all of this is going to be implemented in a little jack. There is also another trick here for sniffing this connection. In the specification, there is a parameter called the instant. When a device updates on some parameters, say the channel map for instance, it's in a packet telling the device that the channel map will be updated 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. We may lose the signal and lose packets. So the fact is that, really, we don't really care. We don't really care because once a channel map update packet is issued by a device, whoops, sorry. So once a channel map packet is sent by the device, at a specific instance, we don't know the hoping sequence will change. And then we are going to sniff on channel 11 in this case, while the sequence will go to channel 1. 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 hoping sequence and re-synchronize with the communication. So by using this little trick, we can just follow any connection and support the channel map update process, even if we don't know the instant value for this pre-sized connection. So all of this is implemented in Beta Jack. And so I decided to create this new tool. And I'm very proud to present it at DEF CON this year. This is a brand new tool based on Microbit. Again, this is a tiny device, 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. But in fact, we can turn it into some kind of hacker 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 other food, blue friend, Ellie Sniper, for instance. You can also stack them and create some sniffing rig. She wanted to do this. So basically, I modified the cluster art for Raspberry Pi. This is just a USB 2, USB hub. But it's quite huge. It's quite useful. I had to find a name, obviously, so since I'm not a very creative person, you know. You see, it's got Beta Jack because of the new availability I'm going to present in the next section. But anyway, this tool is quite, you know, quite useful. But I won't do any live demo because I know you first. I know if I put some kind of beady 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 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 that sniffing of a new connection. So I specify the Bluetooth device address in the parameter and as you can see, 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 an valid access address. 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 Beetlejack will recover all the required parameters to follow, to be able to follow the connection and then to sniff packets. So it recovers the CRC need value, 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. So again, existing connection, well, not really a problem with Beetlejack. And to offer some other features, there is a pickup export possible. So if you're interested in packets with Beetlejack, you can export these files into a pickup file. Obviously it was expected for this kind of tool. But it also supports the specific format for the pickup file that makes it able to use with Cracalli. Cracalli 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 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 the details of the specifications and I stumbled upon a very specific, you know, not a weakness but something I mainly feel bad. I don't know what it was. I was reading the section about the supervision timeout in these specifications. And just to summarize it a bit. So the supervision timeout is provided by a device in the connection request PDU. So this is a parameter sent 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 with a 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. So this supervision timeout is enforced by both devices. I had quite an idea about it. What is timeout timeout? What if we jam some specific packet at a specific time? Let's see. 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 and there is some kind of a keep a life 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 considered the connection not lost but with no valid data. So it starts a timer and we do this sometimes until the supervision timeout is reached. And then the central device considered the connection has lost. But the fun fact here is that the peripheral still gets packet from the master 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. So it's based on jamming. First of all I implemented the jamming feature in the beetle jack. So this is just a short video. I don't know many times. So I'm connected to a specific device and I'm using beetle jack to jam the connection. I don't know if it's going to be alright. So in order to jam the connection you get to recover all the required parameters and all these CRC in it, channel map, hop interval, hop increment and so on. And once the beetle jack is synchronized with the connection it starts jamming by sending bad 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. So the idea of this attack, which I call it beetle jacking because of the tool but anyway, it's this attack abuses BAD supervision timeout to take over a connection. So basically we get our hands on an existing connection. 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. But it requires proximity because you need to be close to the target to jam it. If you are not close but 5 meters is good, you can jam the target. And I read the model of this attack with some example devices. We are going to start with something everybody loves, drones. 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. It's too loud I guess. Yeah. So as you can see it's difficult to keep it in the video. But anyway, I stopped beetle jack and I'm going to hijack the connection by using this tool. So we got to recover the CRC and map and so on. Then we are jamming the smart phone to disconnect the smart phone and it gets disconnected quite soon. So yeah, the smart phone 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. Well, I know this is not impressive so I made another video. So in this video I triggered the emergency mode. That causes a cut off of the motors. So it's basically the same attack with two payloads. And I also played with some other devices and especially sex toys. I'm not a great fan of sex toys. But anyway, why sex toys? Because PENTA's partners made some research last year. They called the term screw driving. They were performing some kind of ride driving and found this ash from Lavence. 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 and saw this post and sent back. They issued a statement stating that if your sex toy is on but if your smart phone is connected to this sex toy, you're okay. Since it's not advertising anymore, nobody can connect to this sex toy. I guess what will happen in the next slide. So the sex toy is connected to my smart phone. Just to make the video short, I had to cut it a bit. But in fact, I disconnected the smart phone by taking over the connection with Beta Jack. Take some time. There is a little pop up on the smart phone. Yeah, this is disconnected. So the smart phone has no more control of the sex toy. And since it's UART over BLE, it's quite easy to make it vibrate. There is no sound here. But it's still visual. Look at my point. I find the characteristic and I wrote to this characteristic a special string vibrate semicolon two. There are ten levels. So I don't know if some of you wear this kind of stuff. Yeah, maybe turn it off. So what are the impacts of this vulnerability? So you get unauthorized access to a device. So obviously this was a case for the sex toy. Even if it's already connected, of course, if there is some kind of authentication performed at the start of the connection, then you can bypass it. So this might be cool for some smart talk 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. If some characteristics are available in forward and right, you can may get back some data that have been written to these characteristics. This may be interesting. How to avoid this? Well, the BLE specification provides some kind of secure connections by using pairing. So if you are using the pairing mechanism and the encryption mechanism provided by the Bluetooth specifications should be okay. There is some kind of injection protection. There is a message integrated code added to all the packets that avoid this kind of manipulation of this kind of consequences. But the fact is that the keeper of packets don't have this message integrated code. So basically you can take over the connection, even if you are using this secure BLE connection. Well, you can do some kind of dinner 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 for the data you are going to exchange. So there are some countermeasures but it's up to you to use them correctly. So the 2DV is available online. It has been released this morning on GitHub. You can also install it with PIP if you want. It's also available on PIP. So this bit of Jack tool is able to sniff already established connections and new BLE connections. It's also able to jam connections to perform a takeover, hijacking, like I said. And it's able to export and pick up. And there is also a multi-sniff support. I mean, if you connect two of them or three micro bits to your computer, it will use them to parallelize some tasks. The channel map recovery is a sped up if you are using a lot of micro bits 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, bit of Jack, well, maybe not in one solution for bit of sniffing. If you want to have a look at this tool or to try it, you are more than welcome. Also, if you want to put some issues or find bugs and so on, I will under them. So it performs bit of sniffing, jamming and hijacking. Hijacking works on all versions of BLE. Insecure BLE connections, as we may all know, apprentice sniffing and hijacking. So it might get worse with further version of BLE because the Bluetooth is trying to extend the range of the Bluetooth low energy protocol. So the Bluetooth 5 version of the protocol is available, yeah, is capable of about 800 meters connection. So it's quite impressive and they might extend this range in the further version of this protocol. So if you are some kind of BLE device vendor, you are more than welcome to secure your BLE connections. Yeah, do it. Thank you very much.