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