 basics of breaking VLE. I'm a freaky zen. I want to thank you for joining me and I want to thank the wireless village for featuring me today. Also I want to thank DEF CON for going into safe mode and allowing us the space to interact and learn with each other. So I've got a few things planned for us today. We've got some just going over the basics of what VLE is as far as the technology, just how expansive it is. Some kind of tools and techniques that you can use for pen testing or just exploring Bluetooth low-energy devices around you. So as you can see here on the desk I have a few devices. We have the bomb badge from DC-27, Team Einds. We have HACNAR's BLE CTF. If any of you have seen any of my in-person talks, I usually try to feature this piece a lot because I feel like it's a very easy sort of entry point for people to learn how to interact with GAT services on Bluetooth devices. So going on we also have a Thingy 52. This is a development tool and learning tool from Nordic. This has its own application that you can interact with sound and different gyroscopes and LEDs and all sorts of fun things. And then of course we have N-AUDEX ORS DC-27 badge that has a Bluetooth mesh network on it. We'll look at some of this and some interesting things that I found on the badge poking around looking for demonstration items for today. We actually also have the LG Phoenix LG 150. This phone is important because it's the only one that I have found so far that allows for a live capture of the BT snoop file from an Android device into Wireshark. I feel that the live capture is important when you're auditing devices because you can actually see the command interactions between devices and the changes in real time. If I hit this button and this command comes across the wire then it's probably pretty obvious but that is the command that's controlling that and if you can see a difference in the variables then you have an easier time in reversing the commands and actually being able to find meaningful exploits or meaningful ways of interacting with devices. So going on, the last item that we have is the Adafruit Bluefruit LE. This has some services that I built on it for DC-27 actually. So we will look at actually cloning this device and spoofing it against a target. So just a short introduction to who I am. My name is Maxine Filcher. I also go by Freaky Zen online. Security Consultant with IO Active, Sarmie Veteran, graduated class 2020 with the BS in Info Assurance and Cyber Security. I also have a minor in Law and Policy. I'm also a member of the Sands Women's Academy 2018 cohort where I earned the GSEC, the GCIH, and the G-PEN. I am also in the process of studying for the GAWN. So just a small disclaimer, I'm not a Bluetooth developer by any means but I have been teaching about Bluetooth hacking and just general Bluetooth concepts for a couple of years now. So I feel like I am fairly well-versed in this topic. So in any of my demonstrations, I always like to frame wireless security as greater than just Wi-Fi or just Bluetooth. In PIN testing, when we see companies talk about wireless PIN tests, generally they're talking about their Wi-Fi and they are completely ignoring a lot of other vectors that could occur with wireless. So I always like to bring up this kind of definition, I guess this contrast in definition, this weak definition from Wikipedia where it's wireless networks, which I mean I guess could be broadly interpreted, but I much prefer the NIST, which I believe is still current. It may have been updated, but the NIST definition of wireless enabled technologies, I feel it's more encompassing of everything that you could encounter. So we talk about wireless, just kind of continuing that discussion. You know, many different technologies. We have Bluetooth, Wi-Fi, ZigBee, RFID, NFC, CEL, SAT, and these come into a number of different industries. So medical is one that is growing pretty rapidly as far as Bluetooth low energy and then of course IoT, the things around us, all these smart devices that really rely heavily on Bluetooth low energy to communicate. Then Industry 4.0, Bluetooth is starting to get more into automated systems within factories and smart buildings and also smart automated HVAC systems or just building control systems. So Bluetooth is really starting to make its way into these important and sometimes high risk systems. So Bluetooth is becoming more of an important research topic and target for actually pen testing as we go and as the technology develops. So just a few basics about Bluetooth. You'll find it in, you know, within the ISN band, so 2.4 to 2.485 gigahertz in this case for Bluetooth low energy. It comes in a few different flavors, you could kind of call them, although the protocol stacks are different in some ways and and similar in some ways. The original Bluetooth that came out we refer to as Bluetooth classic or enhanced data rate. Any more you will find that in things like wireless headsets. So, you know, your Bluetooth headsets, anything where you're streaming, data that needs larger packets and maybe higher throughput, that will generally go through on Bluetooth classic or BREDR is what it's known as now. Bluetooth low energy is what it is described as. It's a low energy protocol. It's intended to be used in devices that could run on a coin cell battery for up to a year. So that's a pretty heavy design specification for something, you know, that is low touch. You can put it somewhere and it's supposed to be able to work and, you know, you're not supposed to worry about the power and you can interact with it all day long. It's something new that's emerging and I mentioned it with the NodExor badge is Bluetooth mesh. Bluetooth mesh is actually you could kind of think of it as a hat that goes on top of Bluetooth low energy. It uses some of the underlying components but it adds things like provisional keys and application keys and it's a it's a mini to mini connection and it's very interesting. It can use, you know, pathways across other devices and set up nodes. It's a very interesting portion of the protocol but we aren't really going to get into Bluetooth mesh too much. So just some other numbers, of course, you know, Bluetooth low energy is blowing up still all across the world, all these different technologies. I'm sure you have more than more than a few Bluetooth low energy devices around you right now. I also I also love to throw in, you know, little tidbits of history about Bluetooth. I think it's got kind of a fun origin with the name and kind of the intentions behind it. So you can see that if you've ever wondered where the Bluetooth symbol comes from it's actually a mixture of two runic symbols, one for H and one for B. And this is actually for Harold Bluetooth who was the king of Norway and Denmark. He was seen as a great unifier of these countries and and brought together these nations. If you've watched Vikings, the history channel series, you might recognize the guy that whose picture I've pasted up there but yes, it's loosely based on the on the same on the same person on the same historical character or figure. Another person that I really love that is integral to the development in Bluetooth but not really in sort of a direct creating of the protocol or anything like that. But Hedy Lamar, I love the story of Hedy Lamar. I love the story of her, you know, totally being just underestimated but being so brilliant and for those who aren't familiar, she was an actress in the early part of the 20th century. And she came from Austria, fairly scandalous kind of background, had left her husband who had decided to supply arms to the Nazi party. She came to the United States and she befriended a man named George Anthel and together they worked on a concept for creating a torpedo that was basically protected against jamming or the interruption of the signal, whether that was intentional or unintentional for torpedoes that were fired from either or allied submarines or allied ships. A lot of times these torpedoes, when they were fired they would either get jammed or they would lose connection and sometimes they could actually backtrack around and hit the ship that fired the torpedo originally. So this was at the time was actually a fairly large concern and it was something that was a kind of an operational hazard that you had to put up with and together they came up with this concept of frequency hopping spread spectrum. And this is where two devices, two transceivers, would have the set channel set within them that they would hop across at a set interval and at a set rate. So once these were loaded in they would hop across the frequency spectrum in a way that would skip just pinpoint jamming or just any kind of natural interference since it was skipping across frequencies. So this was actually a fairly unique idea at the time. It was based on player pianos, synced player pianos, which is kind of cool. If you have kind of more interest about this story there is an amazing documentary on Netflix called Hedy Lamar or bombshell the Hedy Lamar story. Highly recommend that you check it out. It's a little bit sad but if you're curious about the background it's a really amazing story. So let's get into a little bit of terminology. So as far as devices within Bluetooth connections we can think about devices in two ways, central and peripheral. So your central devices are generally going to be your phone or the device that the user is actually interacting with. So you know whether that's a tablet or a laptop or a TV or something like that where it's actually initiating the connection to whatever peripheral device say that's any kind of device that you're going to connect to that's a peripheral device. It's not something that you are directly interacting with with like an application on your phone that's generally going to be a peripheral. So connections are also something that's important in Bluetooth obviously it's a wireless protocol so there has to be some sort of way the connections are handled. Bluetooth low energy just like Bluetooth has set channels where it advertises itself on or to central devices that may be looking to connect to it. So it has three set channels the Bluetooth low energy has three set channels that will broadcast across 37, 38 and 39 and there are also four advertising PDU types I won't go over those you can look them up. They don't really have too much impact on what we're going to talk about today. So we also have 36 channels for Bluetooth low energy separated by two megahertz across the spectrum and when we're also speaking about connections we think about them in two phases sort of. Once you see the advertising of a device that you want to connect to say from your phone you will initiate the pairing process. I'm fairly confident that most people are familiar with the pairing process but it's where you initiate a wireless connection and these come in kind of two phases so you have your basic pairing session where you're unbonded or you've passed your short term keys between the devices. So they have established a connection but it's not trusted on on certain levels and it's not been placed into the devices have been placed into each other's sort of trusted devices list. So once you create a bonded connection that will actually those devices are actually transferring long term key information between each other. In most cases they'll go into a trusted device list so that either the short term key pairing process can be skipped or there's no need to even initialize the pairing process again at all. You can just you know whenever you're in proximity of the device it will just automatically connect to you. So that's one of the benefits of bonding. Another benefit of bonding is you will oftentimes have greater leeway in the the amount of kind of tolerance for fuzzing on a device. So if you just have a short term key pair with a device and you try to start fuzzing GAT services there's a good likelihood that that device will in that pair. Once you've bonded with a device there is a greater chance that that connection will survive any kind of fuzzing that you do onto the GAT services. So we can talk a little bit about sort of the evolution of the of the Bluetooth protocol stack. We talked about how it kind of comes in multiple flavors and you can see that we have classic BREDR there and then you can see the the hybrid version of smart ready and now Bluetooth smart which most new Bluetooth low-energy devices coming out should be Bluetooth smart. Although most of your most phones will have the ability to use BREDR in the case of say Bluetooth headphones or that sort of thing. There is also a new audio protocol that is coming out a new Bluetooth low-energy audio protocol. It was announced earlier this year. I haven't personally seen a lot of specifications on it but I'm sure that there are people that can answer lots of questions about it already. But it's interesting. I'm excited from a security researcher perspective to get my hands on some of the devices just because it sounds like it might have some issues but we'll have to see. So yeah just some of the basic components of the protocol stack that we're going to really pay attention on today is GAT. I've already mentioned it a couple of times but it's the generic attribute profile. These are where the profiles of the services that a device can offer are stored. So you can think about this as sort of a catalog of things that a device can do. Whether that's measuring heart rate or giving temperature or you know measuring humidity levels. There's a GAT service and then there's a way for that information or that service to be interacted with. So there is a way to retrieve that temperature or that humidity measurement through the GAT services. Primarily we're going to be interested in GAT services today. Okay so we've already talked about that. So when I talk about GAT hacking, what I'm really talking about is the abuse of read or write privileges on a device over their GAT services. So in the case of iOS read privileges can be abused fairly easily and you can do things like retrieve the cell phone username, the battery level, the OS version, which may not be such an issue on the surface but once you start poking lower into the protocol or into this vulnerability, especially with the proof of concept called Apple BLEEE, you can see that there are some significant interactions that are available over GAT and there are some very significant information disclosures from iOS. So a few simple write privilege abuses that I have seen in devices that I've pen tested are just sending simple codes. So picking out of a GAT service and I just start fuzzing codes. In some of the real world cases that I've seen, you know, writing the hex value 0x08 and that enables me to set up a new pin between the devices. So now I'm defeating one of the very few security measures that you have for controlling Bluetooth connections. Further still I've been able to achieve over the air firmware update mode. So writing 01 to a GAT service will actually allow you to push firmware to a device. I mean, you obviously could get lower interactions than potentially placement malicious firmware onto a device and then, you know, who knows you'd own that device then. Other devices I've seen like write 02 to a GAT service, a specific GAT service and it would start a heating cycle on a device. So, you know, potentially there is danger there. So Bluetooth low energy does have security. It's developed through the years, mainly in response to security research that's been done where, you know, a big set of vulnerabilities comes out and the technology has to respond to that in kind of a dynamic way or, you know, they risk really losing their customer base. So Bluetooth SIG has done a fairly decent job of of responding to security researchers and trying to get chip manufacturers and developers on board with everything. But yeah, so there's a there's a lot of space for growing and there's also a lot of space for research. So Bluetooth low energy has currently I would say the standard would be 4.2, although BLE 5.0, the new standard that came out has some pieces that strengthen the just works pairing by introducing some nonce values, the more entropy the better. We have protections against man in the middle, we have protections against eavesdropping and theoretically there's authentication via pairing and bonding, but we can see that oftentimes it's not the case and that can be abused pretty easily. So some of the Bluetooth vulnerabilities that have come out in the past. Once I started getting into Bluetooth pretty heavily, BlueBorne was pretty fresh. It was fairly new. And it seemed to scare a lot of people. That's when I noticed Bluetooth security research really kind of starting to kick up again. It seemed like it had died off before that. And since then, there have been major vulnerabilities that's released every year. I think there were two as well spin tooth was released earlier this year and then there was a new set that they release a new vulnerability set that they released just a couple of weeks ago for spin tooth. So interesting piece about or interesting trivia piece about spin tooth, it's actually named after the son of Harold Bluetooth. So kind of cool marketing piece that they did in there. So spin tooth, since it's brand new, we'll talk about that really starts to attack the protocol in ways that we that I personally haven't been testing it and just fuzzing the header values and fuzzing the protocol in a way that just makes things stop working. There are a lot of denial of service vulnerabilities within this. A lot of deadlock security bypasses that are included within this. And it's fairly expansive. There are a lot of vendors that are impacted by spin tooth. So a pretty cool piece of research I personally haven't had a lot of time to jump into it. But I have read through it quite a bit, and it's pretty interesting. These are just a few of the Bluetooth tools out there that you can use. Some of these are proof of concepts, but they have neat scripts that you could either alter or actually just use as they are. So the first tool that we're going to look at is the uber tooth one. Let me switch over here. And so I have one right here. So older device, a few years old. But it's still probably the best way to ingest externally viewed Bluetooth packets into wire shark. And I say externally because this is what I consider to be looking from the outside in to a Bluetooth connection between devices. So generally, you won't see a lot because things should be encrypted. Although I have seen some devices that say they are doing things, but they aren't actually encrypting things. So you're able to pull commands out of the air. But this is still probably the best tool that you can use for that use case for trying to check encryption or trying to check a device connection for its strength against eavesdropping and passive sniffing. So the greepfet one is a tool that's still currently in development, I would consider. The Quincy was announced as the first sort of hat that was going to be added to this add on hat. And it would allow for full spectrum sniffing of Bluetooth low energy. So instead of having to use an uber tooth, which is locked into one advertisement channel at a time, you would be able to sniff all 36 channels at a time and be able to see basically all the Bluetooth information that's going on. So much easier to kind of manage as far as mass sniffing operations. But as of yet, as of today, there's still no release date. And I haven't heard anything about a price. Maybe that'll change with DEF CON coming up. So this is being recorded beforehand. So maybe there's already been an announcement and if that's the case, then disregard this portion. So another tool that you probably won't get to use, or probably won't see unless you have a lot of money or you work for a bigger employer is the ELISIS system, which relies on SDR. And it's the same kind of concept as the Quincy in that it's looking to do a mass spectrum capture. So it's trying to capture all of the Bluetooth packets that it possibly can. And then you can go through there and sort it by connection and see everything. This system will go even further and in some cases will strip the encryption off of the packet. So the software is actually pretty cool. I've had the chance to use one of these systems. And yeah, it's a very powerful tool that you can do a lot of really meaningful research with. But there is a huge price tag that's associated with it. So that brings us to NRF Connect. NRF Connect is what I generally use on engagements first. So I will exhaust every avenue possible with NRF Connect, because it's free and it installs on any smart device. So or well, you know, Android or iOS. So it's highly available. It's extremely simple to use. It allows for abuse of GAT services. It also allows for cloning and spoofing. So it's a fairly useful tool. So that's where I like to start all of my engagements with, because if I can prove that there is impact from this free and highly available tool, then the chances are then you probably have larger problems. And someone with more technical ability or more powerful tools is likely going to be able to have even greater impact on your systems. So, you know, let's take a sort of low hanging fruit first approach. So I always start with NRF Connect. You know, it was intended for debugging, but it works wonderful for the purposes that I need. One of the great things that you can do with this is record macros. So sometimes devices will only allow for momentary connections. Just long enough for two devices to basically pass short term keys and decide that one device say that I don't want to talk to you because I don't know who you are. Well, it's still in that period of time. There may be two seconds, three seconds where you have the window to actually send GAT commands in. And if you can capture that and potentially send a command to a device, you may actually get interaction with it. Even though you're not establishing a long term paired session, bonded session, you're just that momentary connection. So I really enjoy the macro feature. And of course, you can also export the logs which, you know, help for reporting. NRF stiffer we won't actually talk about. So BetterCat is a tool capable of interacting or allowing you to interact with GAT services of a device, but from a Linux machine using a BLE dongle. So Kismet has the ability to do this too, but I feel like BetterCat has a slightly better UI for this. But it can be a little bit difficult to install. But yeah, you have the ability to send requests and commands over GAT. So it's still a very powerful tool. If you're interested in doing this from a laptop or, you know, a desktop rather than a mobile device. Another powerful tool from a desktop machine is Scapi. So Scapi actually will allow you the ability to script. And this is very powerful once you start looking at these deeper interactions. So if you wanted to follow along with the SvenTooth vulnerabilities, you could actually craft packets using the Scapi library to attack those specific pieces of the protocol and, you know, push different kinds of data to them and potentially push them over. So if you're looking to do that deeper kind of penetration testing or research on Bluetooth energy, low energy, Scapi, the Scapi library is definitely something you'll want to check out. Another essential tool that I use on just about every one of my pen tests for Bluetooth low energy devices is Android debug bridge. For those of you who might not be familiar with this, this allows you to create a PC interface to your Android device over USB. Generally, most phones won't allow you to do the live capture of BT snoop logs, which is where Bluetooth low energy connections and data is logged to. So in the case of the LG phone that I have here, the LG M150, that will allow for us to do a live capture into Wireshark and we'll actually look at this here shortly. So just some basic installation instructions if you're not familiar with ADB, very simple to set up, very easy to get going and use. So I mentioned Kismet earlier, if you're not familiar with Kismet, it also supports Bluetooth low energy, but it has some limited functionality, but they may be increasing that as we speak. So that tool is definitely growing in its functionality and its capabilities every day. And we've mentioned Apple BLEE, a wonderful proof of concept for the security issues that are really inherent within the iOS Bluetooth low energy stack. This is a lot of fun. I've done some private talks where I've actually attacked entire rooms full of people and AirPods are popping up on everyone's phone. So it's a lot of fun, but it can also be scary for Apple users to see that you can get that much interaction with their devices just through Bluetooth low energy. The BlueBorn scanner, it was deprecated, but I've actually seen it back on the store or on the Play Store and I can still download it and still use it. But the likelihood that you're going to find a device that is actually still vulnerable or pops up as vulnerable is going to be highly unlikely at this point. Most manufacturers have patched or updated things against this. So it used to be a couple of years ago you could walk into a Best Buy, run this BlueBorn scanner and almost every TV, every display TV that they had on smart display TV would pop up on your BlueBorn scanner and would give you all kinds of information. And then from there you could actually use proof of concept scripts to actually attack these TVs, but you know those are different stories. But as far as I know, BlueBorn is pretty much patched up and is no longer a risk. So a few challenges that we run into in Bluetooth low energy as far as security researcher challenges. Most of the modern connections are encrypted. So they're hard to see from the outside. So unless there is a companion application on Android that I can use the Android debug bridge on, it's very hard to reverse commands. You know, the Uber tooth can follow connections, but I can't see inside of those connections that are encrypted. Crackle is largely ineffective anymore for breaking pins. So you know, good luck breaking pins. I know that there has been some research done in attacking the entropy levels of the pins that are generated. So that's kind of been a potential. But as far as I know, there isn't a reliable way of breaking pairing pins at this point. Commercial sniffers are also really expensive. And the cheaper alternatives really don't outperform the Uber tooth. So a few approaches to BLE. Sniff the broadcast traffic. So look from the outside in first. Is it encrypted? What can you see basically? What are they leaking? What could you potentially do without any kind of interaction with the device? Is there any kind of information leak? Are there any issues with configuration? Yeah, that sort of thing. The next step would be to look from the inside out. Using something like Android debug bridge and looking at the unencrypted packets that are coming in. So Android debug bridge allows you to look at the Bluetooth low energy packets once they've crossed over the HCI threshold. So they've been stripped of the encryption layer and you can actually see the commands that are getting sent over the wire. Attempt out-of-app connection. So just try to use nrf connect. Connect to a device. See if you can create a paired or a bonded session. And then just start buzzing values and see what interaction you get. Sometimes you'll get devices to lock out. Sometimes you'll get devices to actually do what they're supposed to. Sometimes you hit the trigger. And then the next thing is to spoof a device or check for cloning protections within the application itself. So these are kind of the four things that I really look for in a pen test. So hopefully that helps you kind of frame and contextualize what we're going to look at here in a second. So let's get into some hands-on stuff. So short list of equipment. The Nordic thingy 52, Bluefruit LE, the LG M150, the Samsung S20 I'll be using as the victim. But I will also be showing you the screens that the attacker would see on that phone. It's just kind of a technology and display matter at this point. So and then we'll of course be using nrf connect. We'll be using the thingy app, then the Bluefruit Connect application. We'll also be using ADB and Wireshark. For an external scan, we're going to start with Ubertooth. And we're going to go through the basic setup. I just set this up on my computer. If you go to the GitHub page and go to their wiki for the Ubertooth, there are really good setup instructions. You just go line by line. I didn't have any issues on the newest version of Kali. So hopefully you don't. But yeah, you never know. This is where we will be using ADB to do a live capture of the BT Snoop file on our LG M150. So let me get the phone hooked up here. We are going to launch ADB. So we would launch by using ADB start server. Mine's already started, but we'll just hit it again. And then we use ADB devices. And you can see our LG M150 is right there. So I plugged a different phone in. And we can see the device that I'm using here to capture the BT Snoop file on. We go over to Wireshark, which I already have started. And we can see that we have this BT Snoop interface that's opened up here. Now, it's important to note that the LG M150 has to be running Android version 7. So I just tried this a second ago with a different LG that I have, and it's running version 6. And it does not open up the BT Snoop. So you'll have to actually update the version of Android. Luckily we have pre-recorded videos this time so I can go in and actually edit out some of that stuff. So we have our BT Snoop file here. Let's go ahead and start the Sniffer. So our Sniffer is now running from our phone. So I have the phone connected here. And what we can do is start trying to connect to devices. So for instance, I have this thingy 52 on the desk here. I can turn this on and I can open up InterF Connect. And you'll see the packets are starting to come in here. So we can see I'm going to connect to the thingy device here and you'll see the packets start to change. We can create a connection to our thingy 52 using the thingy connect app. And now that I'm connected, I'm actually reading data from this device from the thingy 52 onto my phone. So I can do things like play sounds. Now that's as I'm pressing here, you hear the sound on the thingy 52. So those commands are coming through the GAT services. Commands are being written from our phone to the GAT services that are being offered on the thingy 52. So since we have this hooked up in an internal fashion and we can see these packets, you can actually see what commands are controlling what. So if I hit this tone, we can see that there are packets coming across. Send right here. And this is the value that's being written to that GAT service. So let's try a different key. Okay, let's see if that value is changed. You can see it's changed to an eight from a five to an eight. I would also suspect that one is the on and off, right? So the first right is the on the second right is the off. You can see all f's in the middle there. And then we see all zeros in the middle. All f's all zeros. Okay, so that's a pretty basic look at how we see commands and we're able to reverse command values that come across the wire internally. So how do we actually then interact with or take this information and use it to then test if there is any unauthorized access to the GAT services or if we can get any interaction to the device from an unauthenticated source. So let me bring up the screen here and I'm going to use my victim device here or in this case, my attacking device to actually seek out the thingy 52 here over nrf connect. So this would constitute an out of application connection. Since the thingy 52 has an application that controls all of the interactions, using an application like nrf connect to directly interact with the GAT services would be considered an out of app interaction. So let me scan. So we have this thing here. That's my that's my thingy 52. We'll go ahead and connect to that. So you can see right off of that we have a connection, but it's not bonded. You'll also notice up here in the right hand corner is the DFU button that will actually allow us to push firmware updates over the air. So not all devices and most consumer devices will be locked down from this. But, you know, not all devices will have this. But if you do see this, this would constitute a fairly major vulnerability in this device, especially since we have a short term connection since there hasn't been long term key information passed. Let's go ahead and open up our sound services. So when we were looking at the other at the other screen here, let me go to Kelly and phone. So when we were looking at the other commands that we that we captured from the internal from the ADB capture, we saw our read and write commands. So those were being written to the handle 005B. And that was in the sound service. So let's look in the sound here. So if we open up the handle, we can see the full UUID there. Okay, so the thingy speaker data characteristic is what we saw being written to. So we can actually use this upload command. So we have right permissions to it. And we can use this value that we have here. So we have 8701FFAA. So let's try and push this. This was a write command. So let's make sure that it's placed in command, you have the option between request or command. And this was sent as command x 52. So we'll send it as a command and we'll see if we can get any interaction here between our device and our attacking device. There it is. There it is. So we're now attacking from there. And just like I thought, so the all F command is the on command. So when we saw the right, that that was the F. So we've sent it the option to be on. So it's on right now. And you can hear it in that tone. So now let's write the off command. So that was 8701 0005a. And we send that as a command. And now it's off. So that is a very robust look at your basic GAT hacking. We abused an unauthenticated out of application connection to a device, our thingy 52 in this case. And we used a command that we reversed from other information into getting this interaction from an attacking device. So say this was something else say this was, I don't know, I don't know what kind of user device you would have but say it had some purpose and you had this in your pocket, but it also made noise like that. And say somebody had reversed these commands and knew that these devices were vulnerable or that you could just arbitrarily write these commands to GAT services. So if you could walk around, identify that these or where these devices were, or when they were in proximity, you could automatically attack these devices so that everybody was walking around that had one of these in their pockets, they would automatically get this tone just going off in their pocket and they would have to shut the device off. So you can see where there is user impact. And there's also a circumventing of protections that are in place for Bluetooth low energy. So successful GAT hacking there. Let's switch over to some more slides here. We used the internal scan to reverse the the Bluetooth commands that we saw coming across the wire and then we use that in an out of application attack. So let's move into cloning some services. So this will enable us to really attack the application. Generally, there isn't a lot of value in spoofing against a peripheral, say like spoofing a user device. Although I have seen that be, you know, a valid find where you can impersonate a legitimate user's phone. And then there is some interaction with the device. But without the long term keys that have been passed, there's a really, you have an uphill battle basically in trying to spoof a user device against a peripheral. So what we are going to do is spoof a peripheral device and we are going to watch the victim attached to it from their application and basically see all of the interactions that you normally would. And you don't even know that you haven't connected to your device. Meanwhile, if we were to push this further, what that would enable me to do is get a bonded session with my target. So I would have those long term keys exchange with my target and be able to then exploit that further. So I could either, you know, use some sort of proof of concept or, you know, have that deeper interaction with that user's device. And so what we're going to do is we are going to be spoofing the the blue fruit le push some of this other stuff out of the way here for a second. We're going to be spoofing the blue fruit le. It's a it's real simple development tool out of fruit has all these kinds of kits that you can use. This is intended for development. It's intended to learn with and to explore how Bluetooth development works. But why we're using it is because it has its own application and one that does not have spoofing protections in it. So it's easy to basically prove this this this cloning this cloning concept. So let me plug things in. You can see we've got power now there. Okay, so you can see that we have power there. The blue fruit module is on. So what I'll be doing on my device is leveraging the scanner. So I'm going to scan for devices right now. Hopefully we see this blue fruit pop up somewhere. Oh, there we go. Freaky Zen sinister hunt sun hat was a project that I had for DEF CON last year. But yeah, it didn't quite make it all the way. So what we're going to do is we're going to clone here this clone button. So what I'm doing is I'm cloning the advertisement data now. So basically, I'll be able to impersonate the out of fruit unit on the advertisement channels. So now that we've cloned it, what we can do is we can actually connect to the device. And we connect to it to get a get a return on the GAT services that are available. So now that we've connected to we can go here up into the upper right hand corner, and we can go to clone device services. And you can see the little box popped up there and we've cloned the GAT services now. So we've cloned the advertisement profiles and we've cloned the GAT profiles. So now if we're able to turn these on, we're basically impersonating that device. So what we have to do is then go to the GAT server, and we have to turn on the GAT server to mimic the sun hat. So there we have the GAT services turned on. And what we also have to do is go to go to our advertiser, and we turn on the advertisement for the freaky zen sinister sun hat. So now we are impersonating this device. Hopefully we will get a connection to our target device. So now that we've cloned all of the GAT services, what we have to do is go into the advertiser, turn on the advertiser for the sinister sun hat. And then we also have to go in and change the name of the device. We're now advertising as a spoofed sun hat. So we will update our scan here on the out of fruit le app. And we can see the phoenix three. This is actually the name of the phone. So the name didn't update on the phone. So let's try and connect to it. And it allows us to connect to it as if it were the the sun hat. So the phoenix three is this phone. This is my attacker phone. So I've created a spoof from this from this phone. And I've now got a connection in the application in the blue fruit low energy application. And from there, like, it's not giving us the right information because we're not getting returns on that. However, if I go to the server information here on my attacker, I can change things like my manufacturer string. This is an attacker. We can set that. Now we should be able to see that pop up there. You see now we've provided information on the on our attacker on the got service for the manufacturer name. So now the end user is seeing that if we had a device that had more functionality, we could potentially send information from this device say we spoofed a thingy 52 and we spoofed or we sent temperature data out from there and this red temperature data. So think about that in a real world example where say a building is relying on Bluetooth low energy sensors to control HVAC. Say we are able to impersonate one of those sensors and then provide, you know, fake information to whatever is reading that that temperature and then making the judgments on what should be done about that temperature. If we can then create a scenario where it thinks maybe the temperature is rising uncontrollably, maybe there's cooling systems or maybe it kicks on the fire suppression systems or something. So there is the there is the risk of, you know, spoofing something and then providing information from that spoof. But I also have a connection now a bonded connection to my target device that I could potentially exploit even further. So we just went through the basic pieces. We clone the advertisement data. We change our device name. We clone the device services. We went through and turned on the advertiser and then we actually connected through and provided a spoof that our victim connected to. So I do want to introduce HACNAR's BLE CTF that it runs on ESP32. Like I said, if you've ever been to any of my in-person training sessions, I generally give these out to as many people as I can. So I have, you know, like maybe 10 or 20 of these that I give out. But obviously, since we are all safe mode and social distancing, then I can't really give a bunch of these out. But they're like $10 and you can upload all the information yourself. And you can actually go through a BLE CTF and it's more of just interacting on GAT services. So what we went through earlier where we were doing the abusing of right privileges. So there are a bunch of challenges on there. Some of them are, you know, decoding MD5 or, you know, following certain instructions that you get back from the services. So if you have, you know, interest in exploring more on the GAT side, then I would definitely recommend checking out HACNAR's BLE CTF. And of course, if you need help, feel free to reach out to me on Twitter or wherever. So a few recommendations for just kind of the individual Bluetooth low-energy user or your consumer. Keep your Bluetooth turned off unless you really need it. I know with the prevalence of Bluetooth low-energy devices, I find my Bluetooth is being turned on more and more and kept on for longer and longer. So this might not be valid information in a few years. We may just always have to just deal with Bluetooth being on. Choose low traffic areas to do pin pairing sessions with. While it is fairly unlikely that there will be, you know, significant kind of leakage of keys or pins, there is the chance that that could happen. So you're better off to choose sort of a controlled RF space where you know there aren't going to be a lot of people eavesdropping. Generally, your home is a good option or, you know, an uninhabited part of your office, maybe. Also, be aware that, like we saw with the Blue Fruit LE app, a lot of apps don't have spoofing protection. So you could very well be connecting to something that is not what you thought it was. And you've allowed an attacker to either provide you with false information or gain a bonded connection to your phone that they can then further abuse. And then I would also say that, you know, there are enough free tools out there that you could actually just start auditing all the Bluetooth devices around you and see, can I abuse GAT services? Can I create a spoof of this device? How does the application handle that? You might need two phones for that, but yeah. And then of course, if you want to get deeper into that, you know, maybe pick up a dedicated testing phone like an LG M150, make sure it's running Android 7. So yeah, those are a few of my recommendations for consumers. As far as developers, I like to push out of band pairing options just because it pushes some of that very privileged and important information away from the channel that is being used for data. Using something like NFC to actually pass long term keys will increase the security of the Bluetooth data or the integrity of it because you don't have the risk of using basically an unprotected channel to pass keys to them protect it. So you're using out of band practices. Don't focus solely on device security. You know, does your application have good spoofing protections? Is, you know, is your app just basically looking for devices on name alone or is it looking, you know, for something deeper? What I like to, you know, dream and recommend is that, you know, that there be a remote server where you can actually validate the keys of a device before you ever connect to it through the cloud. So say your cloud application would actually or your application on your phone would have a connection to a cloud server somewhere. So before you actually even start a connection with a device, that advertising data and that key or short term key would be passed to your your cloud and then validated and if it's not valid, then obviously you wouldn't connect or you could blacklisted or something like that. So that's what I tend to recommend. As far as further study, there are a number of blue tooth researchers. But probably the the one that I follow the most and the most enthusiastic is Jessica, I think I'm saying that right. But she is a she's a security researcher and yeah, RF kind of wizard out of out of Europe. So yeah, follow her on Twitter. She does a lot of talks all over the place. So if you're looking for books, Hacking Exposed Wireless is amazing. I just went through the coursework for the GAWN and it's very, very similar, obviously written by the same people. So of course, there's going to be knowledge kind of overlap there. And if you're looking to get more on the hands on side, then the out of fruit blue fruit LE, the thingy 52 ESP 32s and the UD 100 Bluetooth USB adapter, which we didn't cover in this talk, but is capable of doing more long range stuff. So that's definitely something you'll want to pick up if you have an interest in taking this further. Okay, so with the with the badge just on, if you just turn it on, you can see the nrf or the Bluetooth mesh pop up in an nrf connect. But I'm not able to connect to it. So I'm able to see the anodexor badge within nrf connect, the Bluetooth mesh, you see there it's listed as such, and I can try to connect to it. And I have a connection to it. And it's giving me certain options. I've done some poking around on this side, but I haven't found a lot. This SMP characteristic might be fun to poke around with. But what I have seen is within the SMP characteristic, you can actually do some interesting commands that have these right values here. But you know, OS echo commands, so you can echo commands through Bluetooth into the operating system, I haven't got much interaction from that, I've tried the bender commands, but it hasn't really worked. But the one that I have seen that works very well is the reset command. So I will switch over here. So as soon as I hit the reset command, you'll see the badge turns off. And then the badge turns off. Last year, if you were at Def Con, and they were talking about the the Bluetooth mesh, where you could attack other people's devices, you could connect to the badges, and then you could send these commands, you know, turn people's badges off or, you know, make it do different things, send different commands. So very cool, very cool kind of puzzle and interaction and tool for learning. So if you have one of these badges, one of these anonics or DC27 badges, or I believe the one before that also had a Bluetooth mesh on it. But if you have one of these badges, they would be awesome to hack on. Yeah, so they have that Bluetooth, Bluetooth component, that's going to wrap up my presentation. And I just want to thank you for spending the time with me today and learning about Bluetooth low energy hacking. Hopefully you learned something. Hopefully you found something that maybe caught your interest. And, you know, you're ready to explore the Bluetooth low energy devices around you. Don't forget the further study that I pushed out in one of the last slides. And if you have any questions, feel free to reach out on me on Twitter or LinkedIn or anywhere really. And I will try my best to get in touch with you. I know sometimes I don't do a great job, but yeah, so thank you so much for joining me. And I hope you have a wonderful, wonderful DEF CON safe mode.