[00:20.400 --> 00:27.400]  Hey, everyone. Welcome to the basics of breaking BLE. I'm Preeti Sen. I want to thank you for
[00:27.400 --> 00:33.140]  joining me and I want to thank the Wireless Village for featuring me today. Also, I want to
[00:33.140 --> 00:41.220]  thank DEF CON for going into safe mode and allowing us the space to interact and learn with each
[00:41.220 --> 00:51.780]  other. So, I've got a few things planned for us today. We've got some just going over the basics
[00:51.780 --> 01:03.120]  of what BLE is as far as the technology, just how expansive it is, some kind of tools and techniques
[01:03.120 --> 01:11.140]  that you can use for pen testing or just exploring Bluetooth low energy devices around you.
[01:11.840 --> 01:21.720]  So, as you can see here on the desk, I have a few devices. We have the Bombadge from
[01:23.100 --> 01:35.120]  DC27, Team IDES. We have Hacknar's BLE CTF. If any of you have seen any of my in-person talks,
[01:35.120 --> 01:42.020]  I usually try to feature this piece a lot because I feel like it's a very easy
[01:43.000 --> 01:52.920]  a sort of entry point for people to learn how to interact with GAT services on Bluetooth devices.
[01:54.120 --> 02:03.320]  So, going on, we also have a Thingy 52. 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:19.080]  different gyroscopes and LEDs and all sorts of fun things. And then, of course, we have
[02:19.080 --> 02:27.600]  Anode XOR's DC27 badge that has a Bluetooth mesh network on it. We'll look at some of this and
[02:28.100 --> 02:31.940]  some interesting things that I found on the badge poking around looking for demonstration
[02:31.940 --> 02:42.460]  items for today. We actually also have the LG Phoenix LG150. This phone is important because
[02:42.460 --> 02:52.460]  it's the only one that I have found so far that allows for live capture of the BT Snoop
[02:53.100 --> 03:00.400]  file from an Android device into Wireshark. I feel that the live capture is important when you're
[03:00.400 --> 03:05.200]  auditing devices because you can actually see the command interactions between devices
[03:06.400 --> 03:13.220]  and the changes in real time. If I hit this button and this command comes across the wire,
[03:13.220 --> 03:18.540]  then it's probably pretty obvious that that is the command that's controlling that. And if you
[03:18.540 --> 03:23.120]  can see a difference in the variables, then you have an easier time in reversing the commands
[03:23.120 --> 03:29.040]  and actually being able to find meaningful exploits or meaningful ways of interacting
[03:29.040 --> 03:40.260]  with devices. So going on, the last item that we have is the Adafruit Bluefruit LE. This has
[03:41.470 --> 03:49.440]  some services that I built on it for DC27, actually. So we will look at actually cloning
[03:49.440 --> 04:00.460]  this device and spoofing it against a target. So just a short introduction to who I am.
[04:00.460 --> 04:07.180]  My name is Maxine Filcher. I also go by Freaky Zen online. Security consultant with IOActive.
[04:07.180 --> 04:15.380]  Sarmie veteran. Graduated class of 2020 with a BS in Info Assurance and Cybersecurity. I also
[04:15.380 --> 04:22.900]  have a minor in Law and Policy. I'm also a member of the SANS Women's Academy 2018 cohort,
[04:22.900 --> 04:30.520]  where I earned the GSEC, the GCIH, and the GPEN. I am also in the process of studying for the
[04:30.520 --> 04:39.480]  GAWN. So just a small disclaimer, I'm not a Bluetooth developer by any means. But I have
[04:39.480 --> 04:49.080]  been teaching about Bluetooth hacking and just general Bluetooth concepts for a couple of years
[04:49.080 --> 04:59.780]  now. So I feel like I am fairly well versed in this topic. So in any of my demonstrations,
[04:59.780 --> 05:08.640]  I always like to frame wireless security as greater than just Wi-Fi or just Bluetooth.
[05:09.940 --> 05:17.280]  In pen testing, when we see companies talk about wireless, you know, pen tests, generally they're
[05:17.280 --> 05:23.980]  talking about their Wi-Fi and they are, you know, completely ignoring a lot of other vectors that
[05:23.980 --> 05:33.040]  could occur with wireless. So I always like to bring up this kind of definition, I guess,
[05:33.040 --> 05:39.920]  this contrast in definition, you know, this weak definition from Wikipedia where it's wireless
[05:39.920 --> 05:45.540]  networks. Which I mean, I guess, could be broadly interpreted. But I much prefer the NIST,
[05:46.220 --> 05:52.760]  which I believe is still current. It may have been updated. But the NIST definition of wireless
[05:52.760 --> 05:58.740]  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:14.540]  You know, many different technologies. We have Bluetooth, Wi-Fi, ZigBee, RFID, NFC, Cell,
[06:15.260 --> 06:22.860]  and these come into a number of different industries. So medical is one that is growing
[06:22.860 --> 06:29.420]  pretty rapidly as far as Bluetooth low energy. And then, of course, IoT, the things around us,
[06:29.420 --> 06:36.080]  all these smart devices that really rely heavily on Bluetooth low energy to communicate.
[06:36.440 --> 06:42.880]  Then, you know, industry 4.0, Bluetooth is starting to get more into, you know,
[06:42.880 --> 06:49.740]  automated systems within factories and smart buildings. And also, you know, smart automated,
[06:49.740 --> 06:55.560]  you know, HVAC systems, or just building control systems. So Bluetooth is really starting to make
[06:55.560 --> 07:05.720]  its way into these important and sometimes, you know, high risk sort of systems. So Bluetooth is
[07:05.720 --> 07:15.040]  becoming more of an important research topic and, you know, target for actually pen testing
[07:15.040 --> 07:22.140]  as we go and as the technology develops. So just a few basics about Bluetooth.
[07:22.640 --> 07:31.780]  You'll find it in, you know, within the ISN band. So 2.4 to 2.485 gigahertz in this case for
[07:31.780 --> 07:39.080]  Bluetooth low energy. It comes in a few different flavors, you could kind of call them. Although
[07:39.080 --> 07:46.820]  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:04.680]  Any more you will find that in things like wireless headsets. So, you know, your Bluetooth
[08:04.680 --> 08:11.710]  headsets, anything where you're streaming data that needs larger packets and maybe higher throughput,
[08:11.960 --> 08:18.600]  that will generally go through on Bluetooth classic or BREDR is what it's known as now.
[08:19.160 --> 08:25.860]  Bluetooth low energy is what it is described as. It's a low energy protocol. It's intended
[08:25.860 --> 08:31.540]  to be used in devices that could run on a coin cell battery for up to a year.
[08:31.980 --> 08:39.860]  So that's a pretty heavy design specification for something, you know, that is low touch. You can
[08:39.860 --> 08:43.800]  put it somewhere and it's supposed to be able to work and, you know, you're not supposed to
[08:43.800 --> 08:51.340]  worry about the power and you can interact with it all day long. Something new that's emerging,
[08:51.340 --> 08:57.560]  and I mentioned it with the N on XOR badge, is Bluetooth mesh. Bluetooth mesh is actually,
[08:57.560 --> 09:02.320]  you can kind of think of it as a hat that goes on top of Bluetooth low energy. It uses some of
[09:02.320 --> 09:07.620]  the underlying components, but it adds things like provisional keys and application keys.
[09:07.620 --> 09:15.700]  And it's a mini to mini connection and it's very interesting. It can use, you know,
[09:16.580 --> 09:22.480]  pathways across other devices and set up nodes. It's a very interesting portion of the protocol.
[09:22.860 --> 09:31.760]  But we aren't really going to get into Bluetooth mesh too much. So just some other numbers,
[09:31.760 --> 09:37.120]  of course, you know, Bluetooth low energy is blowing up still all across the world,
[09:37.120 --> 09:44.400]  all these different technologies. I'm sure you have more than a few Bluetooth low energy devices
[09:44.400 --> 09:56.460]  around you right now. I also love to throw in, you know, little tidbits of history about Bluetooth.
[09:56.460 --> 10:04.040]  I think it's got kind of a fun origin with the name and kind of the intentions behind it. So
[10:04.040 --> 10:09.980]  you can see that if you've ever wondered where the Bluetooth symbol comes from, it's actually a
[10:09.980 --> 10:17.240]  mixture of two runic symbols, one for H and one for B. And this is actually for Harald Bluetooth,
[10:17.240 --> 10:24.440]  who was the king of Norway and Denmark. He was seen as a great unifier of these countries and
[10:24.440 --> 10:30.040]  brought together these nations. If you've watched Vikings, the History Channel series,
[10:30.040 --> 10:36.720]  you might recognize the guy whose picture I've pasted up there. But yes,
[10:36.720 --> 10:44.560]  it's loosely based on the same person, on the same historical character or figure.
[10:44.720 --> 10:50.240]  Another person that I really love that is integral to the development in Bluetooth,
[10:50.240 --> 10:56.400]  but not really in sort of a direct creating of the protocol or anything like that,
[10:56.400 --> 11:04.880]  Hedy Lamarr. I love the story of Hedy Lamarr. I love the story of her, you know, totally being
[11:04.880 --> 11:11.980]  just underestimated, but being so brilliant. And for those who aren't familiar, she was an actress
[11:12.880 --> 11:21.320]  in the early part of the 20th century. And she came from Austria, fairly scandalous kind of
[11:21.320 --> 11:28.600]  background, had left her husband, who had decided to supply arms to the Nazi party.
[11:28.600 --> 11:36.480]  She came to the United States and she befriended a man named George Anthel. And together they
[11:36.480 --> 11:47.880]  worked on a concept for creating a torpedo that was basically protected against jamming,
[11:48.440 --> 11:55.020]  or the interruption of the signal, whether that was intentional or unintentional, for torpedoes
[11:55.020 --> 12:03.840]  that were fired from either allied submarines or allied ships. A lot of times these torpedoes,
[12:03.840 --> 12:08.080]  when they were fired, they would either get jammed or they would lose connection. And sometimes they
[12:08.080 --> 12:14.000]  could actually backtrack around and hit the ship that fired the torpedo originally. So this was,
[12:14.000 --> 12:18.380]  at the time, was actually a fairly large concern. And it was something that was
[12:20.460 --> 12:26.140]  kind of an operational hazard that you had to put up with. And together they came up with
[12:26.880 --> 12:35.300]  this concept of frequency hopping spread spectrum. And this is where two devices,
[12:35.940 --> 12:45.320]  two transceivers, would have the set channel hopping, or it would have channels set within
[12:45.320 --> 12:52.760]  them that they would hop across at a set interval and at a set rate. So once these were loaded in,
[12:52.760 --> 13:00.580]  they would hop across the frequency spectrum in a way that would skip just pinpoint jamming,
[13:00.580 --> 13:05.060]  or just any kind of natural interference since it was skipping across frequencies.
[13:05.060 --> 13:14.760]  So this was actually a fairly unique idea at the time. It was based on player pianos,
[13:14.760 --> 13:20.500]  synced player pianos, which is kind of cool. If you have more interest about this story,
[13:20.500 --> 13:26.780]  there is an amazing documentary on Netflix called Hedy Lamarr, or Bombshell the Hedy Lamarr Story.
[13:26.780 --> 13:29.900]  Highly recommend that you check it out. It's a little bit sad, but
[13:29.900 --> 13:34.580]  if you're curious about the background, it's a really amazing story.
[13:36.760 --> 13:45.040]  So let's get into a little bit of terminology. So as far as devices within Bluetooth connections,
[13:45.040 --> 13:51.920]  we can think about devices in two ways. Central and peripheral. So your central devices are
[13:51.920 --> 13:59.920]  generally going to be your phone, or the device that the user is actually interacting with.
[14:00.420 --> 14:06.500]  So, you know, whether that's a tablet, or a laptop, or a TV, or something like that,
[14:06.500 --> 14:13.140]  where it's actually initiating the connection to whatever peripheral device. Say that's
[14:14.600 --> 14:19.200]  any kind of device that you're going to connect to, that's a peripheral device. It's not something
[14:19.200 --> 14:22.560]  that you are directly interacting with, with like an application on your phone,
[14:22.560 --> 14:31.300]  that's generally going to be a peripheral. So connections are also something that's important
[14:31.300 --> 14:36.680]  in Bluetooth, obviously, it's a wireless protocol. So there has to be some sort of
[14:37.240 --> 14:43.340]  way the connections are handled. Bluetooth Low Energy, just like Bluetooth, has set channels
[14:43.340 --> 14:52.660]  where it advertises itself on, or to central devices that may be looking to connect to it.
[14:53.120 --> 14:58.420]  So it has three set channels, Bluetooth Low Energy has three set channels that will broadcast across
[14:58.420 --> 15:07.760]  37, 38, and 39. And there are also four advertising PDU types. I won't go over those,
[15:07.760 --> 15:12.620]  you can look them up. They don't really have too much impact on what we're going to talk about
[15:12.620 --> 15:24.600]  today. So we also have 36 channels for Bluetooth Low Energy separated by two megahertz across the
[15:24.600 --> 15:31.840]  spectrum. And when we're also speaking about connections, we think about them in two phases,
[15:31.840 --> 15:38.590]  sort of. Once you see the advertising of a device that you want to connect to,
[15:38.590 --> 15:45.730]  from your phone, you will initiate the pairing process. I'm fairly confident that most people
[15:45.730 --> 15:53.550]  are familiar with the pairing process. But it's where you initiate a wireless connection.
[15:53.950 --> 15:59.830]  And these come in kind of two phases. So you have your basic pairing session where you're unbonded,
[15:59.830 --> 16:07.650]  or you've passed your short term keys between the devices. So they have established a connection,
[16:07.650 --> 16:14.670]  but it's not trusted on certain levels, and it's not been placed into... the devices haven't been
[16:14.670 --> 16:21.130]  placed into each other's sort of trusted devices list. So once you create a bonded connection,
[16:22.030 --> 16:27.490]  that will actually... those devices are actually transferring long term key information between
[16:27.490 --> 16:36.190]  each other. In most cases, they'll go into a trusted device list, so that either the short
[16:36.190 --> 16:42.710]  term key pairing process can be skipped, or there's no need to even initialize the pairing
[16:42.710 --> 16:48.330]  process again at all. You can just, you know, whenever you're in proximity of the device,
[16:48.330 --> 16:53.250]  it will just automatically connect to you. So that's one of the benefits of bonding.
[16:53.250 --> 17:00.890]  Another benefit of bonding is you will oftentimes have greater leeway in the
[17:02.570 --> 17:10.130]  amount of kind of tolerance for fuzzing on a device. So if you just have a short term key
[17:11.250 --> 17:17.810]  pair with a device, and you try to start fuzzing GAT services, there's a good likelihood that that
[17:17.810 --> 17:24.390]  device will end that pair. Once you've bonded with a device, there is a greater chance that
[17:24.390 --> 17:29.930]  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:47.290]  We talked about how it kind of comes in multiple flavors, and you can see that we have classic
[17:47.290 --> 17:55.590]  B-R-E-D-R there. And then you can see the hybrid version of Smart Ready, and now Bluetooth Smart,
[17:55.590 --> 18:00.700]  which most new Bluetooth low energy devices coming out should be Bluetooth Smart.
[18:02.200 --> 18:09.400]  Although most phones will have the ability to use B-R-E-D-R in the case of, say,
[18:09.400 --> 18:15.540]  Bluetooth headphones or that sort of thing. There is also a new audio
[18:17.760 --> 18:22.880]  protocol that is coming out, a new Bluetooth low energy audio protocol.
[18:23.280 --> 18:29.380]  It was announced earlier this year. I haven't personally seen a lot of specifications on it,
[18:29.380 --> 18:34.320]  but I'm sure that there are people that can answer lots of questions about it already.
[18:35.240 --> 18:42.840]  But it's interesting. I'm excited from a security researcher perspective to get my hands on some of
[18:42.840 --> 18:49.860]  the devices, just because it sounds like it might have some issues, but we'll have to see.
[18:50.280 --> 18:54.940]  So, yeah, just some of the basic components of the protocol stack that we're going to really
[18:54.940 --> 19:01.620]  pay attention on today is GATT. I've already mentioned it a couple of times, but it's the
[19:01.620 --> 19:12.100]  generic attribute profile. These are where the profiles of the services that a device can offer
[19:12.100 --> 19:20.400]  are stored. So you can think about this as sort of a catalog of things that a device can do,
[19:20.400 --> 19:28.320]  whether that's measuring heart rate or giving temperature or measuring humidity levels.
[19:28.320 --> 19:34.440]  There's a GATT service, and there's a way for that information or that service to be interacted
[19:34.440 --> 19:40.560]  with. So there is a way to retrieve that temperature or that humidity measurement
[19:41.200 --> 19:46.320]  through the GATT services. Primarily, we're going to be interested in GATT services today.
[19:48.080 --> 19:51.300]  Okay. So we've already talked about that.
[19:52.820 --> 20:02.000]  So when I talk about GATT hacking, what I'm really talking about is the abuse of read or
[20:02.000 --> 20:12.960]  write privileges on a device over their GATT services. So in the case of iOS, read privileges
[20:12.960 --> 20:21.000]  can be abused fairly easily. And you can do things like retrieve the cell phone username,
[20:21.360 --> 20:30.420]  the battery level, the OS version, which may not be such an issue on the surface. But once you
[20:30.420 --> 20:36.500]  start poking lower into the protocol or into this vulnerability, especially with the proof of
[20:36.500 --> 20:44.120]  concept called Apple BLEEE, you can see that there are some significant interactions that are
[20:44.120 --> 20:51.160]  available over GATT, and there are some very significant information disclosures from iOS.
[20:52.400 --> 20:58.740]  So a few simple write privilege abuses that I have seen in devices that I have pin tested
[20:59.800 --> 21:06.480]  are just sending simple code. So picking out a GATT service, and I just start fuzzing codes.
[21:07.320 --> 21:17.500]  In some of the real world cases that I've seen, writing the hex value 0x08, and that enables me
[21:17.500 --> 21:24.880]  to set up a new pin between the devices. So now I'm defeating one of the very few security measures
[21:24.880 --> 21:30.840]  that you have for controlling Bluetooth connections. Further still, I've been able to
[21:30.840 --> 21:39.100]  achieve over the air firmware update mode. So writing 01 to a GATT service will actually allow
[21:39.100 --> 21:45.680]  you to push firmware to a device. I mean, you obviously could get, you know, lower interactions
[21:45.680 --> 21:51.420]  than potentially placement malicious firmware onto a device. And then, you know, who knows,
[21:51.420 --> 21:57.460]  you'd own that device then. Other devices I've seen like write 02 to a GATT service,
[21:57.660 --> 22:02.660]  a specific GATT service, and it would start a heating cycle on a device. So, you know,
[22:02.660 --> 22:10.100]  potentially there is danger there. So Bluetooth Low Energy does have security. It's developed
[22:10.100 --> 22:17.820]  through the years, mainly in response to security research that's been done, where, you know,
[22:18.060 --> 22:22.100]  a big set of vulnerabilities comes out and the technology has to respond to that in kind of a
[22:22.100 --> 22:28.240]  dynamic way or, you know, they risk really losing their customer base. So Bluetooth SIG has done a
[22:28.240 --> 22:37.080]  fairly decent job of responding to security researchers and trying to get chip manufacturers
[22:37.080 --> 22:44.280]  and developers on board with everything. But yeah, so there's a lot of space for growing,
[22:44.280 --> 22:49.880]  and there's also a lot of space for research. So Bluetooth Low Energy has
[22:50.980 --> 23:00.980]  currently, I would say the standard would be 4.2. Although BLE 5.0, the new standard that came out,
[23:00.980 --> 23:09.880]  has some pieces that strengthen the just works pairing by introducing some nonce values. The
[23:09.880 --> 23:15.020]  more entropy, the better. We have protections against man in the middle. We have protections
[23:15.020 --> 23:21.220]  against eavesdropping, and theoretically there's authentication via pairing and bonding,
[23:21.220 --> 23:26.820]  but we can see that oftentimes that's not the case and that can be abused pretty easily.
[23:28.500 --> 23:35.000]  So some of the Bluetooth vulnerabilities that have come out in the past. Once I started getting
[23:35.000 --> 23:44.380]  into Bluetooth pretty heavily, Blueboard was pretty fresh. It was fairly new, and it
[23:44.380 --> 23:49.460]  seemed to scare a lot of people. That's when I noticed Bluetooth security research really kind
[23:49.460 --> 23:57.300]  of starting to kick up again. It seemed like it had died off before that. And since then,
[23:57.300 --> 24:03.120]  there have been major vulnerabilities that's released every year. I think there were two,
[24:03.120 --> 24:08.780]  well Sphintooth was released earlier this year, and then there was a new set that they released,
[24:08.900 --> 24:13.540]  a new vulnerability set that they released just a couple of weeks ago for Sphintooth.
[24:14.940 --> 24:21.340]  So interesting piece about, or interesting trivia piece about Sphintooth. It's actually
[24:21.980 --> 24:29.580]  named after the son of Harold Bluetooth. So got a cool marketing piece that they did in there.
[24:29.580 --> 24:37.500]  So Sphintooth, since it's brand new, we'll talk about that, really starts to attack the protocol
[24:37.500 --> 24:45.960]  in ways that I personally haven't been testing it. And just fuzzing the header values and fuzzing
[24:45.960 --> 24:51.160]  the protocol in a way that just makes things stop working. There are a lot of denial of service
[24:51.160 --> 24:57.580]  vulnerabilities within this. A lot of deadlocks, security bypasses that are included within this.
[24:57.740 --> 25:02.680]  And it's fairly expansive. There are a lot of vendors that are impacted by Sphintooth.
[25:02.700 --> 25:07.380]  So a pretty cool piece of research. I personally haven't had a lot of time to jump into it,
[25:07.380 --> 25:15.880]  but I have read through it quite a bit. And it's pretty interesting. These are just a few of the
[25:15.880 --> 25:21.860]  Bluetooth tools out there that you can use. Some of these are proof of concepts, but they have
[25:21.860 --> 25:26.180]  neat scripts that you could either alter or actually just use as they are.
[25:27.720 --> 25:35.060]  So the first tool that we're going to look at is the Ubertooth One. Let me switch over here.
[25:35.060 --> 25:44.320]  So I have one right here. It's an older device. It's a few years old. But it's still probably
[25:44.320 --> 25:55.820]  the best way to ingest externally viewed Bluetooth packets into Wireshark. And I say externally
[25:55.820 --> 26:04.120]  because this is what I consider to be looking from the outside in to a Bluetooth connection
[26:04.120 --> 26:12.860]  between devices. So generally, you won't see a lot because things should be encrypted. Although
[26:12.860 --> 26:18.560]  I have seen some devices that say they are doing things, but they aren't actually encrypting things.
[26:18.560 --> 26:25.960]  So you're able to pull commands out of the air. But this is still probably the best tool that you
[26:25.960 --> 26:35.640]  can use for that use case for trying to check encryption or trying to check a device connection
[26:35.640 --> 26:48.920]  for its strength against eavesdropping and passive sniffing. So the GreatFET One is a tool that's
[26:48.920 --> 26:57.160]  still currently in development, I would consider. The Quincy was announced as the first
[26:57.690 --> 27:03.320]  sort of hat that was going to be added to this, the add-on hat. And it would allow for full
[27:03.320 --> 27:10.300]  spectrum sniffing of Bluetooth Low Energy. So instead of having to use an Ubertooth, which is
[27:10.300 --> 27:19.880]  locked into one advertisement channel at a time, you would be able to sniff all 36 channels
[27:20.900 --> 27:26.040]  at a time and be able to see basically all the Bluetooth information that's going on.
[27:26.040 --> 27:40.280]  So much easier to kind of manage as far as mass sniffing operations. But as of yet,
[27:41.000 --> 27:46.260]  um, and I haven't heard anything about a price. Maybe that'll change with Defcon coming up. So
[27:46.260 --> 27:50.560]  this is being recorded beforehand. So maybe there's already been an announcement. And
[27:50.560 --> 28:00.420]  if that's the case, then disregard this portion. So another tool that you probably won't get to use
[28:00.920 --> 28:05.700]  or probably won't see unless you have a lot of money or you work for a bigger employer
[28:06.940 --> 28:18.280]  is the Eliasys system, which relies on SDR. And it's the same kind of concept as the Quincy
[28:19.180 --> 28:26.260]  in that it's looking to do a mass spectrum capture. So it's trying to capture all of the
[28:26.260 --> 28:31.920]  Bluetooth packets that it possibly can. And then you can go through there and sort it by connection
[28:31.920 --> 28:38.500]  and see everything. This actually, this system will go even further and in some cases will strip
[28:38.500 --> 28:45.980]  the encryption off of the packet. So the software is actually pretty cool. I've had the chance to
[28:45.980 --> 28:53.900]  use one of these systems. And yeah, it's it's a very powerful tool that you can do a lot of
[28:53.900 --> 28:59.360]  really meaningful research with. But there is a huge price tag that's associated with it.
[28:59.940 --> 29:08.320]  And so that brings us to nRF Connect. And nRF Connect is what I generally use on
[29:08.320 --> 29:17.880]  engagements first. So I will exhaust every avenue possible with nRF Connect because it's free
[29:18.340 --> 29:24.080]  and it installs on any smart device. So well, you know, Android or iOS.
[29:24.080 --> 29:32.940]  And so it's highly available. It's extremely simple to use. It allows for abuse of GATT
[29:32.940 --> 29:41.500]  services. It also allows for cloning and spoofing. So it's a fairly useful tool.
[29:41.660 --> 29:47.600]  So that's where I like to start all of my engagements with because if I can prove that there
[29:48.160 --> 29:57.660]  is impact from this free and highly available tool, then the chances are that you probably have
[29:57.660 --> 30:03.980]  larger problems and someone with more technical ability or more powerful tools is likely going
[30:03.980 --> 30:11.280]  to be able to have even greater impact on your systems. So, you know, let's take a sort of low
[30:11.280 --> 30:19.660]  hanging fruit first approach. So I always start with nRF Connect. You know, it was intended for
[30:19.660 --> 30:25.380]  debugging but it works wonderful for the purposes that I need. One of the great things that you can
[30:25.380 --> 30:32.850]  do with this is record macros. So sometimes devices will only allow for momentary connections.
[30:33.780 --> 30:40.040]  Just long enough for two devices to basically pass short-term keys and decide that one device
[30:40.040 --> 30:44.800]  says that I don't want to talk to you because I don't know who you are. Well, still in that
[30:44.800 --> 30:49.880]  period of time there may be two seconds, three seconds where you have the window to actually
[30:49.880 --> 30:56.120]  send GATT commands in. And if you can capture that and potentially send a command to a device,
[30:56.120 --> 31:02.740]  you may actually get interaction with it even though you're not establishing a long-term
[31:03.540 --> 31:08.900]  paired session, bonded session. You're just that momentary connection.
[31:08.900 --> 31:14.860]  So I really enjoy the macro feature. And of course you can also export the logs which
[31:15.420 --> 31:20.040]  you know help for reporting. nRF sniffer we won't actually talk about. So
[31:21.000 --> 31:27.140]  BetterCap is a tool capable of interacting or allowing you to interact with GATT services of
[31:27.260 --> 31:38.700]  a device but from a Linux machine using a BLE dongle. So Kismet has the ability to do this
[31:38.700 --> 31:45.920]  but I feel like BetterCap has a slightly better UI for this. But it can be a little bit difficult
[31:45.920 --> 31:55.360]  to install. But yeah, you have the ability to send requests and commands over GATT. So it's
[31:55.360 --> 32:02.240]  still a very powerful tool if you're interested in doing this from a laptop or a desktop rather
[32:02.240 --> 32:11.920]  than a mobile device. Another powerful tool from a desktop machine is Scapi. So Scapi actually will
[32:11.920 --> 32:19.740]  allow you the ability to script. And this is very powerful once you start looking at these deeper
[32:19.740 --> 32:26.600]  interactions. So if you wanted to follow along with the Sphintooth vulnerabilities, you could
[32:26.600 --> 32:33.800]  actually craft packets using the Scapi library to attack those specific pieces of the protocol
[32:33.800 --> 32:40.920]  and push different kinds of data to them and potentially push them over. So if you're looking
[32:40.920 --> 32:47.480]  to do that deeper kind of penetration testing or research on Bluetooth energy, low energy,
[32:48.020 --> 32:51.680]  the Scapi library is definitely something you'll want to check out.
[32:52.720 --> 32:59.700]  And another essential tool that I use on just about every one of my pen tests for Bluetooth
[32:59.700 --> 33:06.840]  low energy devices is Android Debug Bridge. For those of you who might not be familiar with this,
[33:06.840 --> 33:13.900]  this allows you to create a PC interface to your Android device over USB.
[33:13.900 --> 33:23.960]  And generally, most phones won't allow you to do the live capture of BT Snoop logs, which is
[33:23.960 --> 33:33.180]  where Bluetooth low energy connections and data is logged to. So in the case of the LG phone that I
[33:33.180 --> 33:39.460]  have here, the LG M150, that will allow for us to do a live capture into Wireshark. And we'll
[33:39.460 --> 33:45.780]  look at this here shortly. So just some basic installation instructions if you're not familiar
[33:45.780 --> 33:55.280]  with ADB. Very simple to set up. Very easy to get going and to use. So I mentioned Kismet earlier.
[33:55.280 --> 34:00.800]  If you're not familiar with Kismet, it also supports Bluetooth low energy, but it has some
[34:00.800 --> 34:08.220]  functionality, but they may be, you know, increasing that as we speak. So, you know,
[34:08.220 --> 34:15.500]  that tool is definitely growing in its functionality and its capabilities every day.
[34:16.300 --> 34:24.660]  And we've mentioned Apple BLEEE, a wonderful proof of concept for the security issues that
[34:24.660 --> 34:32.460]  are really inherent within the iOS Bluetooth low energy stack. This is a lot of fun. I've
[34:32.460 --> 34:37.960]  done some private talks where I've actually attacked entire rooms full of people and
[34:37.960 --> 34:44.820]  AirPods are popping up on everyone's phone. So it's a lot of fun. But it can also be scary for
[34:44.820 --> 34:49.720]  Apple users to see that you can get that much interaction with their devices just through
[34:49.720 --> 34:58.620]  Bluetooth low energy. The Blueborn scanner, it was deprecated, but I've actually seen it back
[34:58.620 --> 35:05.980]  on the store or on the Play Store. And I still download it and still use it. But the likelihood
[35:05.980 --> 35:10.800]  that you're going to find a device that is actually still vulnerable or pops up as vulnerable
[35:10.800 --> 35:18.060]  is going to be highly unlikely at this point. Most manufacturers have patched or updated things
[35:18.060 --> 35:24.760]  against this. So it used to be a couple of years ago, you could walk into a Best Buy,
[35:24.760 --> 35:31.180]  run this Blueborn scanner, and almost every TV, every display TV that they had on, smart display
[35:31.180 --> 35:38.260]  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:50.040]  You know, those are different stories. But as far as I know,
[35:50.040 --> 35:54.220]  Blueborn is pretty much patched up and is no longer a risk.
[35:56.340 --> 36:03.020]  So a few challenges that we run into in Bluetooth low energy, as far as security
[36:03.020 --> 36:12.000]  researcher challenges. Most of the modern connections are encrypted. So they're hard
[36:12.000 --> 36:17.820]  to see from the outside. So unless there is a companion application on Android that I can use
[36:17.820 --> 36:24.080]  the Android debug bridge on, it's very hard to reverse commands. You know, the Ubertooth can
[36:24.080 --> 36:28.660]  follow connections, but it can't see inside of those connections that are encrypted.
[36:28.680 --> 36:35.600]  Crackle is largely ineffective anymore for breaking pins. So you know, good luck breaking
[36:35.600 --> 36:44.340]  pins. I know that there has been some research done in attacking the entropy levels of the pins
[36:44.340 --> 36:52.480]  that are generated. So that's kind of been a potential. But as far as I know, there isn't a
[36:52.480 --> 36:59.690]  reliable way of breaking pairing pins at this point. 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:14.890]  So a few approaches to BLE. Sniff the broadcast traffic. So look from the outside in first.
[37:14.890 --> 37:21.610]  Is it encrypted? What can you see, basically? What are they leaking? What could you potentially do
[37:21.610 --> 37:28.430]  without any kind of interaction with the device? Is there any kind of information leak?
[37:28.430 --> 37:34.210]  Are there any issues with configuration? Yeah, that sort of thing.
[37:35.930 --> 37:43.230]  The next step would be to look from the inside out using something like Android Debug Bridge
[37:43.230 --> 37:50.630]  and looking at the unencrypted packets that are coming in. So Android Debug Bridge allows you to
[37:50.630 --> 37:55.850]  look at the Bluetooth Low Energy packets once they've crossed over the HCI threshold. So
[37:56.570 --> 38:02.490]  they've been stripped of the encryption layer and you can actually see the commands that are
[38:02.490 --> 38:09.570]  getting sent over the wire. Attempt out of app connection. So just try to, you know, use nrf
[38:09.570 --> 38:17.210]  connect. Connect to a device. See if you can create a paired or a bonded session. And then
[38:17.210 --> 38:22.790]  just start fuzzing values and see what interaction you get. Sometimes, you know, you'll get devices
[38:22.790 --> 38:28.490]  to lock out. Sometimes you'll get devices to actually do what they're supposed to. Sometimes
[38:28.490 --> 38:36.090]  you hit the trigger. And then the next thing is to spoof a device or check for cloning protections
[38:36.090 --> 38:41.630]  within the application itself. So these are kind of the four things that I really look for
[38:41.630 --> 38:48.130]  in a pen test. So hopefully that helps you kind of frame and contextualize what we're
[38:48.130 --> 38:54.510]  going to look at here in a second. So let's get into some hands-on stuff.
[38:56.170 --> 39:07.110]  So short list of equipment. The Nordic Thingy 52. Bluefruit LE. The LG M150. The Samsung S20
[39:07.110 --> 39:13.290]  I'll be using as the victim. But I will also be showing you the screens that the attacker would
[39:13.290 --> 39:20.030]  see on that phone. It's just kind of a technology and display matter at this point. So
[39:21.510 --> 39:26.310]  and then we'll of course be using NRF Connect. We'll be using the Thingy app,
[39:26.310 --> 39:31.650]  then the Bluefruit Connect application. We'll also be using ADB and Wireshark.
[39:31.650 --> 39:37.150]  For an external scan, we're going to start with Ubertooth. And we're going to go through the
[39:37.150 --> 39:46.110]  setup. I just set this up on my computer. If you go to the GitHub page and go to their wiki
[39:46.110 --> 39:52.750]  for the Ubertooth, there are really good setup instructions. You just go line by line. I didn't
[39:52.750 --> 39:58.930]  have any issues on the newest version of Kali, so hopefully you don't. 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:22.990]  So let me get the phone hooked up here. We are going to launch ADB. So we would launch by using
[40:22.990 --> 40:31.350]  ADB start server. Mine's already started, but we'll just hit it again. And then we use ADB
[40:31.350 --> 40:38.750]  devices. And you can see our LG M150 is right there. 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:53.470]  We go over to Wireshark, which I already have started. And we can see that we have this BT
[40:53.470 --> 41:02.750]  Snoop interface that's opened up here. Now, it's important to note that the LG M150 has to be
[41:02.750 --> 41:11.250]  running Android version 7. So I just tried this a second ago with a different LG that I have,
[41:11.250 --> 41:16.850]  it's running version 6, and it does not open up the BT Snoop. So you'll have to actually update
[41:16.850 --> 41:23.290]  the version of Android. Luckily, we have pre-recorded videos this time, so I can go in
[41:23.290 --> 41:30.530]  and actually edit out some of that stuff. So we have our BT Snoop file here. Let's go ahead and
[41:30.530 --> 41:38.590]  start the sniffer. So our sniffer is now running from our phone. And so I have the phone connected
[41:38.590 --> 41:50.090]  here. And what we can do is start trying to connect to devices. So for instance, I have this
[41:50.090 --> 41:58.350]  thingy 52 on the desk here. 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:14.830]  So we can see I'm going to connect to the thingy device here, and you'll see the packets start to
[42:14.830 --> 42:26.290]  change. We can create a connection to our thingy 52 using the thingy connect app.
[42:27.170 --> 42:34.290]  And now that I'm connected, I'm actually reading data from this device, from the thingy 52,
[42:34.290 --> 42:43.550]  onto my phone. So I can do things like play sounds.
[42:48.780 --> 42:57.700]  Now that's as I'm pressing here, you hear the sound on the thingy 52. So those commands are
[42:57.700 --> 43:04.020]  coming through the GAT services. Commands are being written from our phone to the GAT services
[43:04.020 --> 43:10.500]  that are being offered on the thingy 52. So since we have this hooked up in an internal fashion and
[43:10.500 --> 43:16.460]  we can see these packets, we can actually see what commands are controlling what. So if I hit this
[43:16.460 --> 43:31.610]  tone, we can see that there are packets coming across. Send write here. And this is the value
[43:31.610 --> 43:38.330]  that's being written to that GAT service. So let's try a different key.
[43:40.610 --> 43:48.770]  Okay, let's see if that value has changed. You can see it's changed to an 8, from a 5 to an 8.
[43:56.110 --> 44:02.710]  I would also suspect that 1 is the on and off, right? So the first write is the on, the second
[44:02.710 --> 44:12.110]  write is the off. You can see all Fs in the middle there, and then we see all 0s in the middle.
[44:12.610 --> 44:22.970]  All Fs, all 0s. Okay, so that's a pretty basic look at how we see commands and we're able to reverse
[44:22.970 --> 44:30.750]  command values that come across the wire internally. So how do we actually then interact
[44:30.750 --> 44:37.650]  with or take this information and use it to then test if there is any unauthorized
[44:38.470 --> 44:44.710]  access to the GAT services, or if we can get any interaction to the device from an
[44:45.430 --> 44:56.050]  unauthenticated source. So let me bring up the screen here. And I'm going to use my
[44:56.550 --> 45:04.030]  victim device here, or in this case my attacking device, to actually seek out the
[45:05.970 --> 45:15.230]  Thingy52 here over nrfconnect. So this would constitute an out-of-application connection.
[45:15.230 --> 45:22.570]  Since the Thingy52 has an application that controls all of the interactions,
[45:22.570 --> 45:28.130]  using an application like nrfconnect to directly interact with the GAT services
[45:28.130 --> 45:34.610]  would be considered an out-of-app interaction. So let me scan.
[45:41.550 --> 45:50.750]  So we have this thing here. That's my Thingy52. We'll go ahead and connect to that.
[45:52.530 --> 45:59.550]  And so you can see right off the bat we have a connection, but it's not bonded. You'll also
[45:59.550 --> 46:06.410]  notice up here in the right-hand corner is the DFU button. That will actually allow us to push
[46:07.150 --> 46:13.630]  firmware updates over the air. So not all devices, and most consumer devices will be locked down
[46:13.630 --> 46:22.970]  from this, but not all devices will have this. But if you do see this, this would constitute a
[46:22.970 --> 46:30.250]  fairly major vulnerability in this device, especially since we have a short-term connection,
[46:30.250 --> 46:34.890]  since there hasn't been long-term key information passed.
[46:34.890 --> 46:43.490]  Let's go ahead and open up our sound services. So when we were looking at the other screen here,
[46:43.490 --> 46:52.170]  let me go to Kali and phone. So when we were looking at the other commands that we captured
[46:52.170 --> 47:00.370]  from the internal, from the ADB capture, we saw our read and write commands. So those were being
[47:00.370 --> 47:08.810]  written to the handle 005B, and that was in the sound service. So let's look in the sound here.
[47:11.970 --> 47:19.370]  So if we open up the handle, we can see the full UUID there. Okay, so the thingy,
[47:19.370 --> 47:24.750]  speaker data characteristic, is what we saw being written to.
[47:26.150 --> 47:33.590]  So we can actually use this upload command, so we have write permissions to it, and we can use this
[47:33.590 --> 47:54.230]  value that we have here. So we have 8701FFF5A. So let's try and push this. This was a write command,
[47:54.230 --> 47:59.650]  so let's make sure that it's placed in command. You have the option between request or command,
[47:59.650 --> 48:06.090]  and this was sent as a command, X52. So we'll send it as a command, and we'll see if we can get
[48:06.610 --> 48:11.930]  any interaction here between our device and our attacking device.
[48:21.680 --> 48:30.080]  There it is. There it is. So we're now attacking from there, and just like I thought,
[48:30.080 --> 48:37.900]  so the all F command is the on command. So when we saw the write, that was the F. So we've sent
[48:37.900 --> 48:47.140]  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
[48:47.140 --> 49:03.220]  the off command. So that was 870100005A, and we send that as the command, and now it's off.
[49:03.220 --> 49:14.140]  So that is a very robust look at your basic GAT hacking. We abused an unauthenticated
[49:14.140 --> 49:20.740]  out of application connection to a device, our thingy 52 in this case,
[49:21.580 --> 49:28.540]  and we used a command that we reversed from other information into getting this interaction
[49:28.540 --> 49:36.560]  from an attacking device. So say this was something else. Say this was, I don't know,
[49:36.560 --> 49:40.480]  I don't know what kind of user device you would have, but say it had some purpose and you had
[49:40.480 --> 49:47.180]  this in your pocket, but it also made noise like that. And say somebody had reversed these commands
[49:47.180 --> 49:53.040]  and knew that these devices were vulnerable or that you could just arbitrarily write these
[49:53.040 --> 50:00.820]  commands to GAT services. So if you could walk around, identify where these devices were or when
[50:00.820 --> 50:04.820]  they were in proximity, you could automatically attack these devices so that everybody was
[50:05.360 --> 50:09.300]  walking around that had one of these in their pockets, they would automatically get this tone
[50:09.300 --> 50:13.720]  just going off in their pocket and they would have to shut the device off. So you can see where
[50:13.720 --> 50:21.560]  there is user impact and there's also a circumventing of protections that are in place
[50:21.560 --> 50:33.780]  for Bluetooth Low Energy. So successful GAT hacking there. Let's switch over to some more slides here.
[50:34.540 --> 50:39.920]  We used internal scan to reverse the Bluetooth commands that we saw coming across the wire and
[50:39.920 --> 50:47.400]  then we used that in and out of application attack. 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:15.940]  Say like spoofing a user device. Although I have seen that be, you know, a valid find where
[51:15.940 --> 51:22.960]  you can impersonate a legitimate user's phone and then there is some interaction with the device.
[51:22.960 --> 51:33.620]  Without the long-term keys that have been passed, there's a really... you have an uphill battle
[51:33.620 --> 51:41.740]  basically in trying to spoof a user device against a peripheral. So what we are going to do is spoof
[51:41.960 --> 51:50.760]  a peripheral device and we are going to watch the victim attach to it from their application
[51:51.320 --> 51:59.000]  and basically see all of the interactions that you normally would and you don't even know that
[51:59.000 --> 52:06.340]  you haven't connected to your device. Meanwhile, if we were to push this further, what that would
[52:06.340 --> 52:14.200]  enable me to do is get a bonded session with my target. So I would have those long-term keys
[52:14.200 --> 52:19.200]  exchange with my target and be able to then exploit that further. So I could either
[52:20.540 --> 52:29.240]  use some sort of proof of concept or have that deeper interaction with that user's device.
[52:30.660 --> 52:39.260]  So what we're going to do is we are going to be spoofing the Bluefruit LE. Push some of this
[52:39.260 --> 52:46.060]  stuff out of the way here for a second. We're going to be spoofing the Bluefruit LE. It's a
[52:46.060 --> 52:51.520]  real simple development tool. Adafruit has all these kinds of kits that you can use.
[52:51.520 --> 52:59.640]  This is intended for development. It's intended to learn with and to explore how Bluetooth
[53:00.100 --> 53:07.780]  development works. But why we're using it is because it has its own application and one
[53:07.780 --> 53:13.500]  that does not have spoofing protections in it. So it's easy to basically prove this
[53:13.500 --> 53:27.760]  cloning concept. So let me plug things in. You can see we've got power now there.
[53:30.300 --> 53:39.120]  Okay. So you can see that we have power there. The Bluefruit module is on.
[53:40.720 --> 53:50.640]  So what I'll be doing on my device is leveraging the scanner. So I'm going to scan for devices
[53:50.640 --> 54:02.640]  right now. Hopefully we see this Bluefruit pop up somewhere. Ah, there we go. Freaky Zen Sinister
[54:02.640 --> 54:11.780]  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:20.240]  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
[54:20.240 --> 54:27.260]  cloning the advertisement data now. So basically I'll be able to impersonate the Adafruit unit
[54:27.960 --> 54:32.400]  on the advertisement channels. So now that we've cloned it,
[54:32.400 --> 54:36.160]  what we can do is we can actually connect to the device.
[54:39.260 --> 54:47.620]  And we connect to it to get a return on the GAT services that are available. So now that we've
[54:47.620 --> 54:56.120]  connected to, we can go here up into the upper right-hand corner and we can go to clone device
[54:56.120 --> 55:02.860]  services. And you can see the little box popped up there and we've cloned the GAT services now.
[55:02.860 --> 55:08.640]  So we've cloned the advertisement profiles and we've cloned the GAT profiles. So now if we're
[55:08.640 --> 55:17.600]  able to turn these on, we're basically impersonating that device. So what we have to do is then go to
[55:17.600 --> 55:25.400]  the GAT server and we have to turn on the GAT server to mimic the Sun Hat. So there we have
[55:25.400 --> 55:37.680]  the GAT services turned on. And what we also have to do is go to our advertiser
[55:39.760 --> 55:50.900]  and we turn on the advertisement for the Freaky Zen Sinister Sun Hat. So now we are impersonating
[55:50.900 --> 56:03.820]  this device. And hopefully we will get a connection to our target device. So now that
[56:03.820 --> 56:10.360]  we've cloned all of the GAT services, what we have to do is go into the advertiser, turn on
[56:10.360 --> 56:17.280]  the advertiser for the Sinister Sun Hat, and then we also have to go in and change the name
[56:17.280 --> 56:22.880]  of the device. We're now advertising as a Spoofed Sun Hat. So
[56:23.820 --> 56:29.940]  we will update our scan here on the Adafruit LE app.
[56:32.540 --> 56:37.940]  And we can see the Phoenix 3. This is actually the name of the phone. So
[56:37.940 --> 56:43.980]  the name didn't update on the phone. So let's try and connect to it.
[56:45.940 --> 56:54.240]  And it allows us to connect to it as if it were the Sun Hat. So the Phoenix 3 is this phone. This
[56:54.240 --> 57:00.340]  is my attacker phone. So I've created a spoof from this phone and I've now got a connection
[57:00.340 --> 57:09.680]  in the application, in the Bluefruit Low Energy application. And from there, it's not giving us
[57:09.680 --> 57:13.960]  the right information because we're not getting returns on that. However, if I
[57:13.960 --> 57:23.760]  go to the server information here on my attacker, I can change things like my manufacturer string.
[57:24.380 --> 57:30.460]  This is an attacker. We can set that.
[57:31.840 --> 57:38.680]  Now we should be able to see that pop up there. You see now we've provided information on our
[57:38.680 --> 57:46.340]  attacker on the GAT service for the manufacturer name. So now the end user is seeing that if we
[57:46.340 --> 57:53.740]  had a device that had more functionality, we could potentially send information from this device.
[57:53.740 --> 58:01.820]  Say we spoofed a Thingy 52 and we spoofed or we sent temperature data out from there and this
[58:01.820 --> 58:09.820]  read temperature data. So think about that in a real world example where say a building is relying
[58:09.820 --> 58:17.920]  on Bluetooth Low Energy sensors to control HVAC. Say we are able to impersonate one of those sensors
[58:17.920 --> 58:25.640]  and then provide, you know, fake information to whatever is reading that temperature
[58:26.160 --> 58:31.100]  and then making the judgments on what should be done about that temperature. If we can then
[58:31.660 --> 58:35.940]  create a scenario where it thinks maybe the temperature is rising uncontrollably,
[58:35.940 --> 58:42.300]  maybe there's cooling systems or maybe it kicks on the fire suppression systems or something.
[58:42.300 --> 58:51.260]  So there is the risk of, you know, spoofing something and then providing information
[58:51.260 --> 58:58.020]  from that spoof. But I also have a connection now, a bonded connection to my target device
[58:58.020 --> 59:04.560]  that I could potentially exploit even further. So we just went through the basic pieces. We
[59:04.560 --> 59:10.620]  cloned the advertisement data. We changed our device name. We cloned the device services.
[59:11.780 --> 59:18.980]  We went through and turned on the advertiser and then we actually connected through
[59:19.600 --> 59:27.120]  and provided a spoof that our victim connected to. So I do want to introduce
[59:29.680 --> 59:42.240]  you to Hacknarr's BLE CTF. It runs on ESP32. Like I said, if you've ever been to any of my
[59:42.240 --> 59:49.420]  in-person training sessions, I generally give these out to as many people as I can. So I have,
[59:49.420 --> 59:55.600]  you know, like maybe 10 or 20 of these that I give out. But obviously since we are all
[59:56.280 --> 01:00:01.460]  all safe mode and social distancing, then I can't really give a bunch of these out.
[01:00:01.460 --> 01:00:08.000]  But they're like $10 and you can upload all the information yourself. And you can actually go
[01:00:08.000 --> 01:00:14.320]  through a BLE CTF and it's more of just interacting on GAT services. So what we went through earlier
[01:00:14.320 --> 01:00:22.700]  where we were doing the abusing of right privileges. So there are a bunch of challenges
[01:00:22.700 --> 01:00:29.660]  on there. Some of them are, you know, decoding MD5 or, you know, following certain instructions
[01:00:29.660 --> 01:00:36.020]  that you get back from the services. So if you have, you know, interest in exploring more on
[01:00:36.020 --> 01:00:43.320]  the GAT side, then I would definitely recommend checking out Hacknarr's BLE CTF. And of course,
[01:00:43.320 --> 01:00:48.540]  if you need help, feel free to reach out to me on Twitter or wherever.
[01:00:50.160 --> 01:00:57.100]  And so a few recommendations for just kind of the individual Bluetooth low energy user or your
[01:00:57.100 --> 01:01:06.340]  consumer. Keep your Bluetooth turned off unless you really need it. I know with the prevalence of
[01:01:06.340 --> 01:01:12.060]  Bluetooth low energy devices, I find my Bluetooth is being turned on more and more and kept on for
[01:01:12.060 --> 01:01:18.120]  longer and longer. So this might not be valid information in a few years. We may just always
[01:01:18.120 --> 01:01:27.560]  have to just deal with Bluetooth being on. Choose low traffic areas to do pin pairing sessions with.
[01:01:27.560 --> 01:01:37.240]  While it is fairly unlikely that there will be, you know, significant kind of leakage of keys
[01:01:37.640 --> 01:01:44.660]  or pins, there is the chance that that could happen. So you're better off to choose sort of
[01:01:44.880 --> 01:01:49.620]  a controlled RF space where you know there aren't going to be a lot of people eavesdropping.
[01:01:49.740 --> 01:01:58.940]  Generally, your home is a good option. Or, you know, an uninhabited part of your office, maybe.
[01:02:00.540 --> 01:02:08.860]  Also, be aware that like we saw with the Blue Fruit LE app, a lot of apps don't have spoofing
[01:02:08.860 --> 01:02:14.960]  protections. So you could very well be connecting to something that is not what you thought it was.
[01:02:14.960 --> 01:02:20.980]  And you've allowed an attacker to either provide you with false information or gain a bonded
[01:02:20.980 --> 01:02:26.340]  connection to your phone that they could then further abuse. And then I would also say that,
[01:02:26.340 --> 01:02:31.820]  you know, there are enough free tools out there that you could actually just start auditing all
[01:02:31.820 --> 01:02:37.960]  the Bluetooth devices around you and see, can I abuse GAT services? Can I create a spoof of this
[01:02:37.960 --> 01:02:44.500]  device? How does the application handle that? You might need two phones for that. But, yeah.
[01:02:44.500 --> 01:02:49.560]  And then, of course, if you want to get deeper into that, you know, maybe pick up a dedicated
[01:02:49.560 --> 01:02:57.080]  testing phone like an LG M150. Make sure it's running Android 7. So, yeah. Those are a few of
[01:02:57.080 --> 01:03:04.940]  my recommendations for consumers. As far as developers, I like to push out of band pairing
[01:03:04.940 --> 01:03:14.540]  options just because it pushes some of that very privileged and important information away from
[01:03:15.440 --> 01:03:22.480]  the channel that is being used for data. So, using something like NFC to actually pass
[01:03:22.480 --> 01:03:31.880]  long-term keys will increase the security of the Bluetooth data because... or the integrity of it
[01:03:31.880 --> 01:03:39.120]  because you don't have the risk of using basically an unprotected channel to pass
[01:03:39.120 --> 01:03:47.200]  keys to then protect it. So, you're using out of band practices. Don't focus solely on device
[01:03:47.200 --> 01:03:58.640]  security. You know, does your application have good spoofing protections? Is your app just
[01:03:58.640 --> 01:04:04.240]  looking for devices on name alone or is it looking, you know, for something deeper?
[01:04:04.960 --> 01:04:14.560]  What I like to, you know, dream and recommend is that, you know, that there be a remote server
[01:04:14.560 --> 01:04:21.040]  where you can actually validate the keys of a device before you ever connect to it through the
[01:04:21.040 --> 01:04:27.860]  cloud. So, say your cloud application would actually... or your application on your phone
[01:04:27.860 --> 01:04:33.360]  would have a connection to a cloud server somewhere. So, before you actually even start
[01:04:33.580 --> 01:04:40.400]  a connection with a device, that advertising data and that key or short-term key would be passed to
[01:04:40.980 --> 01:04:46.460]  your cloud and then validated. And if it's not valid, then obviously you wouldn't connect or
[01:04:46.460 --> 01:04:51.700]  you could blacklist it or something like that. So, that's what I tend to recommend.
[01:04:52.340 --> 01:05:01.720]  So, as far as further study, there are a number of Bluetooth researchers, but
[01:05:03.440 --> 01:05:10.320]  probably the one that I follow the most and the most enthusiastic is Jiska. I think I'm saying
[01:05:10.320 --> 01:05:20.920]  that right. But she is a... she's a security researcher and, yeah, an RF kind of wizard
[01:05:20.920 --> 01:05:31.380]  out of Europe. So, yeah, follow her on Twitter. She does a lot of talks all over the place.
[01:05:31.680 --> 01:05:38.120]  If you're looking for books, Hacking Exposed Wireless is amazing. I just went through the
[01:05:38.120 --> 01:05:45.580]  work for the GAWN and it's very, very similar. Obviously written by the same people. So,
[01:05:45.580 --> 01:05:49.520]  of course, there's going to be knowledge kind of overlap there.
[01:05:49.980 --> 01:05:56.660]  And if you're looking to get more on the hands-on side, then the Adafruit BlueFruit LE,
[01:05:57.460 --> 01:06:05.040]  the Thingy 52, ESP32s, and the UD100 Bluetooth USB adapter, which we didn't cover in this talk,
[01:06:05.040 --> 01:06:08.940]  is capable of doing more long-range stuff. So,
[01:06:08.940 --> 01:06:13.240]  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:28.600]  Okay. So, with the badge just on, if you just turn it on,
[01:06:28.600 --> 01:06:40.820]  you can see the Bluetooth mesh pop up in nRF Connect. But I'm not able to connect to it.
[01:06:49.400 --> 01:06:54.080]  So, I'm able to see the Anode XOR badge within nRF Connect,
[01:06:54.080 --> 01:07:00.560]  the Bluetooth mesh you see there, it's listed as such. And I can try to connect to it.
[01:07:01.280 --> 01:07:11.140]  And I have a connection to it, and it's giving me certain options. I've done some poking around
[01:07:11.140 --> 01:07:18.680]  on this side, but I haven't found a lot. 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:41.290]  within the SMP characteristic, you can actually do some interesting commands that have these
[01:07:41.290 --> 01:07:48.230]  right values here. But, you know, OS echo commands, so you can echo commands through Bluetooth into
[01:07:49.490 --> 01:07:53.430]  the operating system. I haven't got much interaction from that. I've tried the
[01:07:53.430 --> 01:07:58.910]  commands, but it hasn't really worked. But the one that I have seen that works very well
[01:07:58.910 --> 01:08:06.870]  is the reset command. So, I will switch over here. So, as soon as I hit the reset command,
[01:08:06.870 --> 01:08:15.150]  you'll see the badge turns off. We'll send that. And then the badge turns off.
[01:08:26.430 --> 01:08:30.530]  Last year, if you were at DEF CON and they were talking about the Bluetooth mesh,
[01:08:30.530 --> 01:08:37.030]  where you could attack other people's devices, you could connect to the badges,
[01:08:37.030 --> 01:08:42.970]  and then you could send these commands, you know, turn people's badges off, or,
[01:08:42.970 --> 01:08:48.610]  you know, make it do different things, send different commands. So, very cool,
[01:08:49.150 --> 01:08:55.290]  very cool kind of puzzle and interaction and tool for learning. So, if you have one of these badges,
[01:08:55.290 --> 01:09:02.330]  one of these Anonyx or DC27 badges, or I believe the one before that also had a Bluetooth mesh on
[01:09:02.330 --> 01:09:08.950]  it. But if you have one of these badges, they would be awesome to hack on. Yeah,
[01:09:08.950 --> 01:09:14.730]  so they have that Bluetooth component. That's going to wrap up my presentation.
[01:09:15.010 --> 01:09:20.230]  And I just want to thank you for spending the time with me today and learning about
[01:09:20.230 --> 01:09:25.870]  Bluetooth low-energy hacking. Hopefully, you learned something. Hopefully, you found something
[01:09:25.870 --> 01:09:30.130]  that maybe caught your interest and, you know, you're ready to explore the Bluetooth low-energy
[01:09:30.130 --> 01:09:38.090]  devices around you. Don't forget the further study that I pushed out in one of the last slides.
[01:09:38.090 --> 01:09:43.870]  And if you have any questions, feel free to reach out to me on Twitter or LinkedIn or anywhere,
[01:09:43.870 --> 01:09:50.210]  really. And I will try my best to get in touch with you. I know sometimes I don't do a great
[01:09:50.210 --> 01:09:57.530]  job. But, yeah, so thank you so much for joining me. And I hope you have a wonderful, wonderful
[01:09:57.530 --> 01:09:59.350]  DEF CON safe mode.