Unnamed: Thank you, thank you.
Welcome to our talk on, well, hacking of Bluetooth headphones, or more specifically,
maybe IOHA-based Bluetooth audio devices, because it's not only headphones.
Well, we are Frida and Dennis.
Our day jobs are penetration testers at ERW, a German security
company, and we do mostly technical assessments in the cosmos of IoT.
This means a lot of embedded systems assessments and a lot
of communication security that very often involves Bluetooth.
Bluetooth is also a subject that we have dedicated quite
some research time to over the last couple of years.
Then it's even longer than that.
Last year, we were lucky to be able to present some of
our findings on Bluetooth AuraCast right here at Congress.
The research we did back then was heavily focused on the Bluetooth specification itself.
We looked at this AuraCast feature, which is Bluetooth audio
broadcasting, and we found some things in the specification, but
at some point we felt like we were done with the theoretical work,
so to say, and wanted to look at some actual implementations.
Back then, not a lot of devices on the market actually supported AuraCast.
So we just Googled around for some devices that did support it, and we found a
transmitter that was able to broadcast audio via AuraCast, and a pair of matching
headphones that also supported AuraCast, both by a Taiwanese vendor, kind of random.
We bought them and started looking into them.
For us, that means we wanted to reverse engineer the firmware, look at the implementation.
This means our first step, our first goal was basically to get
hold of the firmware, to load it up in Ghidra and start reversing.
Well, what was kind of convenient in a way was that for the
transmitter, we already had a firmware update file that was freely
downloadable on the vendor's website, and we had to look at it.
Well, that wasn't too enlightening in the beginning. We saw some structure in it.
It seemed to have been a header, and then later on some compressed,
maybe even encrypted data, but we couldn't really make sense of
the file, and we certainly did not know how to unpack this blob.
We decided to start off with a little bit of more dynamic testing.
We had a look at a configuration tool for this transmitter, because
the way you configure this AuraCast transmitter is you have a
Windows tool, and you connect this transmitter via USB to your PC,
and then you fire up this tool, and you can configure some settings.
It's not a lot. You can set a name for your AuraCast stream.
You can set a password.
You can adjust the sampling rate, and what you
also can do is you can apply firmware updates.
The firmware update file we had, this is something you would apply using this tool.
To get started with a little bit of dynamic reverse engineering
of how this whole ecosystem of this tool and the transmitter
works, we fired up Wireshark and sniffed the USB traffic.
Then we connected to a device and started clicking around in the settings and
observe what was happening, and immediately we saw a lot of USB-HID traffic.
This is not very surprising to people who have dealt with these types of things
before, because USB-HID, albeit being actually meant for USB human interface devices,
is very often used as a casual generic transport for custom vendor protocols.
This is exactly what's happening in this case.
We have a custom protocol they implemented to configure
this transmitter, and they use HID as transport.
We also immediately saw some of the configuration messages produced
HID payloads that had human readable text in them, so we knew this
protocol is probably not encrypted, which is a good thing for us.
It might not be that complex.
We then also performed a firmware update and looked at the messages we saw then.
They were less enlightening than the clear text messages, because we
saw just some binary data in them, but once we stared at them a little
bit longer, we immediately recognized that the binary data that was
in there was actually just chunks of the firmware update file we had.
Well, that made a lot of sense, because obviously the
firmware needs to be transmitted to the transmitter.
By staring at the packet a little bit longer and comparing several of
the packets, we also saw that part of this USB-HID payload was also
a value that was incrementing steadily with every packet we sent.
If you see now, there is this small value in the beginning. It is increasing.
However, we figured it is probably not. Here we have three examples, basically.
As you can see, they increment steadily.
It is probably not a counter, because it does not start at zero.
Also, it does not increase by one in every step.
We figured it is probably something else, and we get the idea it might be an address.
This kind of fitted, because the distance between the
individual values of this increasing value perfectly matched
the offset of the binary data in our firmware update file.
This seemed to be some kind of address.
Also, by comparing these firmware update messages we saw to the
other messages that were transmitted when we changed configuration
values, we were able to pinpoint something that looked like a
command ID, because that was where all the messages differed.
In this case, this would be the 0204, which we guessed and we know now it's true.
You have to interpret in a little Indian way, so that this is 402 actually as a value.
Well, while we managed to make some sense on these messages, we made another discovery
that someone already wrote an unpacking tool for these types of firmware images.
There's not a lot of other info out there on these types of firmware,
but there is a tool that unpacks them, and we did just that.
That was great, because now we had some dynamic traces of
of this protocol, and also we had the firmware unpacked
and loaded in Ghidra, and we could start it reversing.
What we then found, because we could basically follow the flow of
USB messages, and we had an idea of at least a couple of messages,
what command IDs they had, we could find a command handler.
We found something that looked immediately exactly like this.
This is basically decompiler output from Ghidra that we cleaned up and where we
named some symbols, but this is basically exactly as it exists in the firmware.
In this switch case statement, you can see there is a function we
already named command write flash, because we figured that this is
the function that handles commands with this 402 command ID, and we
found that what it does is it writes data to the flash of the SOC.
We looked at the one below and figured, oh, it's a flash read command.
It does just the equivalent process, but it reads back memory.
That was cool, because remember, we wanted to research implementations, and for the
transmitter we had a firmware copy, but for the headphones, for example, we didn't.
Reading back the flash was very interesting to us.
We went ahead and implemented the protocol as far as we understood it, and
implemented the flash read command, and, well, connected the transmitter to our
computer, and we were perfectly able to dump flash via USB HRD, and that was great.
And what was even better?
It worked for the headphones, too, so we got a firmware we
didn't have before and were able to look at that as well.
Yeah, so at this point we were kind of hooked, and we wanted to know
more about this protocol and wanted to see what capabilities it could
give us and what things we can find out with that, and we kind of also
forgot about the initial goal of the research, so the AuraCast research
is still, like, somewhere on the to -do list, somewhere below, maybe.
But one of the biggest questions we asked ourselves
was, does this work with other more prestigious devices?
So, for example, these $9,000 Bose diamond-crusted earbuds, these actually
exist, but no, but the goal was to maybe find devices that people actually
use, like, from vendors that people know and devices that are sold.
So, what we did is we started to open up the two devices, the transmitter
and the headphones, and we looked inside to find out what they might have in
common, and we found that both are powered by an SOC by a vendor called Aroha.
Aroha is basically a Taiwanese vendor that sells
Bluetooth SOCs, specifically Bluetooth audio SOCs.
They also have SDKs and reference implementations for headphones,
and they have been getting very popular in the Bluetooth
audio space and also have, like, a very good quality there.
So, we started to look around for this vendor to see if we
could maybe find out what kind of devices they supply with SOCs.
So, the first thing you obviously do is Google, while it still
works, and one thing we found was some kind of news article that
mentioned Aroha in combination with Sony and some very specific
model where they apparently started to put in an Aroha chip.
So, that was the first vendor we found there.
Something else that we wanted to mention is 52audio.com.
So, essentially, it's like a teardown website, but specifically tailored for audio devices.
So, they just take apart lots of different audio devices and look what's inside.
Their focus is mostly just the audio parts of the device,
but it's just very helpful to find out other details.
So, in this case, we just went on the website, we searched for Aroha, and
then found a lot of different teardowns for a lot of different devices.
So, the quality of pictures is really great.
For example, this is a picture of a biodynamic earbud, and
this is a PCB that's part of the earbud that's inside an ear.
So, the quality is pretty good, and yeah, you can see it contains an Aroha chip.
Something else you'll find if you start Googling
Aroha is also this weird community of AirPod replicas.
So, apparently, there are a lot of AirPod replicas, and a lot of
people that are talking about it, and there's this subreddit, for
example, where people also take these apart and check what what SSCs
are inside, and yeah, apparently Aroha is also popular in that space.
That was also new to us. So, in the end, we found a few examples.
So, for example, Sony uses Aroha socks, Marshall uses them, Jabra uses them,
JBL, Biodynamic, and Bose, not for all of the devices, but for some of them.
That was interesting because those are names that we know, so we bought some.
So, that's a picture of part of our testing arsenal.
Also, stay tuned for our Headphone Review YouTube channel because
we've been playing with a lot of different headphones and earbuds.
No, of course not.
At the beginning, we only bought, like, one or
two devices that we could start out with testing.
Yeah, but, well, the next thing that happened was a big disappointment.
None of the devices we bought was using the USB port it had for anything but charging.
So, we plugged them in, we fired up our cool flash dumping tool, and
it did just nothing because those things don't show up as USB devices.
That was kind of sad, but then we got thinking,
well, those devices also need to be configured.
They need to be updated, hopefully, at some point. How do you do that?
Well, the answer, obviously, is there's an app for that.
We just went ahead and got some of those apps because
there's actually, like, a ton of apps because it's not one.
It's everyone has their own app, or some have even multiple
apps depending on which type of headphone you have.
We just downloaded a bunch of them and started decompiling reverse
engineering them, because that's just super convenient in comparison
to some bare metal reverse engineering of headphone firmware.
Pulling apart a Java-based Android app is, yeah, comparatively easy.
And, yeah, we did that.
We didn't learn a lot about specific messages that the protocol we knew
supports, but we learned it's actually this protocol exists in these apps.
It's obviously also possible to use this protocol via
Bluetooth, not only USB, and apparently, specifically, it
can be used over Bluetooth Classic and Bluetooth Low Energy.
And what we also found was a lot of symbols.
We found names for many, if not all, commands that exist, although we did
not know how those commands exactly looked like, but we had names for them.
And we also had a name for the protocol. It's called RACE.
We have no idea why it's called RACE.
It seems to be an acronym for something, but we don't know for what.
So, before we start to look into how the RACE protocol can be used
via Bluetooth, we want to give a short background on Bluetooth Classic
and Bluetooth Low Energy, just in the way it's relevant to this
RACE protocol and how it's used in the context of these headphones.
So, we have two types of Bluetooth, basically.
We have Bluetooth Classic and we have Bluetooth Low Energy.
The original Bluetooth Classic has been built for high data throughput, basically.
It's used for audio connections to this day, mostly.
Bluetooth Low Energy started off as something, well, with a smaller
energy footprint for energy efficiency, and now that's a bit changing.
It's just the newer Bluetooth. It also has audio capabilities now.
You can see AuraCast and stuff like that.
But there's also a couple of other differences between these two types of Bluetooth.
For Bluetooth Classic, every device has an address that is kind of like a MAC address.
It's not exactly the same, but it's kind of like that.
It's usually fixed for the whole lifetime of a device. It never changes.
For Bluetooth Low Energy, it's a bit different
for reasons I'm going to talk about in a minute.
We have the same kind of public addresses that stay fixed, but we
also have random addresses that periodically change, for example.
This is privacy reasons in Bluetooth Low Energy because
Bluetooth Low Energy devices are typically easily discoverable.
They advertise themselves, they advertise their presence, they
send periodic advertisements maybe, but some status data also.
And if you just run around with a Bluetooth Low Energy
device and it always advertises data with the same static
address, well, you have a tracking beacon in your pocket.
And to not have this issue, we have random addresses that would periodically change.
This is all very high level, right?
There's much more intricacy to this, but this should suffice for now.
For Bluetooth Classic, we don't have the same thing.
Bluetooth Classic devices do not advertise themselves.
You can usually only discover them when they're in the so-called discoverable
state, which is typically the case when you put a device in pairing mode.
Then it's in the discoverable state, you can find it, you can connect to it.
If it's not in this state, it's not straightforward
to find such a device or figure out its address.
You need at least bespoke hardware for that.
Also relevant for our context here, we have in both worlds, we have things that
are typically used or maybe even abused for the same things use BHID is used.
We have in Bluetooth Classic, we have RF-COM or maybe directly
L2-Cup, which is used to have this kind of a biggest channel
where you can just transmit your custom protocol over.
And in the Bluetooth Low Energy world, people typically use GAT for that.
And I'm going to explain both of those things a little bit
in a little bit more detail because RAIS does use them.
RAIS uses RF-COM for Bluetooth Classic.
RF-COM is, well, a Bluetooth protocol that emulates kind of a serial interface.
It has channels that are identified by their channel number
and you can just send serial data via these channels.
If you don't know a channel's number, you can discover a channel if you know its UUID.
There's a lookup protocol for that. It's called SDP.
And if you have a UUID, you can discover a
channel number and then transmit via this channel.
For RAIS specifically, there is, we saw like the UUIDs you're seeing here in the slide.
Every vendor has a bit of a different one, but yeah.
If you know the UUID, you can find the channel and speak RF-COM, the protocol.
For Bluetooth Low Energy, as I said, the equivalent would be GAT.
GAT is a bit different. It's a hierarchical structure.
We have services and services have one or more characteristics,
and these characteristics are basically the communication channels.
And they can be read from, written to, and you can subscribe to
them to receive any data that's coming in, or rather coming out.
They also have UUIDs, and you can find them by these UUIDs.
For GAT, we only saw two different UUIDs ever in use.
We saw like a general upstream IROHA one, and we saw one that was specific to Sony.
All other vendors use the IROHA upstream UUID.
If we now look at the RAIS protocol messages, we already saw
them earlier when we didn't really exactly know how they work.
Now we have the chance to reverse engineer firmware, compare
with the apps, and actually get to know how the protocol works.
And we found out it has a head. That's just one byte.
That's typically hex5 or hex15 when it's a firmware update message.
Then we have a type. That's a request or a response.
If you send a request, you have 5a.
If you get a response, it will have 5b in this place.
Then we have a 2 byte length field, and we have a command ID we saw earlier.
And depending on the command ID, we have a payload.
If we have a flash read message, we have a specific payload.
If we have a different message, we have a completely different payload.
The payload itself follows no global structure.
It's just the command handler for this specific
command ID just expects something in the payload.
And for a read flash command, for example, what we would have in
the payload is we would have a type byte that specifies whether we
want to read from the SoC's internal flash or an external flash.
We have a num that specifies how many flash pages we want to read.
We cannot say how many bytes, but entire flash pages.
And then an address from which we want to read.
Then a much more simple command would be the get build version of the command, for
example, that doesn't have any payload at all because it just has a command code.
And then, well, the response will be the build version of the firmware.
So we reversed like a ton of these command handlers.
We saw different commands being implemented in different firmware.
Some vendors had some commands that others didn't.
But in general, we figured out what the RAISE
protocol can do, what capabilities it provides.
You can read flash. You can write in a limited capacity.
You cannot write everywhere in the flash. You can read and write RAM.
And we're talking small ARM Cortex-M4 microcontrollers here.
That means if you can write to any memory address, you can
write to peripherals as well, or read from peripherals.
You can perform firmware update operations.
You can query the Bluetooth classic device address. That will be relevant later.
And you can read out the build version.
But there's many, many, many other commands for
configuring ANC equalizer settings, stuff like that.
That's not super interesting to us.
But these are the most interesting capabilities, we would say.
So we went ahead and built a tool.
To do the flash dumping we did earlier via USB, via Bluetooth now.
And we made it like transport agnostic. It supports USB.
It supports RF-com and it supports GAT.
And it did the flash dumping and it worked perfectly well.
We built it using Google's Python -based Bluetooth library, Bumble.
It's a terrific library with a horrible name.
Because if you try to Google anything about it, you'll find something about the dating app.
It's just super annoying. But the tool itself, it works very well.
And it gave us the capability to dump flash of
any headphones that supported these protocols.
We could basically just pair our headphones with the computer,
run the tool, dump the flash, reverse-engineer the firmware.
And we also had some limited debugging functionality by reading and writing RAM.
So that was super cool. It was a perfect setup for research, basically. Yeah.
But at this point, we realized something.
So during the testing, we always took the headphones, put
them in pairing mode, and connected them to our laptop.
But we realized that the pairing is actually not required.
So there's essentially no authentication.
And as a consequence, what this means is anyone in
Bluetooth range can just connect to our headphones.
Anyone in Bluetooth range can dump our headphones flash.
And anyone in Bluetooth range can read and write our headphones RAM.
And that's kind of bad. So let's see what you can do with that.
And so now we're actually performing live demos with Bluetooth on stage.
Let's hope that the demo gods are on our side.
So here on stage, we have our colleague Dennis. He's also called Dennis. Yeah.
And he's going to be...
So for a little bit of clarity, this is Demo Dennis, and this is Presenter Dennis.
If there's any confusion, I'm going to refer to them by that name. Okay.
So what you will be able to see here is the tool that Frida just mentioned.
And yeah, so essentially we have Dennis, target Dennis here, Demo Dennis.
And he's just going to start vibing to some music.
I think his favorite music probably.
And we're going to start with some things we mentioned before.
So for example, one thing we can do is we can try to read out the build version.
All right.
So we put a filter on this Bluetooth scanning so that it doesn't scan all of your devices.
So no worries. Right. So now we're connecting via Bluetooth Low Energy via GAT.
And we get this build version response.
This could be interesting for fingerprinting.
So we can see that it contains like a build date. It contains a vendor name.
It contains the name of the SOC that's inside the device.
And yeah, it could be useful for fingerprinting and identifying device.
Also, you'll see that the build date is a bit older.
We are not running the most recent firmware on that because
the demos wouldn't work with that anymore, partially.
But that's not that interesting. It's just a build version.
So whatever you now know the build version of his headphones.
But we also mentioned reading RAM.
And one thing we built here was another command which we call media info.
So what it first does, it will query the build version to identify the exact device.
And now it will read stuff from RAM.
And there you can see what Dennis is currently listening to.
And now it also makes sense why he's vibing so much. I understand.
Let's check it out. Okay, so we also mentioned reading the flash.
And for the first part of this research, we only used it to dump the firmware.
That wouldn't necessarily be interesting right now.
But the flash also contains other stuff.
So there's actually a partition table at the beginning of
the flash, and there are different partitions in the flash.
And there's one very interesting partition in this flash,
which is kind of like a configuration partition, NVDM.
And we can also try to dump this one.
You can imagine it like some kind of key value
store, specifically tailored to flash storage.
It does wear leveling and all that stuff. Yeah, it's Bluetooth. It will fail.
Bluetooth and Python. Don't worry. That's a pretty normal behavior. Yeah.
Okay, so now it's dumping the first part of the flash,
which contains this partition table that I've mentioned.
And our tool already says that the NVDM partition, the configuration
partition that we're interested in is usually partition number six.
So I'm dumping that.
And what's interesting to mention here is that, well, Dennis can
see it on the screen, but he wouldn't notice that this is happening.
The music is just running, and he can continue listening
to Taylor Swift without noticing anything going on.
Because what we're doing here is connecting to the device via Bluetooth
Low Energy, and the music he's listening to is via Bluetooth Classic.
Most of the devices do not actually support multiple
connections via Bluetooth Classic, for example.
Some do, but not for audio.
But all of them basically work that way that the audio
connection is not disrupted if you use Bluetooth Low Energy.
All right. So this is the configuration partition.
And it's not important how it exactly works, but it's something like a key value store.
So you have a lot of keys and a lot of value stored in there.
Some have human readable names and some don't.
And there's one specific subset of configurations, the AB15.18, whatever.
And we can look inside that configuration part.
And what we'll find is something like a connection table.
So you can see here there's like a device name and Bluetooth address.
And this device name is Elephone, which is Demo Dennis' smartphone's name.
All right.
So this is all stuff that we did via Bluetooth Low Energy without him noticing.
There is also a different scenario that you can think of, because what we can
also do is connect to his device via Bluetooth Classic and do audio stuff.
So in order to do that, we first need to find out the Bluetooth Classic address.
And as Frida showed before, there's actually a raise command to do that.
It works much better if you're in a room alone.
Alone isn't strictly required, but I don't know. 2,000 people is a bit much. Okay.
We're going to talk about what we're using here later.
But essentially, what we can now do is establish an audio connection to his headphones.
So this is a different scenario.
This wouldn't work while he's listening to music, because if we establish
an audio connection to his headphones, then his music will drop.
And that's something he will probably notice.
But imagine a scenario where he's just standing around,
maybe talking to someone with his headphones around his neck.
And what we can do now is establish a Bluetooth Classic connection.
And now an audio connection. Yeah. Yeah. So this is Demodan is talking.
Hello, Hamburg. All right.
And with that, we can essentially build something like an eavesdropping attack.
So to summarize, what you can do with that is you can extract data.
We've shown that for runtime data, like the audio that's currently playing.
But you can also extract configuration data, like the connection table that we've shown.
You can do eavesdropping attacks, although that certainly depends on the
scenario, because the person will notice that the audio connection drops.
Something that you could also do that we didn't show
here is injecting code via the RAM write functionality.
We can overwrite functions that are stored in RAM and called.
However, that does require a lot of engineering effort.
And as you'll see by the end of this presentation, it's probably not necessary,
because that takes a lot of work, and you don't really gain a lot by that.
The only thing that could be interesting would be to
build something like a worm that automatically spreads.
We didn't do this for two reasons, because, well, firstly, it
might be dangerous, and also because it's just very hard to build.
And honestly, I'm not sure if I could do it.
But there's one thing that is very interesting, and that's basically what we call pivoting.
So if you think about how people are using headphones, they're usually
using them in combination with another device, like in most cases
a smartphone or a tablet or maybe a computer, any other device that
sends data to the headphones or that the headphones can control.
And at the center of this connection, there's usually something like a love
relationship, or if we put this a bit more scientifically or technically,
there's actually a cryptographic bond in form of a Bluetooth link key.
The Bluetooth link key is a shared secret that is established during pairing,
and it's the base for authentication and for encryption in that connection.
So what do people use headphones for mostly?
Well, obviously, audio content, like listening to music, listening
to podcasts, whatever, but also calls or maybe voice messages.
And the third purpose might be voice assistant, so maybe
some people also use them for Siri or Google Assistant.
The latter two are things that are covered by the Bluetooth hands-free profile.
Bluetooth profiles are essentially like a set of protocols that
define how devices should behave so that they work together.
And the hands-free profile, the HFP, is essentially used by headphones or
car head units to communicate with the device and exchange information.
What an HFP device can do with a smartphone is actually a lot.
There's call control.
For example, a headphone that implements the HFP protocol can answer
calls, can reject calls, can end calls, or can even dial numbers.
There are audio routing settings. It can also access caller information.
So who's currently calling will get the information.
It can get network information. So it can query the operator name.
And something very interesting, it can also get the subscriber number.
So the headphones can query the phone number of the phone that it's connected to.
And it can also trigger voice assistants like Siri and whatever.
It also can do some phone book access.
However, these are some weird non -standard AT commands that we saw
sometimes working with Android, but that would require permissions.
Okay, so let's get back to the cryptographic bond here.
The question is, what happens if we steal this link key?
And the answer is, we can essentially impersonate the headphones to the smartphone.
So we, as an attacker, in combination with the link key can pretend to be
the headphones, and the smartphone will think we are the actual headphones.
But what do we need for that?
So the first thing is the headphones address, because that is what we want to spoof.
That is what we want to pretend to be.
And this is essentially what our source address needs to be for this attack.
We also need the smartphone's Bluetooth address, because
that is what we want to establish a connection to.
And usually, modern smartphones are not in discoverable
state, so you cannot just get their Bluetooth classic address.
And most importantly, we need the shared link key between these devices.
So if you have carefully paid attention to the previous demo at the end,
we actually have all this information and can try to do that attack.
And that's what we're going to attempt now.
So in this case, Dennis is coming up again. However... Yeah, thank you.
However, you might notice one thing.
He doesn't have his headphones with him anymore. He only has his phone with him.
And that is because the information I just mentioned is something
we already dumped before in that configuration partition.
So everything we're doing now doesn't require the headphones anymore.
And it also means, essentially, it's not very specific to these vulnerable headphones.
In any case where you can get these three information,
like the headphone address, the link key, and the target
address, in any of these cases, you can do these attacks.
So the first thing we need to do is setting the device address.
And it's sort of similar to network interfaces.
So the device address should be something that is static and fixed,
but some Bluetooth controllers allow you to change that address.
And I have one here that's by CSR, and they have a
command where you can just change the Bluetooth address.
And that's the first thing we need to do.
And as we're impersonating the headphones, we need
to take the Bluetooth address of the headphones.
All right, there's a lot of errors, but yeah, it's Bluetooth, so that's expected.
But at the end it says done, so that means we now have step one.
We changed our address to the address of the headphones.
Now, the second thing is we're using a lot of tools from BTStack,
and we're going to quickly cover what BTStack is later on.
But we need to tell BTStack the tooling that we're using to use the link key.
And if we look back at the configuration partition,
we can see the rest of the information we require.
So this is the target address of Dennis's phone that
we're targeting, and the link key between these devices.
And essentially what we need to tell BTStack now is,
for this Bluetooth address, please use that link key.
Okay, I already prepared this luckily.
So yeah, essentially this is just the configuration that we're setting now.
And now we can use an implementation.
We're using an implementation by BTStack of the HFP
protocol to do exactly what I've shown on the slides here.
Okay, now I'm establishing a Bluetooth connection to Dennis's phone.
His phone will now think that the headphones are connected.
And you can see that the HFP protocol has already exchanged some information.
And at the bottom it also says Apple extension supported.
So you can see that this is an Apple smartphone.
So there are a lot of things we can do. We could, for example, trigger calls.
We can take calls. But one example that we can do is we can communicate with Siri.
So Siri has some sort of restrictions when the phone is locked.
In this case it was locked.
So we cannot just get the content of any SMS or we cannot read the notes.
So it has some sort of restrictions that might be different on Android.
But yeah, for Siri you cannot do that much.
However, something we're going to try now is
we're trying to steal Dennis's WhatsApp account.
So the first thing we need is his phone number.
And that's something we can just query.
So the HFP command for his phone number, and please
don't call it, will give us the phone number.
And now we can put that into WhatsApp. You could also look up.
It's way bigger there. Yeah. All right. So it will request a code.
And Dennis's phone will get the code. But there's also something else we can do.
And we can tell WhatsApp to call us.
And if you remember, we have audio routing and we can accept calls.
So in this case we just have to wait a minute.
We did have some cases where this is five minutes.
You need to press see more for the phone because we have this weird missed call thing.
I think I can do this one. Yeah. Okay. Try it. So let's see. Yeah.
So they apparently have sometimes have some rate limiting in there
where it takes five minutes until the first code was received.
But we can do one fun thing.
And we can essentially spam the accept call command via HFP.
If we just spam it, the call acceptance is quicker than the vibration of Dennis's phone.
So in this case, he will not realize that a call is going on.
And I hope that it works now.
And by the way, everything we're saying today about Dennis is probably not true.
So it's not his real phone number.
But I'm not going to comment on whether he actually listens to Taylor Swift.
Let's see what happens. Oh, that's not going to work. Yeah. Okay. Yeah. Okay.
So I will try to spam the accept call command.
It fails because there's no call, but I'm not sure what's happening now. Yeah.
To elaborate quickly, because if you saw... Okay.
I think I can shed some light on this. Someone called us. Thank you very much.
Yeah. Okay.
In all honesty, this is funny one time, but we're
taking a leap here by doing live Bluetooth demos.
And if you could just not do that, that would be cool. Okay.
So for this case, for this case, we prepared a video for that step. All right.
So while they're setting it up, I will just show you the video of what's happening.
So this is the same thing that I just tried now. I received the phone number.
This was from a different phone number.
If you try to call this one, nothing will happen. Um, please don't do it. Okay.
So that's the same dialogue. Um, except in this case, um, the code is requested.
We press, um, we didn't receive it. And then there's the one minute wait.
And we can just skip over that one minute wait.
So now it's 30 seconds, 17 seconds, four seconds.
And then you get a call and hopefully we have audio. What's up verification code.
Press six to receive your, what your verification
code is seven, six, eight, two, nine, nine.
Your verification code is seven, six, eight, two, nine, nine.
And with that, we've taken over the WhatsApp account. Okay. All right.
Um, so it works. Yeah. So now that's cool.
Um, we won't, we won't get all of Dennis's old messages because of WhatsApp's
end to end encryption, but we'll get future messages as you could see here.
Um, but we didn't want to stop here. We wanted to try something funny here.
cool. Um, we won't, we won't get all of Dennis's old messages because of WhatsApp's
here. Um, but we didn't want to
here. Um, and as you remember, we still have the phone
number and apparently you can just log into Amazon
with a phone number and your password, of course,
but you can also do sign in with code and then you
can send the code to WhatsApp and let's so right,
there it is. Nice. So now we're in Dennis's Amazon account. So if anyone needs something,
yeah, just hit me up. He already has some items.
Oh, he has something in his. Ah, all right. Oh,
okay. So he's trying to keep up with current topics. That's very good. Staying educated.
Nice. Okay. Um, yeah, to, to, uh, put some disclaimer on this demo, um, this is not a silent
attack. This is noisy. Um, this is basically
what the screen of Dennis's phone now looks like.
There's a message from Amazon, uh, with, with the
login code. There's three messages by WhatsApp
that say, Hey, there, someone requested a transfer
code. Hey, uh, here's the transfer code. And Hey,
your account has been transferred to a different
phone. So this is definitely not silent, but we
have to keep in mind the window of opportunity for
this attack is huge basically because we are not no
longer reliant on the headphones. We could perform this
attack at any time. We can wait until he goes to the
gym and puts his phone in locker. We can wait until
he sleeps on the train. I don't know. We can wait
until he sits in an exciting talk and doesn't look
at his phone, uh, stuff like that. So it's still,
we would say it's a viable attack, but, uh, we
are also open for creative other ideas. I mean,
the capabilities are clear. We can receive calls.
We cannot just access SMS. So that would be an easy
two-factor bypass. That would be cool. Um, we
cannot, cannot do that doing HFP, but we can receive
calls. So everywhere where there's, uh, verification
calls like WhatsApp, uh, you're basically screwed.
Now, um, Dennis promised that, uh, we're going to
say something about BTStack, which is a software we
were using for, for the demo we just did. And
the thing is, when we started doing these demos,
we needed, uh, reliable, um, hands-free connections.
We needed an audio connection that was stable, uh,
for the calls. And Bumble was just not cutting
it. Bumble is cool, but it's bleeding as research
tooling in Python. Um, yeah. BTStack is a rock -solid, uh, Bluetooth HostStack written in Z,
a C. And it works great. Um, we, we used it for
the demos. It was incredibly helpful. If you're
ever on the lookout for Bluetooth HostStack, you
might want to have a look at BTStack. We, we, uh,
yeah, we're grateful for it. So, uh, we talked a
lot about the issues. We talked about the impact of,
of the issues we found. Now, uh, we want to talk
a little bit about, um, the extent of it in the
ecosystem and what we did with these, uh, issues,
uh, once we discovered them. First of all, this is a
slide that tries to answer a question you probably
all have is my, are my headphones affected? This is
a question we can in no way answer exhaustively.
Um, these are all devices we at some point confirmed
to be vulnerable. So this is basically where we
started off. These devices are not all alike.
Some are basically less vulnerable. Some are only
affected by, by one of the issues. We basically
identified three issues. Broken pairing with Bluetooth
Classic, broken pairing with Bluetooth Low Energy,
and the RACE protocol itself with its enormous powerful capabilities. And some of these, uh,
headphones, for example, the Jabra device would be
notable, uh, was only basically affected by the, by,
by this powerful RACE protocol, but the pairing issues were absent because apparently Jabra
caught these issues in their internal testing or
something, um, they fixed it. Um, for most of the
other devices though, the, the, they are fully impacted
by all three vulnerabilities. So this was the state
when we started. Um, now basically half a year after,
uh, after in our initial publication and a little bit
more, uh, longer even after our, our, our disclosure
to the vendor, uh, the situation is to our best guess,
kind of like this. Jabra has definitely fixed. They
even mentioned all three CVEs that got assigned to
the issues. They transparently themselves disclosed
that like, I think five more models by them were
affected. We only confirmed it for one, um, Biodynamic
and Marshall both released updates that specifically
mentioned the issues we discovered and, and say they
fixed it. Um, TOEFL did something, some security
fixing. We don't really know if it concerns the
vulnerabilities we found, but we assume. Sony did,
yeah, for Sony, it's a mixed bag. They never communicated with us. We,
uh, we, we, um, we know that some of their devices
have fixed some of the issues, but we, uh, have no
update notices that specifically say they, they
addressed any of these things. They just handled it,
from our perspective, they handled it pretty poorly
by not being transparent, uh, about what's happening.
In any case, uh, this whole situation is not really, we can't really tackle it.
We, we, we can't, we don't have the resources and
the time to, to check all these patches. This is
just not management. We don't own all of these
devices. We just, some of them, we just got lent
by someone to check if they're vulnerable. Um, it's
not, we can, uh, something we can do. And this is also
a bit, um, due to this confusing situation of the
ecosystem that we were facing initially when we
tried to disclose the vulnerability, because we had
identified these SOCs that were vulnerable. They were by
Aeroha. Aeroha sells these SOCs to vendors, but
also to, to OAMs, who then sell them to vendors,
who then build countless products, who then are
being sold to countless customers. And for us,
it's basically, it was, we can search for these
products. We found some, as you saw, we found a
bunch of headphones and found them to be vulnerable.
We can talk to some of the vendors, but we cannot talk
to all, all of them. We have a lot of trouble to
reach OAMs because they are basically just one layer
apart from us. And so the most obvious solution
was go upstream, just talk to Aeroha directly,
directly, which is, of course, what we did. And
it, um, initially it looked very promising because
Aeroha has a great security page. They, they, um,
said they will respond in a maximum of three to five
business days to you. Um, they will actually handle all the things with the OAMs and, and
downstream vendors. They will do the communication.
They will ship patches within 90 days and they
communicate with everyone affected. They provide a
PGP key, um, and an email address. This was perfect.
So we merely went ahead and sent them a technical
report about the vulnerabilities and a list of all
devices we found to be vulnerable. Then for a month, nothing happened.
We tried to contact them in different ways. We, we
sent emails to different email addresses. We tried
a contact form. We didn't really get through. Uh,
so we informed them we're, we're going to talk to
some vendors downstream directly. And we did so,
um, we contacted Sony, Marshall and Biodynamic.
And of, of, of those three, only Biodynamic ever
talked to us. And the others just ghosted us.
Um, another month later, we suddenly got a response by Aeroha.
And it turned out they had some technical difficulties with their disclosure email address.
They never really, first never really got our emails. And then when they responded,
their responses didn't arrive, uh, at our site. And yeah, they, they, at their site,
they had serious technical troubles. Once that
these troubles were sorted out, communication with
them was, was stellar. Basically it was perfect. They,
they committed to fixing the, the issues immediately.
They, they very quickly came up with the remediation
plan. They, it took them, as you can see, like,
only two weeks basically to come up with a patch
and, and ship an updated SDK to all the customers.
So that, that all went pretty quickly. But four
weeks later, none of their customers, none of the
downstream vendors had managed to produce anything
like a patch. There was basically just silence in that
regard. We knew from Aeroha they shipped, uh, an
updated version, but we, we didn't hear anything
from the downstream vendors. So, 93 days after
our initial report, we did go public in a way,
but not with a lot of technical details, because we wanted to, uh, not to endanger anyone.
So, um, basically, uh, over, over the time, the, the,
the past half year, finally updates were rolling in,
and now we're at a point where we're confident
enough to say we can release the technical details,
details as you have seen, and we can also release
some tooling that enables you to check if your devices
are vulnerable. Right, so tooling, um, we made this
repository public a few minutes ago. Um, this is
essentially some, we don't have the time. This,
this essentially what we've shown in our demos, um,
and a bit more, and we had a few goals for this
tool. So, firstly, we wanted to enable people to
check their devices on their own. We did implement
a command that tries to automate this, but it's
difficult. There are sometimes technical nuances
that we just cannot do with an automated command,
so you can sort of, you sort of don't get false
positive. If the tool says it's vulnerable, it is, um,
but if it says it's not, then, yeah, we just cannot
guarantee this. Um, we also didn't want to do
weaponized tooling, so the only exploit, in a sense, you'll find is the media info command,
but it will only work with older, firmer versions.
Um, we just didn't want to give people, um, the tool
at hand where they can easily exploit people. And
one of the main motivations also was to release
tooling and documentation for further research. Um,
for example, for one part, um, that we didn't talk
about today, which is firmware updates. So, we
did re-implement the firmware update process. Um,
if you have a Sony device, you can get firmware from this repository that we linked there,
and then you can update the firmware. Uh, you
could also do downgrades, but I really wouldn't
recommend that because you will obviously want the
most recent version, um, for fixed vulnerabilities.
Um, we also worked on unpacking and repacking firmware
to modify it. Um, we currently don't recommend
trying that, um, because in the development process we brick two devices, so it's not yet
in a state that's, uh, that properly works. Um,
and we also, in the, the blog post and white paper,
um, put a sort of technical low barrier method to check your devices with a mobile app. So,
you can just install this app on your phone, and
then you can check whether your device is affected,
at least for the Bluetooth low energy part. Again,
it's not, um, it's not a technical guarantee,
but it's at least some way to check it. Okay, so
very quickly, um, some comments on how this should
be mitigated. We identified three different issues that got assigned three different CVEs,
and they should individually be addressed. The fairing
issues, the both pairing issues should be fixed,
and then the race protocol should be stripped
down to non-dangerous commands like configuring
equalizers and stuff like that. For the manufacturers, we,
yeah, I'll keep it short because we're running out of time,
but for the love of it, please do security assessments.
If you sell customers a $600 pair of headphones,
have someone look at it, please. Um, for users, we,
we unfortunately cannot give you super helpful advice.
Update your headphones, if you can. Um, maybe try
to check if the updated version is actually fixed.
If you are, if you are, if you feel you're really at risk
of these types of attacks, then use a cable-bound headphone.
Oh, and one thing you can do is remove pairings with Bluetooth devices you no longer use,
because they are potentially a danger to your phone. As closing thoughts, I want to say
we have smartphones that are now some of the most fortified
and hardened security, hardened platforms we have.
And this may be
something that sets off a bit of a shift that attacks on peripherals that have
some leverage into the smartphones become viable and become interesting to attackers.
Like, imagine Celebrite-like scenarios where even physical access is not out of question
and might be interesting. And we might see more of these types of things in the future
that target peripherals. So, before I leave you with
this final QR codes where you can find all the things
we released, I just want to spend like 10 seconds to
say, um, I'm really, really grateful I could be here
for this talk and give it, uh, because my life get
pretty crazy just the two weeks before this talk,
and I was basically completely out of order because,
well, family stuff. And if it weren't for Dennis,
I wouldn't have any slides to point to, and those
repos would be empty because there was a lot of last
minute preparation work to be done. And Dennis did
all that because I was not available, and I'm really,
really grateful for that. And if, please, and lastly, because this was crazy family stuff,
if my wife would not be at home pulling double
shifts, I would not be able to stand here at all.
So, thank you, Sina. Yeah, and check the white
paper, check the toolkit, check the blog post,
if you're too lazy to read the whole white paper.
Thank you very much for this talk. It was really,
really interesting. Um, we don't have any time
for a Q and A left, but I have a question. Um,
is there any place where, uh, the audience can meet
you and ask questions? Just outside? Is that fine?
I don't know. Huh? Where? Just outside. Okay,
outside, then. Thank you again. One last applause.
Thank you, Marla. Thanks, Marla. And thank you so much for the last one.