WEBVTT 00:20.400 --> 00:21.600 Hey, everyone. 00:21.600 --> 00:24.100 Welcome to the basics of breaking BLE. 00:24.100 --> 00:25.520 I'm Preeti Sen. 00:25.940 --> 00:32.100 I want to thank you for joining me and I want to thank the Wireless Village for featuring me today. 00:32.280 --> 00:42.380 Also, I want to thank DEF CON for going into safe mode and allowing us the space to interact and learn with each other. 00:42.860 --> 00:47.260 So, I've got a few things planned for us today. 00:47.380 --> 01:11.140 We've got some just going over the basics of what BLE 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. 01:11.840 --> 01:18.680 So, as you can see here on the desk, I have a few devices. 01:18.680 --> 01:25.200 We have the Bombadge from DC27, Team IDES. 01:25.200 --> 01:30.260 We have Hacknar's BLE CTF. 01:30.260 --> 01:52.920 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 a sort of entry point for people to learn how to interact with GAT services on Bluetooth devices. 01:54.120 --> 01:58.700 So, going on, we also have a Thingy 52. 01:58.760 --> 02:03.320 This is a development tool and learning tool from Nordic. 02:03.680 --> 02:09.880 This has its own application that you can interact with sound and 02:12.940 --> 02:17.280 different gyroscopes and LEDs and all sorts of fun things. 02:17.720 --> 02:25.640 And then, of course, we have Anode XOR's DC27 badge that has a Bluetooth mesh network on it. 02:25.640 --> 02:34.140 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. 02:34.140 --> 02:40.580 We actually also have the LG Phoenix LG150. 02:40.580 --> 02:56.900 This phone is important because it's the only one that I have found so far that allows for live capture of the BT Snoop file from an Android device into Wireshark. 02:56.900 --> 03:08.900 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. 03:08.900 --> 03:18.180 If I hit this button and this command comes across the wire, then it's probably pretty obvious that that is the command that's controlling that. 03:18.180 --> 03:30.560 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. 03:31.260 --> 03:38.500 So going on, the last item that we have is the Adafruit Bluefruit LE. 03:38.920 --> 03:46.560 This has some services that I built on it for DC27, actually. 03:46.740 --> 03:55.740 So we will look at actually cloning this device and spoofing it against a target. 03:57.020 --> 04:00.460 So just a short introduction to who I am. 04:00.460 --> 04:02.020 My name is Maxine Filcher. 04:02.020 --> 04:04.440 I also go by Freaky Zen online. 04:04.440 --> 04:07.180 Security consultant with IOActive. 04:07.180 --> 04:08.680 Sarmie veteran. 04:08.700 --> 04:15.060 Graduated class of 2020 with a BS in Info Assurance and Cybersecurity. 04:15.060 --> 04:17.620 I also have a minor in Law and Policy. 04:17.680 --> 04:26.620 I'm also a member of the SANS Women's Academy 2018 cohort, where I earned the GSEC, the GCIH, and the GPEN. 04:26.620 --> 04:32.300 I am also in the process of studying for the GAWN. 04:33.060 --> 04:38.420 So just a small disclaimer, I'm not a Bluetooth developer by any means. 04:38.420 --> 04:49.520 But I have been teaching about Bluetooth hacking and just general Bluetooth concepts for a couple of years now. 04:49.520 --> 04:55.600 So I feel like I am fairly well versed in this topic. 04:56.540 --> 05:08.640 So in any of my demonstrations, I always like to frame wireless security as greater than just Wi-Fi or just Bluetooth. 05:09.940 --> 05:26.700 In pen testing, when we see companies talk about wireless, you know, pen tests, generally they're talking about their Wi-Fi and they are, you know, completely ignoring a lot of other vectors that could occur with wireless. 05:26.700 --> 05:41.180 So I always like to bring up this kind of definition, I guess, this contrast in definition, you know, this weak definition from Wikipedia where it's wireless networks. 05:41.240 --> 05:43.740 Which I mean, I guess, could be broadly interpreted. 05:43.740 --> 05:47.760 But I much prefer the NIST, which I believe is still current. 05:47.760 --> 05:49.340 It may have been updated. 05:49.620 --> 05:58.740 But the NIST definition of wireless enabled technologies, I feel it's more encompassing of everything that you could encounter. 06:02.440 --> 06:07.490 So we talk about wireless, you know, just kind of continuing that discussion. 06:07.880 --> 06:09.700 You know, many different technologies. 06:09.700 --> 06:20.460 We have Bluetooth, Wi-Fi, ZigBee, RFID, NFC, Cell, and these come into a number of different industries. 06:20.460 --> 06:25.960 So medical is one that is growing pretty rapidly as far as Bluetooth low energy. 06:26.060 --> 06:36.080 And then, of course, IoT, the things around us, all these smart devices that really rely heavily on Bluetooth low energy to communicate. 06:36.440 --> 06:46.820 Then, you know, industry 4.0, Bluetooth is starting to get more into, you know, automated systems within factories and smart buildings. 06:46.980 --> 06:53.860 And also, you know, smart automated, you know, HVAC systems, or just building control systems. 06:53.860 --> 07:04.120 So Bluetooth is really starting to make its way into these important and sometimes, you know, high risk sort of systems. 07:04.120 --> 07:19.080 So Bluetooth is becoming more of an important research topic and, you know, target for actually pen testing as we go and as the technology develops. 07:19.140 --> 07:22.140 So just a few basics about Bluetooth. 07:22.640 --> 07:26.600 You'll find it in, you know, within the ISN band. 07:26.600 --> 07:33.420 So 2.4 to 2.485 gigahertz in this case for Bluetooth low energy. 07:33.440 --> 07:38.720 It comes in a few different flavors, you could kind of call them. 07:38.720 --> 07:46.820 Although the protocol stacks are different in some ways and similar in some ways. 07:47.860 --> 07:55.620 The original Bluetooth that came out, we refer to as Bluetooth classic or enhanced data rate. 07:55.620 --> 08:02.160 Any more you will find that in things like wireless headsets. 08:02.600 --> 08:18.600 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. 08:19.160 --> 08:23.520 Bluetooth low energy is what it is described as. 08:23.520 --> 08:25.400 It's a low energy protocol. 08:25.400 --> 08:31.540 It's intended to be used in devices that could run on a coin cell battery for up to a year. 08:31.980 --> 08:39.580 So that's a pretty heavy design specification for something, you know, that is low touch. 08:39.580 --> 08:47.980 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. 08:49.120 --> 08:55.840 Something new that's emerging, and I mentioned it with the N on XOR badge, is Bluetooth mesh. 08:55.840 --> 09:01.600 Bluetooth mesh is actually, you can kind of think of it as a hat that goes on top of Bluetooth low energy. 09:01.600 --> 09:07.620 It uses some of the underlying components, but it adds things like provisional keys and application keys. 09:07.620 --> 09:12.720 And it's a mini to mini connection and it's very interesting. 09:12.720 --> 09:19.600 It can use, you know, pathways across other devices and set up nodes. 09:19.600 --> 09:22.480 It's a very interesting portion of the protocol. 09:22.860 --> 09:27.560 But we aren't really going to get into Bluetooth mesh too much. 09:27.580 --> 09:39.020 So just some other numbers, of course, you know, Bluetooth low energy is blowing up still all across the world, all these different technologies. 09:39.020 --> 09:46.300 I'm sure you have more than a few Bluetooth low energy devices around you right now. 09:48.580 --> 09:56.460 I also love to throw in, you know, little tidbits of history about Bluetooth. 09:56.460 --> 10:03.540 I think it's got kind of a fun origin with the name and kind of the intentions behind it. 10:03.560 --> 10:14.100 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. 10:14.100 --> 10:19.220 And this is actually for Harald Bluetooth, who was the king of Norway and Denmark. 10:19.220 --> 10:26.580 He was seen as a great unifier of these countries and brought together these nations. 10:26.680 --> 10:35.160 If you've watched Vikings, the History Channel series, you might recognize the guy whose picture I've pasted up there. 10:35.160 --> 10:44.560 But yes, it's loosely based on the same person, on the same historical character or figure. 10:44.720 --> 10:57.480 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, Hedy Lamarr. 10:58.520 --> 11:01.500 I love the story of Hedy Lamarr. 11:01.500 --> 11:07.980 I love the story of her, you know, totally being just underestimated, but being so brilliant. 11:07.980 --> 11:15.860 And for those who aren't familiar, she was an actress in the early part of the 20th century. 11:17.100 --> 11:28.600 And she came from Austria, fairly scandalous kind of background, had left her husband, who had decided to supply arms to the Nazi party. 11:28.600 --> 11:35.520 She came to the United States and she befriended a man named George Anthel. 11:35.520 --> 12:01.100 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 allied submarines or allied ships. 12:01.100 --> 12:07.400 A lot of times these torpedoes, when they were fired, they would either get jammed or they would lose connection. 12:07.400 --> 12:13.280 And sometimes they could actually backtrack around and hit the ship that fired the torpedo originally. 12:13.280 --> 12:16.760 So this was, at the time, was actually a fairly large concern. 12:16.760 --> 12:24.020 And it was something that was kind of an operational hazard that you had to put up with. 12:24.020 --> 12:31.880 And together they came up with this concept of frequency hopping spread spectrum. 12:31.900 --> 12:49.680 And this is where two devices, two transceivers, would have the set channel hopping, or it would have channels set within them that they would hop across at a set interval and at a set rate. 12:49.680 --> 13:05.060 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. 13:05.060 --> 13:12.160 So this was actually a fairly unique idea at the time. 13:12.160 --> 13:17.380 It was based on player pianos, synced player pianos, which is kind of cool. 13:17.380 --> 13:26.780 If you have more interest about this story, there is an amazing documentary on Netflix called Hedy Lamarr, or Bombshell the Hedy Lamarr Story. 13:26.780 --> 13:28.820 Highly recommend that you check it out. 13:28.820 --> 13:34.580 It's a little bit sad, but if you're curious about the background, it's a really amazing story. 13:36.760 --> 13:40.180 So let's get into a little bit of terminology. 13:40.600 --> 13:48.000 So as far as devices within Bluetooth connections, we can think about devices in two ways. 13:48.000 --> 13:49.880 Central and peripheral. 13:49.940 --> 13:59.920 So your central devices are generally going to be your phone, or the device that the user is actually interacting with. 14:00.420 --> 14:12.640 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. 14:12.640 --> 14:18.440 Say that's any kind of device that you're going to connect to, that's a peripheral device. 14:18.440 --> 14:25.040 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. 14:27.900 --> 14:34.920 So connections are also something that's important in Bluetooth, obviously, it's a wireless protocol. 14:34.920 --> 14:39.120 So there has to be some sort of way the connections are handled. 14:39.120 --> 14:52.660 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. 14:53.120 --> 15:01.160 So it has three set channels, Bluetooth Low Energy has three set channels that will broadcast across 37, 38, and 39. 15:02.180 --> 15:05.800 And there are also four advertising PDU types. 15:06.220 --> 15:09.100 I won't go over those, you can look them up. 15:09.140 --> 15:13.200 They don't really have too much impact on what we're going to talk about today. 15:15.880 --> 15:25.540 So we also have 36 channels for Bluetooth Low Energy separated by two megahertz across the spectrum. 15:26.280 --> 15:32.780 And when we're also speaking about connections, we think about them in two phases, sort of. 15:32.920 --> 15:42.730 Once you see the advertising of a device that you want to connect to, from your phone, you will initiate the pairing process. 15:42.730 --> 15:49.110 I'm fairly confident that most people are familiar with the pairing process. 15:49.630 --> 15:53.550 But it's where you initiate a wireless connection. 15:53.950 --> 15:56.250 And these come in kind of two phases. 15:56.250 --> 16:05.050 So you have your basic pairing session where you're unbonded, or you've passed your short term keys between the devices. 16:05.050 --> 16:18.310 So they have established a connection, but it's not trusted on certain levels, and it's not been placed into... the devices haven't been placed into each other's sort of trusted devices list. 16:18.510 --> 16:28.750 So once you create a bonded connection, that will actually... those devices are actually transferring long term key information between each other. 16:28.870 --> 16:45.270 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. 16:45.270 --> 16:50.810 You can just, you know, whenever you're in proximity of the device, it will just automatically connect to you. 16:50.810 --> 16:53.250 So that's one of the benefits of bonding. 16:53.250 --> 17:07.090 Another benefit of bonding is you will oftentimes have greater leeway in the amount of kind of tolerance for fuzzing on a device. 17:07.090 --> 17:19.930 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 end that pair. 17:20.230 --> 17:29.930 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. 17:34.610 --> 17:42.090 So we can talk a little bit about sort of the evolution of the Bluetooth protocol stack. 17:42.190 --> 17:49.410 We talked about how it kind of comes in multiple flavors, and you can see that we have classic B-R-E-D-R there. 17:49.470 --> 18:00.700 And then you can see the hybrid version of Smart Ready, and now Bluetooth Smart, which most new Bluetooth low energy devices coming out should be Bluetooth Smart. 18:02.200 --> 18:12.420 Although most phones will have the ability to use B-R-E-D-R in the case of, say, Bluetooth headphones or that sort of thing. 18:13.400 --> 18:22.880 There is also a new audio protocol that is coming out, a new Bluetooth low energy audio protocol. 18:23.280 --> 18:25.960 It was announced earlier this year. 18:25.960 --> 18:34.320 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. 18:35.240 --> 18:37.420 But it's interesting. 18:38.280 --> 18:49.860 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. 18:50.280 --> 18:59.060 So, yeah, just some of the basic components of the protocol stack that we're going to really pay attention on today is GATT. 18:59.060 --> 19:03.960 I've already mentioned it a couple of times, but it's the generic attribute profile. 19:04.420 --> 19:13.460 These are where the profiles of the services that a device can offer are stored. 19:13.460 --> 19:28.320 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 measuring humidity levels. 19:28.320 --> 19:34.960 There's a GATT service, and there's a way for that information or that service to be interacted with. 19:34.960 --> 19:43.120 So there is a way to retrieve that temperature or that humidity measurement through the GATT services. 19:43.120 --> 19:46.320 Primarily, we're going to be interested in GATT services today. 19:48.080 --> 19:49.200 Okay. 19:49.200 --> 19:51.300 So we've already talked about that. 19:52.820 --> 20:07.800 So when I talk about GATT hacking, what I'm really talking about is the abuse of read or write privileges on a device over their GATT services. 20:08.120 --> 20:16.640 So in the case of iOS, read privileges can be abused fairly easily. 20:16.640 --> 20:29.220 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. 20:29.220 --> 20:51.160 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 GATT, and there are some very significant information disclosures from iOS. 20:52.400 --> 21:02.120 So a few simple write privilege abuses that I have seen in devices that I have pin tested are just sending simple code. 21:02.120 --> 21:06.480 So picking out a GATT service, and I just start fuzzing codes. 21:07.320 --> 21:19.740 In some of the real world cases that I've seen, writing the hex value 0x08, and that enables me to set up a new pin between the devices. 21:19.740 --> 21:27.860 So now I'm defeating one of the very few security measures that you have for controlling Bluetooth connections. 21:28.040 --> 21:33.900 Further still, I've been able to achieve over the air firmware update mode. 21:33.900 --> 21:41.900 So writing 01 to a GATT service will actually allow you to push firmware to a device. 21:41.900 --> 21:49.760 I mean, you obviously could get, you know, lower interactions than potentially placement malicious firmware onto a device. 21:49.760 --> 21:53.460 And then, you know, who knows, you'd own that device then. 21:53.520 --> 22:01.220 Other devices I've seen like write 02 to a GATT service, a specific GATT service, and it would start a heating cycle on a device. 22:01.220 --> 22:05.580 So, you know, potentially there is danger there. 22:05.620 --> 22:08.800 So Bluetooth Low Energy does have security. 22:08.980 --> 22:26.520 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. 22:26.520 --> 22:39.400 So Bluetooth SIG has done a fairly decent job of responding to security researchers and trying to get chip manufacturers and developers on board with everything. 22:39.780 --> 22:46.740 But yeah, so there's a lot of space for growing, and there's also a lot of space for research. 22:47.480 --> 22:55.120 So Bluetooth Low Energy has currently, I would say the standard would be 4.2. 22:55.540 --> 23:09.800 Although BLE 5.0, the new standard that came out, has some pieces that strengthen the just works pairing by introducing some nonce values. 23:09.800 --> 23:11.520 The more entropy, the better. 23:11.600 --> 23:14.300 We have protections against man in the middle. 23:14.300 --> 23:26.820 We have protections against eavesdropping, and theoretically there's authentication via pairing and bonding, but we can see that oftentimes that's not the case and that can be abused pretty easily. 23:28.500 --> 23:33.460 So some of the Bluetooth vulnerabilities that have come out in the past. 23:33.660 --> 23:40.140 Once I started getting into Bluetooth pretty heavily, Blueboard was pretty fresh. 23:40.140 --> 23:46.260 It was fairly new, and it seemed to scare a lot of people. 23:46.260 --> 23:51.680 That's when I noticed Bluetooth security research really kind of starting to kick up again. 23:52.100 --> 23:55.440 It seemed like it had died off before that. 23:56.200 --> 24:01.360 And since then, there have been major vulnerabilities that's released every year. 24:01.520 --> 24:13.540 I think there were two, well Sphintooth was released earlier this year, and then there was a new set that they released, a new vulnerability set that they released just a couple of weeks ago for Sphintooth. 24:14.940 --> 24:20.740 So interesting piece about, or interesting trivia piece about Sphintooth. 24:20.740 --> 24:26.100 It's actually named after the son of Harold Bluetooth. 24:26.100 --> 24:29.580 So got a cool marketing piece that they did in there. 24:29.580 --> 24:42.800 So Sphintooth, since it's brand new, we'll talk about that, really starts to attack the protocol in ways that I personally haven't been testing it. 24:42.800 --> 24:49.640 And just fuzzing the header values and fuzzing the protocol in a way that just makes things stop working. 24:49.640 --> 24:53.000 There are a lot of denial of service vulnerabilities within this. 24:53.080 --> 24:57.580 A lot of deadlocks, security bypasses that are included within this. 24:57.740 --> 24:59.740 And it's fairly expansive. 24:59.740 --> 25:02.680 There are a lot of vendors that are impacted by Sphintooth. 25:02.700 --> 25:04.880 So a pretty cool piece of research. 25:04.880 --> 25:10.140 I personally haven't had a lot of time to jump into it, but I have read through it quite a bit. 25:10.140 --> 25:12.360 And it's pretty interesting. 25:12.900 --> 25:18.520 These are just a few of the Bluetooth tools out there that you can use. 25:18.900 --> 25:26.180 Some of these are proof of concepts, but they have neat scripts that you could either alter or actually just use as they are. 25:27.720 --> 25:32.980 So the first tool that we're going to look at is the Ubertooth One. 25:33.260 --> 25:35.060 Let me switch over here. 25:35.060 --> 25:38.200 So I have one right here. 25:38.200 --> 25:40.860 It's an older device. 25:40.860 --> 25:42.220 It's a few years old. 25:42.440 --> 25:54.760 But it's still probably the best way to ingest externally viewed Bluetooth packets into Wireshark. 25:54.760 --> 26:05.660 And I say externally because this is what I consider to be looking from the outside in to a Bluetooth connection between devices. 26:06.000 --> 26:12.240 So generally, you won't see a lot because things should be encrypted. 26:12.400 --> 26:18.560 Although I have seen some devices that say they are doing things, but they aren't actually encrypting things. 26:18.560 --> 26:21.000 So you're able to pull commands out of the air. 26:21.380 --> 26:43.680 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. 26:43.680 --> 26:52.720 So the GreatFET One is a tool that's still currently in development, I would consider. 26:53.300 --> 27:01.800 The Quincy was announced as the first sort of hat that was going to be added to this, the add-on hat. 27:01.800 --> 27:05.920 And it would allow for full spectrum sniffing of Bluetooth Low Energy. 27:05.920 --> 27:26.040 So instead of having to use an Ubertooth, 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. 27:26.040 --> 27:33.120 So much easier to kind of manage as far as mass sniffing operations. 27:33.700 --> 27:43.840 But as of yet, um, and I haven't heard anything about a price. 27:43.840 --> 27:46.120 Maybe that'll change with Defcon coming up. 27:46.120 --> 27:48.460 So this is being recorded beforehand. 27:48.460 --> 27:50.080 So maybe there's already been an announcement. 27:50.080 --> 27:53.420 And if that's the case, then disregard this portion. 27:54.920 --> 28:14.320 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 Eliasys system, which relies on SDR. 28:14.460 --> 28:24.380 And it's the same kind of concept as the Quincy in that it's looking to do a mass spectrum capture. 28:24.380 --> 28:29.080 So it's trying to capture all of the Bluetooth packets that it possibly can. 28:29.080 --> 28:33.440 And then you can go through there and sort it by connection and see everything. 28:33.900 --> 28:40.600 This actually, this system will go even further and in some cases will strip the encryption off of the packet. 28:40.600 --> 28:44.980 So the software is actually pretty cool. 28:44.980 --> 28:48.360 I've had the chance to use one of these systems. 28:48.640 --> 28:55.640 And yeah, it's it's a very powerful tool that you can do a lot of really meaningful research with. 28:55.640 --> 28:59.360 But there is a huge price tag that's associated with it. 28:59.940 --> 29:04.560 And so that brings us to nRF Connect. 29:04.600 --> 29:11.240 And nRF Connect is what I generally use on engagements first. 29:11.240 --> 29:21.640 So I will exhaust every avenue possible with nRF Connect because it's free and it installs on any smart device. 29:21.640 --> 29:24.080 So well, you know, Android or iOS. 29:24.080 --> 29:27.560 And so it's highly available. 29:27.560 --> 29:30.340 It's extremely simple to use. 29:30.340 --> 29:33.960 It allows for abuse of GATT services. 29:33.960 --> 29:37.020 It also allows for cloning and spoofing. 29:37.020 --> 29:41.500 So it's a fairly useful tool. 29:41.660 --> 30:08.200 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 that 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. 30:08.200 --> 30:13.860 So, you know, let's take a sort of low hanging fruit first approach. 30:14.440 --> 30:16.980 So I always start with nRF Connect. 30:18.020 --> 30:23.520 You know, it was intended for debugging but it works wonderful for the purposes that I need. 30:23.660 --> 30:28.320 One of the great things that you can do with this is record macros. 30:28.320 --> 30:32.850 So sometimes devices will only allow for momentary connections. 30:33.780 --> 30:43.060 Just long enough for two devices to basically pass short-term keys and decide that one device says that I don't want to talk to you because I don't know who you are. 30:43.180 --> 30:51.920 Well, still in that period of time there may be two seconds, three seconds where you have the window to actually send GATT commands in. 30:51.920 --> 31:06.080 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. 31:06.320 --> 31:08.900 You're just that momentary connection. 31:08.900 --> 31:12.600 So I really enjoy the macro feature. 31:12.600 --> 31:17.560 And of course you can also export the logs which you know help for reporting. 31:17.560 --> 31:19.720 nRF sniffer we won't actually talk about. 31:19.720 --> 31:35.420 So BetterCap is a tool capable of interacting or allowing you to interact with GATT services of a device but from a Linux machine using a BLE dongle. 31:35.760 --> 31:43.840 So Kismet has the ability to do this but I feel like BetterCap has a slightly better UI for this. 31:43.840 --> 31:47.560 But it can be a little bit difficult to install. 31:48.000 --> 31:54.400 But yeah, you have the ability to send requests and commands over GATT. 31:54.400 --> 32:04.420 So it's still a very powerful tool if you're interested in doing this from a laptop or a desktop rather than a mobile device. 32:04.420 --> 32:10.100 Another powerful tool from a desktop machine is Scapi. 32:10.100 --> 32:15.760 So Scapi actually will allow you the ability to script. 32:15.800 --> 32:20.920 And this is very powerful once you start looking at these deeper interactions. 32:20.920 --> 32:39.400 So if you wanted to follow along with the Sphintooth vulnerabilities, you could actually craft packets using the Scapi library to attack those specific pieces of the protocol and push different kinds of data to them and potentially push them over. 32:39.400 --> 32:51.680 So if you're looking to do that deeper kind of penetration testing or research on Bluetooth energy, low energy, the Scapi library is definitely something you'll want to check out. 32:52.720 --> 33:03.600 And another essential tool that I use on just about every one of my pen tests for Bluetooth low energy devices is Android Debug Bridge. 33:03.680 --> 33:13.900 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. 33:13.900 --> 33:30.180 And 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. 33:30.380 --> 33:39.060 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. 33:39.060 --> 33:41.620 And we'll look at this here shortly. 33:42.080 --> 33:47.200 So just some basic installation instructions if you're not familiar with ADB. 33:47.200 --> 33:49.180 Very simple to set up. 33:49.420 --> 33:52.540 Very easy to get going and to use. 33:53.100 --> 33:55.280 So I mentioned Kismet earlier. 33:55.280 --> 34:06.760 If you're not familiar with Kismet, it also supports Bluetooth low energy, but it has some functionality, but they may be, you know, increasing that as we speak. 34:06.760 --> 34:15.500 So, you know, that tool is definitely growing in its functionality and its capabilities every day. 34:16.300 --> 34:29.880 And we've mentioned Apple BLEEE, a wonderful proof of concept for the security issues that are really inherent within the iOS Bluetooth low energy stack. 34:30.540 --> 34:32.240 This is a lot of fun. 34:32.240 --> 34:40.640 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. 34:40.900 --> 34:42.900 So it's a lot of fun. 34:42.900 --> 34:51.340 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. 34:53.260 --> 35:01.700 The Blueborn scanner, it was deprecated, but I've actually seen it back on the store or on the Play Store. 35:01.700 --> 35:04.560 And I still download it and still use it. 35:04.560 --> 35:14.340 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. 35:14.340 --> 35:19.440 Most manufacturers have patched or updated things against this. 35:19.440 --> 35:38.260 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 the on your Blueborn scanner and would give you all kinds of information. 35:38.260 --> 35:43.100 And then from there, you could actually use proof of concept scripts to actually attack these TVs. 35:43.520 --> 35:46.900 You know, those are different stories. 35:47.520 --> 35:54.220 But as far as I know, Blueborn is pretty much patched up and is no longer a risk. 35:56.340 --> 36:04.920 So a few challenges that we run into in Bluetooth low energy, as far as security researcher challenges. 36:06.720 --> 36:10.540 Most of the modern connections are encrypted. 36:10.540 --> 36:13.600 So they're hard to see from the outside. 36:13.600 --> 36:23.200 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. 36:23.200 --> 36:28.660 You know, the Ubertooth can follow connections, but it can't see inside of those connections that are encrypted. 36:28.680 --> 36:32.440 Crackle is largely ineffective anymore for breaking pins. 36:32.440 --> 36:36.140 So you know, good luck breaking pins. 36:36.140 --> 36:45.460 I know that there has been some research done in attacking the entropy levels of the pins that are generated. 36:45.460 --> 36:47.580 So that's kind of been a potential. 36:47.580 --> 36:56.040 But as far as I know, there isn't a reliable way of breaking pairing pins at this point. 36:56.960 --> 36:59.690 Commercial sniffers are also really expensive. 36:59.690 --> 37:06.510 And the cheaper alternatives really don't outperform the Ubertooth. 37:07.510 --> 37:10.890 So a few approaches to BLE. 37:10.890 --> 37:12.590 Sniff the broadcast traffic. 37:12.590 --> 37:14.890 So look from the outside in first. 37:14.890 --> 37:16.190 Is it encrypted? 37:16.190 --> 37:17.970 What can you see, basically? 37:17.970 --> 37:19.370 What are they leaking? 37:19.370 --> 37:25.890 What could you potentially do without any kind of interaction with the device? 37:25.890 --> 37:28.430 Is there any kind of information leak? 37:28.430 --> 37:31.490 Are there any issues with configuration? 37:32.250 --> 37:34.210 Yeah, that sort of thing. 37:35.930 --> 37:48.230 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. 37:48.230 --> 37:55.630 So Android Debug Bridge allows you to look at the Bluetooth Low Energy packets once they've crossed over the HCI threshold. 37:55.630 --> 38:04.510 So they've been stripped of the encryption layer and you can actually see the commands that are getting sent over the wire. 38:04.550 --> 38:06.290 Attempt out of app connection. 38:06.290 --> 38:10.430 So just try to, you know, use nrf connect. 38:10.630 --> 38:12.630 Connect to a device. 38:12.630 --> 38:16.470 See if you can create a paired or a bonded session. 38:16.590 --> 38:20.530 And then just start fuzzing values and see what interaction you get. 38:20.530 --> 38:23.850 Sometimes, you know, you'll get devices to lock out. 38:23.850 --> 38:28.210 Sometimes you'll get devices to actually do what they're supposed to. 38:28.210 --> 38:29.970 Sometimes you hit the trigger. 38:30.770 --> 38:38.090 And then the next thing is to spoof a device or check for cloning protections within the application itself. 38:38.410 --> 38:43.490 So these are kind of the four things that I really look for in a pen test. 38:43.990 --> 38:50.550 So hopefully that helps you kind of frame and contextualize what we're going to look at here in a second. 38:51.190 --> 38:54.510 So let's get into some hands-on stuff. 38:56.170 --> 38:58.530 So short list of equipment. 38:58.610 --> 39:01.690 The Nordic Thingy 52. 39:02.030 --> 39:03.730 Bluefruit LE. 39:03.770 --> 39:05.530 The LG M150. 39:05.590 --> 39:09.250 The Samsung S20 I'll be using as the victim. 39:09.390 --> 39:15.410 But I will also be showing you the screens that the attacker would see on that phone. 39:15.450 --> 39:20.030 It's just kind of a technology and display matter at this point. 39:20.030 --> 39:24.450 So and then we'll of course be using NRF Connect. 39:24.450 --> 39:28.930 We'll be using the Thingy app, then the Bluefruit Connect application. 39:28.930 --> 39:31.650 We'll also be using ADB and Wireshark. 39:31.650 --> 39:35.750 For an external scan, we're going to start with Ubertooth. 39:35.750 --> 39:37.950 And we're going to go through the setup. 39:37.950 --> 39:40.670 I just set this up on my computer. 39:40.670 --> 39:50.930 If you go to the GitHub page and go to their wiki for the Ubertooth, there are really good setup instructions. 39:50.930 --> 39:52.450 You just go line by line. 39:52.450 --> 39:56.610 I didn't have any issues on the newest version of Kali, so hopefully you don't. 39:56.610 --> 39:58.930 But yeah, you never know. 40:04.290 --> 40:15.070 So this is where we will be using ADB to do a live capture of the BT Snoop file on our LG M150. 40:15.490 --> 40:19.330 So let me get the phone hooked up here. 40:19.330 --> 40:21.430 We are going to launch ADB. 40:21.430 --> 40:26.230 So we would launch by using ADB start server. 40:26.350 --> 40:29.570 Mine's already started, but we'll just hit it again. 40:29.570 --> 40:32.870 And then we use ADB devices. 40:33.610 --> 40:36.870 And you can see our LG M150 is right there. 40:36.870 --> 40:38.750 So I plugged a different phone in. 40:39.310 --> 40:44.970 And we can see the device that I'm using here to capture the BT Snoop file on. 40:44.970 --> 40:48.490 We go over to Wireshark, which I already have started. 40:48.670 --> 40:56.590 And we can see that we have this BT Snoop interface that's opened up here. 40:56.590 --> 41:04.810 Now, it's important to note that the LG M150 has to be running Android version 7. 41:04.810 --> 41:15.010 So I just tried this a second ago with a different LG that I have, it's running version 6, and it does not open up the BT Snoop. 41:15.010 --> 41:19.470 So you'll have to actually update the version of Android. 41:19.470 --> 41:25.550 Luckily, we have pre-recorded videos this time, so I can go in and actually edit out some of that stuff. 41:26.630 --> 41:29.310 So we have our BT Snoop file here. 41:29.470 --> 41:31.870 Let's go ahead and start the sniffer. 41:31.870 --> 41:35.970 So our sniffer is now running from our phone. 41:36.650 --> 41:39.690 And so I have the phone connected here. 41:41.070 --> 41:46.450 And what we can do is start trying to connect to devices. 41:46.450 --> 41:52.890 So for instance, I have this thingy 52 on the desk here. 41:52.890 --> 41:58.350 I can turn this on and I can open up nrf connect. 42:00.710 --> 42:04.090 And you'll see the packets are starting to come in here. 42:07.950 --> 42:16.030 So we can see I'm going to connect to the thingy device here, and you'll see the packets start to change. 42:18.470 --> 42:26.290 We can create a connection to our thingy 52 using the thingy connect app. 42:27.170 --> 42:36.790 And now that I'm connected, I'm actually reading data from this device, from the thingy 52, onto my phone. 42:37.570 --> 42:43.550 So I can do things like play sounds. 42:48.780 --> 42:55.320 Now that's as I'm pressing here, you hear the sound on the thingy 52. 42:55.320 --> 43:00.380 So those commands are coming through the GAT services. 43:00.380 --> 43:06.760 Commands are being written from our phone to the GAT services that are being offered on the thingy 52. 43:06.900 --> 43:15.260 So since we have this hooked up in an internal fashion and we can see these packets, we can actually see what commands are controlling what. 43:15.260 --> 43:22.820 So if I hit this tone, we can see that there are packets coming across. 43:24.460 --> 43:26.500 Send write here. 43:30.390 --> 43:35.090 And this is the value that's being written to that GAT service. 43:35.290 --> 43:38.330 So let's try a different key. 43:40.610 --> 43:44.130 Okay, let's see if that value has changed. 43:44.830 --> 43:48.770 You can see it's changed to an 8, from a 5 to an 8. 43:56.110 --> 44:00.310 I would also suspect that 1 is the on and off, right? 44:00.310 --> 44:04.550 So the first write is the on, the second write is the off. 44:04.550 --> 44:12.110 You can see all Fs in the middle there, and then we see all 0s in the middle. 44:12.610 --> 44:15.670 All Fs, all 0s. 44:15.990 --> 44:26.570 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. 44:26.570 --> 44:47.290 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. 44:48.290 --> 44:54.070 So let me bring up the screen here. 44:54.210 --> 45:11.470 And I'm going to use my victim device here, or in this case my attacking device, to actually seek out the Thingy52 here over nrfconnect. 45:11.770 --> 45:15.230 So this would constitute an out-of-application connection. 45:15.230 --> 45:31.970 Since the Thingy52 has an application that controls all of the interactions, using an application like nrfconnect to directly interact with the GAT services would be considered an out-of-app interaction. 45:31.970 --> 45:34.610 So let me scan. 45:41.550 --> 45:44.510 So we have this thing here. 45:44.510 --> 45:47.650 That's my Thingy52. 45:47.890 --> 45:50.750 We'll go ahead and connect to that. 45:52.530 --> 45:58.850 And so you can see right off the bat we have a connection, but it's not bonded. 45:59.030 --> 46:03.430 You'll also notice up here in the right-hand corner is the DFU button. 46:03.430 --> 46:09.650 That will actually allow us to push firmware updates over the air. 46:09.650 --> 46:19.030 So not all devices, and most consumer devices will be locked down from this, but not all devices will have this. 46:19.270 --> 46:33.270 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. 46:34.290 --> 46:37.450 Let's go ahead and open up our sound services. 46:37.810 --> 46:47.390 So when we were looking at the other screen here, let me go to Kali and phone. 46:47.490 --> 46:59.110 So when we were looking at the other commands that we captured from the internal, from the ADB capture, we saw our read and write commands. 46:59.170 --> 47:06.850 So those were being written to the handle 005B, and that was in the sound service. 47:06.850 --> 47:08.810 So let's look in the sound here. 47:11.970 --> 47:17.170 So if we open up the handle, we can see the full UUID there. 47:17.170 --> 47:24.750 Okay, so the thingy, speaker data characteristic, is what we saw being written to. 47:26.150 --> 47:36.110 So we can actually use this upload command, so we have write permissions to it, and we can use this value that we have here. 47:36.110 --> 47:48.310 So we have 8701FFF5A. 47:48.450 --> 47:51.850 So let's try and push this. 47:51.850 --> 47:56.530 This was a write command, so let's make sure that it's placed in command. 47:56.530 --> 48:02.930 You have the option between request or command, and this was sent as a command, X52. 48:02.930 --> 48:11.930 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. 48:21.680 --> 48:23.160 There it is. 48:23.300 --> 48:24.560 There it is. 48:25.860 --> 48:32.800 So we're now attacking from there, and just like I thought, so the all F command is the on command. 48:32.800 --> 48:37.120 So when we saw the write, that was the F. 48:37.120 --> 48:39.760 So we've sent it the option to be on. 48:39.760 --> 48:44.760 So it's on right now, and you can hear it in that tone. 48:45.440 --> 48:48.880 So now let's write the off command. 48:48.880 --> 49:03.220 So that was 870100005A, and we send that as the command, and now it's off. 49:03.220 --> 49:10.120 So that is a very robust look at your basic GAT hacking. 49:10.120 --> 49:30.620 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. 49:30.620 --> 49:33.540 So say this was something else. 49:33.540 --> 49:44.000 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. 49:44.320 --> 49:54.980 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. 49:55.600 --> 50:12.540 So if you could walk around, identify 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. 50:12.540 --> 50:23.480 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. 50:24.240 --> 50:28.980 So successful GAT hacking there. 50:29.800 --> 50:33.780 Let's switch over to some more slides here. 50:34.540 --> 50:43.040 We used internal scan to reverse the Bluetooth commands that we saw coming across the wire and then we used that in and out of application attack. 50:43.400 --> 50:47.400 So let's move into cloning some services. 50:50.020 --> 50:56.600 So this will enable us to really attack the application. 50:58.560 --> 51:06.300 Generally there isn't a lot of value in spoofing against a peripheral. 51:07.240 --> 51:10.180 Say like spoofing a user device. 51:10.180 --> 51:22.960 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. 51:22.960 --> 51:39.040 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. 51:39.040 --> 52:01.200 So what we are going to do is spoof a peripheral device and we are going to watch the victim attach 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. 52:01.200 --> 52:11.440 Meanwhile, if we were to push this further, what that would enable me to do is get a bonded session with my target. 52:11.500 --> 52:18.360 So I would have those long-term keys exchange with my target and be able to then exploit that further. 52:18.360 --> 52:29.240 So I could either use some sort of proof of concept or have that deeper interaction with that user's device. 52:30.660 --> 52:38.340 So what we're going to do is we are going to be spoofing the Bluefruit LE. 52:38.340 --> 52:41.760 Push some of this stuff out of the way here for a second. 52:42.600 --> 52:45.300 We're going to be spoofing the Bluefruit LE. 52:45.300 --> 52:48.080 It's a real simple development tool. 52:48.080 --> 52:51.080 Adafruit has all these kinds of kits that you can use. 52:51.080 --> 52:53.240 This is intended for development. 52:53.240 --> 53:01.460 It's intended to learn with and to explore how Bluetooth development works. 53:01.600 --> 53:10.380 But why we're using it is because it has its own application and one that does not have spoofing protections in it. 53:10.380 --> 53:17.340 So it's easy to basically prove this cloning concept. 53:17.340 --> 53:21.420 So let me plug things in. 53:24.080 --> 53:27.760 You can see we've got power now there. 53:30.300 --> 53:31.200 Okay. 53:31.200 --> 53:34.040 So you can see that we have power there. 53:34.840 --> 53:39.120 The Bluefruit module is on. 53:40.720 --> 53:47.960 So what I'll be doing on my device is leveraging the scanner. 53:47.960 --> 53:52.080 So I'm going to scan for devices right now. 53:52.220 --> 53:58.420 Hopefully we see this Bluefruit pop up somewhere. 53:58.860 --> 54:01.080 Ah, there we go. 54:01.200 --> 54:11.780 Freaky Zen Sinister Sun Hat was a project that I had for Defcon last year, but it didn't quite make it all the way. 54:11.780 --> 54:18.820 So what we're going to do is we're going to clone here, this clone button. 54:18.820 --> 54:22.560 So what I'm doing is I'm cloning the advertisement data now. 54:22.560 --> 54:30.300 So basically I'll be able to impersonate the Adafruit unit on the advertisement channels. 54:30.680 --> 54:36.160 So now that we've cloned it, what we can do is we can actually connect to the device. 54:39.260 --> 54:46.540 And we connect to it to get a return on the GAT services that are available. 54:46.540 --> 54:57.160 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. 54:57.320 --> 55:02.860 And you can see the little box popped up there and we've cloned the GAT services now. 55:02.860 --> 55:07.720 So we've cloned the advertisement profiles and we've cloned the GAT profiles. 55:07.720 --> 55:14.260 So now if we're able to turn these on, we're basically impersonating that device. 55:14.380 --> 55:24.100 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. 55:24.100 --> 55:27.800 So there we have the GAT services turned on. 55:27.800 --> 55:47.900 And what we also have to do is go to our advertiser and we turn on the advertisement for the Freaky Zen Sinister Sun Hat. 55:47.900 --> 55:52.260 So now we are impersonating this device. 55:54.300 --> 56:02.700 And hopefully we will get a connection to our target device. 56:02.860 --> 56:18.940 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. 56:18.940 --> 56:22.820 We're now advertising as a Spoofed Sun Hat. 56:22.820 --> 56:29.940 So we will update our scan here on the Adafruit LE app. 56:32.540 --> 56:34.800 And we can see the Phoenix 3. 56:34.800 --> 56:37.640 This is actually the name of the phone. 56:37.640 --> 56:40.700 So the name didn't update on the phone. 56:41.320 --> 56:43.980 So let's try and connect to it. 56:45.940 --> 56:51.940 And it allows us to connect to it as if it were the Sun Hat. 56:52.040 --> 56:54.080 So the Phoenix 3 is this phone. 56:54.080 --> 56:55.900 This is my attacker phone. 56:55.900 --> 57:04.940 So I've created a spoof from this phone and I've now got a connection in the application, in the Bluefruit Low Energy application. 57:06.180 --> 57:12.680 And from there, it's not giving us the right information because we're not getting returns on that. 57:12.680 --> 57:23.760 However, if I go to the server information here on my attacker, I can change things like my manufacturer string. 57:24.380 --> 57:28.260 This is an attacker. 57:28.620 --> 57:30.460 We can set that. 57:31.840 --> 57:35.260 Now we should be able to see that pop up there. 57:35.260 --> 57:43.040 You see now we've provided information on our attacker on the GAT service for the manufacturer name. 57:43.040 --> 57:53.740 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. 57:53.740 --> 58:03.200 Say we spoofed a Thingy 52 and we spoofed or we sent temperature data out from there and this read temperature data. 58:03.200 --> 58:14.620 So think about that in a real world example where say a building is relying on Bluetooth Low Energy sensors to control HVAC. 58:15.060 --> 58:29.860 Say we are able to impersonate one of those sensors and then provide, you know, fake information to whatever is reading that temperature and then making the judgments on what should be done about that temperature. 58:29.860 --> 58:42.300 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. 58:42.300 --> 58:53.080 So there is the risk of, you know, spoofing something and then providing information from that spoof. 58:53.080 --> 59:01.720 But I also have a connection now, a bonded connection to my target device that I could potentially exploit even further. 59:01.720 --> 59:04.260 So we just went through the basic pieces. 59:04.260 --> 59:06.400 We cloned the advertisement data. 59:06.400 --> 59:08.700 We changed our device name. 59:08.700 --> 59:10.620 We cloned the device services. 59:11.780 --> 59:23.960 We went through and turned on the advertiser and then we actually connected through and provided a spoof that our victim connected to. 59:24.880 --> 59:32.940 So I do want to introduce you to Hacknarr's BLE CTF. 59:34.580 --> 59:38.600 It runs on ESP32. 59:39.740 --> 59:48.740 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. 59:48.740 --> 59:52.200 So I have, you know, like maybe 10 or 20 of these that I give out. 59:52.680 --> 01:00:01.460 But obviously since we are all all safe mode and social distancing, then I can't really give a bunch of these out. 01:00:01.460 --> 01:00:06.040 But they're like $10 and you can upload all the information yourself. 01:00:06.520 --> 01:00:12.800 And you can actually go through a BLE CTF and it's more of just interacting on GAT services. 01:00:12.800 --> 01:00:19.460 So what we went through earlier where we were doing the abusing of right privileges. 01:00:19.460 --> 01:00:24.080 So there are a bunch of challenges on there. 01:00:24.080 --> 01:00:31.840 Some of them are, you know, decoding MD5 or, you know, following certain instructions that you get back from the services. 01:00:31.980 --> 01:00:42.800 So if you have, you know, interest in exploring more on the GAT side, then I would definitely recommend checking out Hacknarr's BLE CTF. 01:00:42.800 --> 01:00:48.540 And of course, if you need help, feel free to reach out to me on Twitter or wherever. 01:00:50.160 --> 01:00:58.160 And so a few recommendations for just kind of the individual Bluetooth low energy user or your consumer. 01:00:59.100 --> 01:01:02.520 Keep your Bluetooth turned off unless you really need it. 01:01:02.660 --> 01:01:12.940 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. 01:01:12.940 --> 01:01:17.240 So this might not be valid information in a few years. 01:01:17.240 --> 01:01:20.900 We may just always have to just deal with Bluetooth being on. 01:01:22.720 --> 01:01:27.560 Choose low traffic areas to do pin pairing sessions with. 01:01:27.560 --> 01:01:42.060 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. 01:01:42.060 --> 01:01:49.620 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. 01:01:49.740 --> 01:01:53.120 Generally, your home is a good option. 01:01:53.780 --> 01:01:58.940 Or, you know, an uninhabited part of your office, maybe. 01:02:00.540 --> 01:02:09.700 Also, be aware that like we saw with the Blue Fruit LE app, a lot of apps don't have spoofing protections. 01:02:09.700 --> 01:02:14.960 So you could very well be connecting to something that is not what you thought it was. 01:02:14.960 --> 01:02:24.280 And you've allowed an attacker to either provide you with false information or gain a bonded connection to your phone that they could then further abuse. 01:02:24.380 --> 01:02:35.980 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? 01:02:35.980 --> 01:02:38.780 Can I create a spoof of this device? 01:02:39.080 --> 01:02:41.520 How does the application handle that? 01:02:41.520 --> 01:02:43.220 You might need two phones for that. 01:02:43.220 --> 01:02:44.500 But, yeah. 01:02:44.500 --> 01:02:52.080 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. 01:02:52.340 --> 01:02:54.380 Make sure it's running Android 7. 01:02:55.500 --> 01:02:56.180 So, yeah. 01:02:56.180 --> 01:02:59.380 Those are a few of my recommendations for consumers. 01:03:00.840 --> 01:03:18.540 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. 01:03:18.540 --> 01:03:40.660 So, using something like NFC to actually pass long-term keys will increase the security of the Bluetooth data because... or the integrity of it because you don't have the risk of using basically an unprotected channel to pass keys to then protect it. 01:03:40.660 --> 01:03:43.860 So, you're using out of band practices. 01:03:44.920 --> 01:03:48.440 Don't focus solely on device security. 01:03:48.880 --> 01:03:53.060 You know, does your application have good spoofing protections? 01:03:54.420 --> 01:04:04.240 Is your app just looking for devices on name alone or is it looking, you know, for something deeper? 01:04:04.960 --> 01:04:22.020 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. 01:04:22.020 --> 01:04:30.760 So, say your cloud application would actually... or your application on your phone would have a connection to a cloud server somewhere. 01:04:30.760 --> 01:04:43.820 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 cloud and then validated. 01:04:43.820 --> 01:04:49.080 And if it's not valid, then obviously you wouldn't connect or you could blacklist it or something like that. 01:04:49.260 --> 01:04:51.700 So, that's what I tend to recommend. 01:04:52.340 --> 01:05:09.520 So, as far as further study, there are a number of Bluetooth researchers, but probably the one that I follow the most and the most enthusiastic is Jiska. 01:05:09.520 --> 01:05:11.620 I think I'm saying that right. 01:05:11.620 --> 01:05:23.820 But she is a... she's a security researcher and, yeah, an RF kind of wizard out of Europe. 01:05:25.040 --> 01:05:27.540 So, yeah, follow her on Twitter. 01:05:27.540 --> 01:05:31.380 She does a lot of talks all over the place. 01:05:31.680 --> 01:05:36.420 If you're looking for books, Hacking Exposed Wireless is amazing. 01:05:36.420 --> 01:05:43.360 I just went through the work for the GAWN and it's very, very similar. 01:05:43.360 --> 01:05:45.240 Obviously written by the same people. 01:05:45.240 --> 01:05:49.520 So, of course, there's going to be knowledge kind of overlap there. 01:05:49.980 --> 01:06:08.740 And if you're looking to get more on the hands-on side, then the Adafruit BlueFruit LE, the Thingy 52, ESP32s, and the UD100 Bluetooth USB adapter, which we didn't cover in this talk, is capable of doing more long-range stuff. 01:06:08.740 --> 01:06:13.240 So, that's definitely something you'll want to pick up if you have an interest in taking this further. 01:06:18.440 --> 01:06:19.480 Okay. 01:06:21.140 --> 01:06:35.040 So, with the badge just on, if you just turn it on, you can see the Bluetooth mesh pop up in nRF Connect. 01:06:37.380 --> 01:06:40.820 But I'm not able to connect to it. 01:06:49.400 --> 01:06:57.540 So, I'm able to see the Anode XOR badge within nRF Connect, the Bluetooth mesh you see there, it's listed as such. 01:06:57.540 --> 01:07:00.560 And I can try to connect to it. 01:07:01.280 --> 01:07:09.620 And I have a connection to it, and it's giving me certain options. 01:07:09.620 --> 01:07:14.200 I've done some poking around on this side, but I haven't found a lot. 01:07:14.580 --> 01:07:18.680 This SMP characteristic might be fun to poke around with. 01:07:20.440 --> 01:07:24.400 But what I have seen is, 01:07:33.570 --> 01:07:42.550 within the SMP characteristic, you can actually do some interesting commands that have these right values here. 01:07:42.550 --> 01:07:50.970 But, you know, OS echo commands, so you can echo commands through Bluetooth into the operating system. 01:07:50.970 --> 01:07:52.770 I haven't got much interaction from that. 01:07:52.770 --> 01:07:55.870 I've tried the commands, but it hasn't really worked. 01:07:55.870 --> 01:08:01.070 But the one that I have seen that works very well is the reset command. 01:08:01.070 --> 01:08:03.670 So, I will switch over here. 01:08:03.810 --> 01:08:10.270 So, as soon as I hit the reset command, you'll see the badge turns off. 01:08:11.790 --> 01:08:13.190 We'll send that. 01:08:13.550 --> 01:08:15.150 And then the badge turns off. 01:08:26.430 --> 01:08:43.390 Last year, if you were at DEF CON and they were talking about 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, 01:08:43.390 --> 01:08:45.810 make it do different things, send different commands. 01:08:45.810 --> 01:08:53.050 So, very cool, very cool kind of puzzle and interaction and tool for learning. 01:08:53.050 --> 01:09:03.070 So, if you have one of these badges, one of these Anonyx or DC27 badges, or I believe the one before that also had a Bluetooth mesh on it. 01:09:03.830 --> 01:09:08.090 But if you have one of these badges, they would be awesome to hack on. 01:09:08.350 --> 01:09:12.670 Yeah, so they have that Bluetooth component. 01:09:12.670 --> 01:09:14.730 That's going to wrap up my presentation. 01:09:15.010 --> 01:09:22.190 And I just want to thank you for spending the time with me today and learning about Bluetooth low-energy hacking. 01:09:22.250 --> 01:09:23.990 Hopefully, you learned something. 01:09:23.990 --> 01:09:31.970 Hopefully, you found something that maybe caught your interest and, you know, you're ready to explore the Bluetooth low-energy devices around you. 01:09:33.030 --> 01:09:38.090 Don't forget the further study that I pushed out in one of the last slides. 01:09:38.090 --> 01:09:44.510 And if you have any questions, feel free to reach out to me on Twitter or LinkedIn or anywhere, really. 01:09:44.650 --> 01:09:48.410 And I will try my best to get in touch with you. 01:09:48.410 --> 01:09:50.850 I know sometimes I don't do a great job. 01:09:50.850 --> 01:09:54.950 But, yeah, so thank you so much for joining me. 01:09:54.950 --> 01:09:59.350 And I hope you have a wonderful, wonderful DEF CON safe mode.