Federal agencies and businesses face growing exposure to wireless threats as modern devices introduce new cybersecurity attack vectors that traditional security tools cannot detect or control. To mitigate consumer and enterprise risks associated with IoT devices in no-phone zones, Bastille Networks’ wireless intrusion detection system identifies and quarantines unauthorized emitters and behavioral abnormalities before data breaches can occur. Explore real-world examples of how Bastille’s IoT security solution proactively defends mission-critical environments from covert emissions, unapproved device behavior and Wi-Fi deauthentication attacks.
Anthony Jimenez
Welcome back to Carahcast, the podcast from Carahsoft, the trusted government IT solutions provider. Subscribe to get the latest technology updates in the public sector. I'm Anthony Jimenez, your host from the Carahsoft production team.
On behalf of Bastille, we'd like to welcome you to today's podcast. We'll be joined by Bluetooth experts from the Defenders Initiative and Bastille as we dive into Bluetooth vulnerabilities, tracing the evolution from early pranks to sophisticated modern exploits. We'll cover attacks like blue snorfing, blue bugging, and look at modern ones like BLE spam, Google fast pair vulnerabilities, and more.
This is part one of a two-part series.
Adrian Sanabria
Welcome to the Wireless Threat Podcast series sponsored by Bastille Networks. I'm Adrian Sanabria and joining me is John Bundy. I am looking forward to this.
In the previous podcast that we did, we talked about the basics of Bluetooth and how Bluetooth works. I learned a lot that I didn't know. So if you missed that one, I would suggest you go check that one out.
A lot of that is going to help you to understand the vulnerabilities and the hacks that we're going to talk about in this episode and the next one. In this podcast series, we explore a new class of device or threat in each episode. As I said, it's all about Bluetooth across these three episodes, and we're going to help you understand the threat, walk through some real-life scenarios, maybe even do the occasional demo.
And ultimately, the goal is to answer the question, should you be worried about this? If you have any devices, threats, or attacks you want us to dissect on this podcast, please let us know in the comments. So we're going to talk about the vulnerabilities and then lean into the hacking side of things.
One of the things we found that I thought was really interesting when we covered the Bluetooth basics is that the Bluetooth SIG, the special interest group, is responsible for certifying devices on Bluetooth. They won't certify older specs on new devices because those specs have some permanent vulnerabilities or attacks that work for them. But it sounds like people will use the old Bluetooth anyway.
Maybe they just don't get the device certified. Do consumers really care or look for a little tiny logo out of 700 logos on the back of a box?
Jon Bundy
There's a lot going on there. So yeah, the Bluetooth SIG, the special interest group, is responsible for the specifications and they release or update. It's coming up close to a year now.
It was slow for a while. Bluetooth 4 came out in 2010, was it? And we're on Bluetooth 6.3 just coming out. They had two releases last year for 6.1 and 6.2. So they release these. They also release the testing standards. There's an acronym for it.
Then you have to pass the test. So you build to that test and make sure you can pass it. There's no security tests in that, by the way.
So that's something you want to- It's all functionality, maybe? All functionality. Do you meet this?
Are you compatible? Are you interoperable? Do you implement these correctly so that other devices can find you and connect to you?
But at the end of it, you get a certification. You pay dearly for that when you're certified and you can use the logo. But the SIG, they do deprecate older versions of the spec.
And there's a little bit of confusion about this. The spec started back in 1999 with 1.0. We're on 6.3 now. What does that mean?
Well, they kept building and building on the spec. So in 2010, we talked about how Bluetooth 4 came out. That introduced Bluetooth Low Energy.
Now you have two technical stacks. You have the Bluetooth Classic, which is called BREDR also, or Bluetooth Low Energy, which is the second stack that was introduced in Bluetooth 4 16 years ago. And they just keep building on that.
They add better security. They add more capabilities. And eventually, some things, there are vulnerabilities in the stack itself.
And they'll say, oh, that's bad. They'll issue an erratum, or they'll patch it to the next version of the spec. And at some point, they say, look, everybody, if you want to get certified, now you have to at least be compliant with Bluetooth 5, which still has a lot of stuff from the original ones built into it by default.
So you've got certification and a certain minimal level. But not everybody gets certified, like you said. You know, I picked up an inexpensive pair of AI glasses.
There's no Bluetooth logo on it. I sniffed around on it a little bit. And they say they support Bluetooth 6.
I'm like, oh, that's fantastic. That's more current than all these other expensive devices I have that still have Bluetooth 5 2, 5 3. And then I look at how it does security.
And it's still using security that was introduced in Bluetooth 2.1. It's not using the latest security. So, you know, they might say, let's not do that. But these devices, they don't care.
They're not certifying. There's no logo on it.
Adrian Sanabria
I just did a search for Bluetooth spec. I pulled up the page at Bluetooth.com. It looks like there's 100 specs.
There's less than that because it's every version of the spec. And I found the core specification. I found the 6.3 that you just mentioned. And I opened up that PDF. And it is just shy of 4,000 pages.
Jon Bundy
They're going to crack it soon. They're getting there.
Adrian Sanabria
The largest PDF I think I've ever opened in my life. And I was a pen tester.
Jon Bundy
It used to scare me when I had to go look at that. But I've been looking at these specs for so long now. I will say that they have organized it pretty well.
It's fairly well laid out. There's good examples in it. But as you can imagine, with the spec that large, almost 4,000 pages, there's probably some flaws in it.
And that is a topic that will keep coming up over and over again. In addition to the spec, the core spec you found, there's profiles. There's those other hundreds of documents.
Say, well, if you want to do Bluetooth low energy audio, here's three or four or five other documents that you also need to understand and implement. So it's not just the core spec. There's, like you said, dozens or hundreds of other applicable documents to follow.
So that brings up a second area where you can have concerns is implementation about flaws in the spec and then ambiguities implementing the spec by the vendors. And these lead to some vulnerabilities later on.
Adrian Sanabria
Let's jump into some of the vulnerabilities here. So first off, when we were preparing for this, I was kind of thinking through all the places you could have Bluetooth vulnerabilities. Surely I've got a device on my desk I can use as a prop.
Yeah, sure. It could be my iPhone or it could be, I don't even know if this has Bluetooth in it. I've got this weird thing running PicoClaw on it.
But it could be in the device itself. It could be in the firmware of the device. I've got a pair of headphones or something like that.
Even those tiny earbuds, there's software that runs on AirPods. So you could have a vulnerability in there. You could have the vulnerability in the SDK that Apple uses to write that code for it.
I don't know if they have their own implementation or if they use somebody else's SDK. For the sake of walking through this, let's say that they use the SDK from Nordic or something like that. And then the protocol itself, that 4,000 page document that explains how the protocol works.
There could be a vulnerability in there. And then the Bluetooth stack on the device that you're connecting to. So Windows, my iPhone, my Mac.
So there's the receiving end.
Jon Bundy
Yeah. Did I miss anything there? Yeah.
I mean, as you can imagine, with a spec this large, we talked about billions of devices being released. Some are certified. Some are not certified.
The vendors that make these, they depend on other companies that actually make the Bluetooth chip itself, which has an SDK. If you start from the flaw in the vulnerability, so you start with the specs, there's flaws in the specs that lead to vulnerabilities. Then the chip makers that implement it, they might implement something incorrectly leading to a flaw in the chip or their SDK that they then pass along to the vendors that build from that.
The vendors either use the default examples because they're not Bluetooth experts. They've got other things to focus on. So they'll just implement whatever code they can to get it to work that comes from that SDK in the chipset, the chip builder.
And from that, then you have all of these things, flaws in how they pair, which is how they connect and establish identity and get the connection. The different protocols now that we remember, 26 years of development, different versions of the protocols, two different tech stacks. You can downgrade because the Bluetooth SIG wants these things to be interoperable as much as possible.
You don't want to just start making devices not work. You still got these old devices.
Adrian Sanabria
It's got to be backwards compatible.
Jon Bundy
Yes. You might downgrade. You might come along as an attacker and say, well, I can only do this old stuff.
Adrian Sanabria
Yeah.
Jon Bundy
I don't want to, but I'll do it.
Adrian Sanabria
I have to troubleshoot stuff every now and then. One thing you said is really interesting. When we did the smart glasses, I remember we tried that app that's supposed to tell somebody who's using metaglasses around you.
And it only worked when I first turned it on and then it was quiet afterwards. So were you talking about like the, like there's all these different phases of using Bluetooth. Like there's the first time connection.
The first time you connect a device to a phone, it's doing some things. It's only going to do once. So if the vulnerability is in that, that's going to be harder for an attacker to leverage because they only get one chance to do that.
When you first connect a new device and then when you turn the device, okay, well, and then I was thinking when you first turn the device on, it does some stuff that it only does when it makes that connection. And then when it's maintaining the connection, maybe you don't have that opportunity anymore. The point being, there's all these phases of interaction with a Bluetooth device that would require you to be kind of lucky if you're looking to hack something, it seems like.
Jon Bundy
Yeah. Getting into the hacking a little bit, it is difficult because it is a proximity protocol. You can't be miles away in general.
You need to be somewhat close in order to do it. And they're all at these phases and there's frequency hopping. And you should probably refer back to the previous episode to understand the fundamentals.
But during that first connection, like you said, yes and no. There's some interesting things about Bluetooth and how we've used it over time that kind of make us humans susceptible to these flaws. So what happens when your Bluetooth keyboard doesn't work?
Do you troubleshoot it? Or do you just forget the connection and repair it?
Adrian Sanabria
Yeah, that. Or turn it off and back on.
Jon Bundy
Yeah. You'll try to turn it on, turn it back, turn it off, turn it on. Good old IT crowd, right?
But then if it doesn't work, like that's it. I've exhausted the extent of my Bluetooth troubleshooting. Just going to forget the device, put it back in parent mode and you're back to step one.
So as an attacker, maybe you're going to try to interfere with that connection and cause demolished service so that the person gets back to that initial mode. So there are ways to get back to those modes, even though they are fleeting. Like you said, it's a one time in theory event that happens very quickly.
It's hard to observe, but you can force human behavior to kind of get back.
Adrian Sanabria
Yeah, it's a good point. Like it's something we use a lot in hacking or downgrade attacks. Maybe if you need it in a specific state, there's some kind of denial of service, some kind of way that you can force someone to do that.
Jon Bundy
Yeah, great from the pairing, there's vulnerabilities and that's a susceptible point in that life cycle. And then you're right, as devices first are turned on from the factory, they behave in one way. Then after they connect parent bond with a second device, they might act in a different way.
But if you're dedicated enough, you can try to force those different modes or hunt them down and exploit them.
Adrian Sanabria
So do you have some examples of some notable vulnerabilities?
Jon Bundy
Yeah, this was fun. I went back through time from the start of the spec. We've all heard of some and I think some of these are going to ring a bell as we get through there.
So they were like the noble goal of, hey, let's replace this proprietary headset to my newfangled mobile phone. Let's go to wireless. And that was what drove Bluetooth.
And then the other interesting thing I find is they wanted to replace the serial connection, which was used for everything. There's no USB yet. So you serial connections in all sorts of different ports.
But what if they could do a wireless serial protocol? It's called RF-COM. And it's still one of the big protocols used in Bluetooth Classic today.
Good old serial connection.
Adrian Sanabria
I imagine it wasn't encrypted. It was just in there.
Jon Bundy
The encryption would be on top of that. And at first, yeah, what encryption? Yeah, encryption.
We don't need no stinking encryption. Nobody can hear this, right? So if we go back, they started with, hey, it's all about the mobile phone and headsets.
And one of the first things they did is what if we could exchange our contact information? Before that, you had to, what, call someone? Or maybe if you had IR, you could point the phone to each other.
And hopefully it would eventually get through.
Adrian Sanabria
Palm pilots. Yes, you would trade it using IR between your palms.
Jon Bundy
It really holds still. Wait, wait, wait. Here it goes.
But so Bluetooth has something called object exchange, OBEX. And so you can send the V card, which is a format for a contact that's been around for a while. Since the mid nineties, the V card format still used.
So you can exchange contact information. So you could use object exchange and push your contact to someone. Well, did the other person have to set up a connection or anything?
No, let's make it easy. So now just anyone could walk anywhere, find phones that were available, discoverable and send the card to them. Say, hey, you've just been bluejacked.
It's just a prank, right? Have you ever used this feature?
Adrian Sanabria
I've never used this feature.
Jon Bundy
No.
Adrian Sanabria
So you can just force a digital business card on somebody without their.
Jon Bundy
Yeah. Back in the, you know, 2008, then of course the spec evolved and they said, well, you know, maybe we should authenticate. Maybe consent's important.
Let's not just allow it to be open all the time. Maybe we should let the user decide when they want to receive these and maybe they could say yes or no. And, you know, things like that.
So evolution, right? It drove that. So that was just a prank.
There's blue snarfing. You might've heard about blue snarfing. Yes.
Same object exchange, but it turns out you could connect to a phone and pull things. So you could pull all their contacts. No authentication required.
Well, it was supposed to be required, but did they implement it? Probably not.
Adrian Sanabria
Implementation.
Jon Bundy
Oops, sorry, our bad. So they eventually, it really was an implementation flaw where the phone, you know, this is all new technology. They don't think of that when they're implementing.
You're like, wow, this is great. We can exchange things. What about the authentication guys?
Adrian Sanabria
Are you supposed to- We were worried about Y2K. We weren't thinking about that.
Jon Bundy
We got to make sure our dates are okay. Yeah. So you could just pull everything without any authentication.
That was bad. That was like 2003. Blue bugging was another classic one, 2004, where you could access the microphone and just listen, or you could call.
Adrian Sanabria
Oh man.
Jon Bundy
It uses the AT commands. Remember the AT commands for modems? Yes, I do.
Adrian Sanabria
I did internet tech support back in the late nineties, early 2000s.
Jon Bundy
Yeah, those are still around. I've used them for, I know cellular modems still use them. I'm not so sure with the Bluetooth radios, but at least back at that time, you could send AT commands to the Bluetooth radios and just take over the phone and do things over this hidden channel.
Was it hidden for long? No, it was a serial port that wasn't advertised. So those are some of the old classic ones.
And then they had some Bluetooth releases to address some of these vulnerabilities and things got quiet for a while. So about almost 10 years, it was really quiet from 2007 to 2017.
Adrian Sanabria
So was there a major spec revision around then? Was that like the move to three?
Jon Bundy
So Bluetooth 4 came out in 2010. That was a big one. So they had the second stack for Bluetooth Low Energy.
Adrian Sanabria
Yeah.
Jon Bundy
We had Bluetooth 3 come out. That one was kind of a dud. Yeah.
Actually, that's one of the few I know where they added a feature and then they pulled it out eight years later, nine years later. So you probably don't even know about it. But at one point they're like, man, we're really slow at transferring things wirelessly.
If we also used Wi-Fi to do file transfers, so they introduced a mode called high speed, and it would use the Wi-Fi radio to connect over Bluetooth and say, I'd like to share some data. But then they got rid of it. They're like, this is way too complicated.
Nobody uses it. The big one was in 2007 with Bluetooth 2.1 because they added secure symbol pairing. So they really beefed up the security in 2007.
And so that kind of slowed things down for a while. Before that, security was either low or non-existent. People could just abuse it.
The spec wasn't quite secure enough. So it was slow going to about 2017. And then instead of abusing the spec as much, like, man, the spec has gotten so complicated.
People are not doing a good job of implementing all the features that they should. Now, either there's a flaw that was overlooked in the spec, so they would still exploit that, or more likely the SDK for a chipset, so the software development kit that the Bluetooth chip vendor would provide with their chips, so you could build an application. That would have a flaw in it.
And so the end manufacturer is totally out of the loop. Like, if Sony's making headphones, they're relying on chips from like Aroha or MediaTek or Qualcomm or whatever. They just take that SDK and they follow the directions, build something, and lo and behold, there's a flaw in it.
And so it goes to Sony, JBL, it goes to everybody that uses that SDK in that function, they would get that flaw. Or the vendor itself would not do an implementation right. Maybe they'd leave security or wouldn't check things the way they should check.
That led to another set of vulnerabilities. One of the big ones was a knob attack, key negotiation of Bluetooth. This was really interesting.
You could say it's a flaw in the spec, and it depends, I guess, on who you are. If you're a security expert, you'd say it's a flaw in the spec. If you're the Bluetooth SIG, you'd say it's a design.
And what it was is the spec said, hey, when you negotiate a key, you can set the key size to be anywhere from one byte to 16 bytes. Well, one byte is 256 unique values, it goes from zero to 255. So that key with 256 guesses, you're going to have the key.
It doesn't take long to do that. And why did the spec allow it? Well, Bluetooth is meant to be low energy.
These are low powered IoT devices with batteries that are meant to last years with low power processors. And complex encryption really puts a drag on the battery. So therefore, it was in the spec.
Now the SIG did...
Adrian Sanabria
Battery's not going to last long when I'm brute forcing the key.
Jon Bundy
It doesn't take long to brute force it though. So it was a good buy. But the SIG did recognize it.
And shortly after it came out, they're like, okay, yeah, we're not going to allow that. And so it was actually officially fixed in the 5.2 spec in 2020. But remember we said they deprecated and they test to 5.0. They're still in a rat amount and to test themselves, make sure that you don't allow a one byte key anymore because that's bad. But think of all the old devices that are out there that aren't patched, that were never certified, aren't going to be certified. All the white label devices that they make them, they push them out and they're done. All the old devices that the big brands are like, well, we're not going to put an update out for our six-year-old device.
So there's still things that are probably vulnerable to these. So that was a big one, pretty recent. There's some spoofing attacks that are out there called bias Bluetooth impersonation attacks, where you can spoof and act like one of the devices and start a connection.
Then you can combine it with knob to crack the key and get past the encryption. When you combine that one byte key, so again, remember how you can force and downgrade. When you connect it, you say, I can only do one byte worth of key because I'm an old device, what was me?
And then it's up to that other device, the victim to say, well, I'm going to allow it or not. Newer devices won't allow it, but there's still this period of time where things haven't been patched. They're still out there.
Adrian Sanabria
I only have one byte.
Jon Bundy
Please sir, can you spare another byte? No, just one. And then so you combine that with other attacks to impersonate one of the devices in the connection and it's like in a downgrade attack and then you crack it and you really can take over.
These are complicated attacks. So, I mean, it sounds pretty easy, but we'll talk more about what it takes to do them later. So those are in the last five years, but now there's been some very interesting ones in the last few years.
I think everyone's heard of this, the VLE spam. You know, three years ago, where you use something like a flipper zero.
Adrian Sanabria
Somewhat famous by the flipper zero, right?
Jon Bundy
Exactly right. Yeah, that implemented it, but you can implement this with just a Bluetooth dongle. Yeah, sure.
There's an Android app for it. There's lots of ways to do it. You put it on a Raspberry Pi, like a Raspberry Pi zeros.
Adrian Sanabria
That's actually what's in this guy. This is a Raspberry Pi zero W in here.
Jon Bundy
Yeah. So there might be a little script that does it, a very simple script. But what it was, is it abused some of the convenience features that vendors implemented for pairing.
So we talked a little bit about this in the last episode about pairing. But when you want to connect to a Bluetooth device, let's say your phone, you want to connect your headphones. There's three phases you go through.
First, you connect and you just say, hey, stop advertising. Let's just talk, you and I. So they talk, they're connected.
Now, if you want to have encryption, you need to have keys. In order to get keys, you have to pair. So by pairing, you establish your identity.
There are ways to prove that you are who you are by showing a series of numbers on one device and you verify it. And then you go, oh, okay, I know now that I'm talking to you and not some other.
Adrian Sanabria
One, two, three, four, five, six, whatever your, what it calls a pin, right?
Jon Bundy
A pin or a pass key. Yeah, there's different flavors. And then after that, if you want to avoid pairing in the future, you bond, which simply means you save the keys.
And then the next time that you guys see each other, you connect and go, oh, let's skip right to the encryption phase. So we both have keys. We don't have to pair again.
Let's just verify that we are who we are with a little crypto. And then we'll go to encryption. We're all good.
We don't have to pair. That's the bonding phase. Now users can find Bluetooth pairing, a pain in the butt, right?
You got to find something, hit a button. Maybe you have to hold the button two seconds. Maybe you have to hit it three times.
You have to unfold them. Every device has its own little way to get to a pairing mode where it's ready to connect. Eventually you get there.
They're in pairing mode. So a lot of the vendors decided, this is a little hard for users. What if we just made it?
So when the device gets nearby your headphones, let's say within a meter, you get close enough. What if your phone just popped up a message and said, hey, these headphones are nearby. Would you like to pair?
Then the user could just say, yes. You don't have to deal with entering in numbers. You don't have to check the number to make sure it matches a different number that may or may not be present on the second device.
You don't have to fiddle around with holding the power button. And so Apple implements this with, I don't know if it's called fast pair with Apple. I think nearby devices and nearby actions is some of the protocol names they use.
Google implemented Google fast pair. Samsung has its own version for its earbuds and watches. And then Microsoft.
Adrian Sanabria
It just feels like magic, right? You know, like you're like, oh, wow, it's set up. That's it.
Like you take the earbuds out and it's like, hey, do you want to add this to this device? Yeah. But that does sometimes backfire because if somebody's sitting right next to you, it's asking them.
It might pop up there. It's annoying. Yeah.
Jon Bundy
But the interesting thing about it is all of those things, just leverage Bluetooth low energy protocol and advertising, which is how Bluetooth low energy devices indicate their presence, whether or not they're connectable and whatnot. So each vendor came up with its own different little payload and unique IDs in that advertisement that then their phones, their MacBooks and their laptops and their OS would recognize. And so I see it's not encrypted yet because remember you haven't connected paired or bonded.
It's just advertising in plain text. What if you as the attacker say, well, I'll just send a message. And that's what the flipper does.
And it sends it out so quickly and it changes to another device. Say, hey, I'm headphones. Hey, I'm a keyboard.
Hey, you know, I'm a Apple TV. Hey, I'm with this. It just keeps changing.
And then the user is spammed with, that's why it's called BLE spam. They're just spammed with these pop-ups to make their device almost unusable because they keep hitting cancel or no, or it goes away and it's replaced with another one. And it's just annoying.
So that was pretty, a famous attack. So I think everyone's heard about that. There were some related ones to that with the Apple.
They had nearby actions. Not only could you pair with things, but if you had an Apple TV, maybe you wanted to configure it or you had a new phone, you wanted to configure it. They had other nearby things that you could do.
If you're close by something, you'd get a different pop-up and you could do something. It turns out there was a flaw in the implementation and users could kind of overflow something and cause a crash and just cause the phone to reboot. So for a while, I think it was iOS 12.1 or 12.0 was vulnerable to just being rebooted or shut down or locked up.
Adrian Sanabria
Yes, I remember that. Yeah. And people did that in crowds, right?
Like at Defcon or something like that. That's madness. Yeah.
Jon Bundy
So the first one was a prank. This one was a little more serious and Apple eventually, within a few months, had patched it.
Adrian Sanabria
I think another thing we kind of skipped over. We started off in 1999 and it's just headsets, right? At some point, like I'm scrolling through these specifications and there's a fitness machine profile specification and there's a gaming audio profile and there's a global navigation satellite system profile and a health thermometer profile, carrying access profile, insulin delivery profile spec, right?
So now we're talking about a lot of different devices, industrial measurement device profile. So this is now touching businesses, healthcare, stuff that could really do harm potentially.
Jon Bundy
Yeah. And each one of those, it's its own little profile that you should implement. First of all, you have to write the profile correctly and securely.
Then it has to be implemented correctly and securely. And that has to be used correctly and securely. So lots of opportunities for issues.
And you can imagine some of those lesser used ones probably don't get the attention that they needed to be secure. So there's flaws coming up in those all the time when people look at them, but there's good news and bad news, right? So those profiles are generally protected by the main spec themselves, which has most of the security and authentication and all that good stuff.
Adrian Sanabria
Yeah. They're not completely on their own.
Jon Bundy
Yeah. So they just build on top of the spec, but still there are ways to have poor implementations that could cause problems. Absolutely.
There was a keyboard hack that was pretty severe in late 2023, early 2024 called Ion Keyboard that would allow users to mimic a keyboard, connect to the phone or computer, say, look, we were connected before and it just bypassed security and the computer would be like, OK, let's start talking. And then it's at that point, it's just a bad USB. You can send in whatever keystrokes you want.
It was their flaws in like basically the stack in most of the OSs and they're all vulnerable to this sort of, you just come in and say, yeah, we already connected. Don't worry about the keys. It's good.
So that was a bad one. That was patched pretty quick. Steeltooth, Breaktooth came out late last year.
This is an interesting one that abuses a vendor implementation of sleep. Sleep isn't really defined in the spec, but vendors want deep sleep. So they added on and said to save battery life as a keyboard, I'm going to go to sleep in 20 minutes.
You tell the computer, hey, I'm going to sleep. I'll be back. Well, somebody else can come in and say, hey, I'm back.
And the computer will be like, cool, I've been waiting for you. We already were encrypted. So let's not worry about any of that stuff.
Adrian Sanabria
Oh, I see.
Jon Bundy
Right. Because it was better implemented, it doesn't quite get the rigor. It should.
There are flaws.
Adrian Sanabria
I'm not sure you can do a whole lot with a mouse.
Jon Bundy
It's harder to see the monitor damage with a mouse. But as we know with the keywords, like you said, you can open up a PowerShell, a command prompt, a terminal, start typing in things, download things, be stealthy. You could try all sorts of things.
Adrian Sanabria
Effectively remote code execution.
Jon Bundy
And eventually, yeah, you get a backdoor remote code or you download malware or you just write it. You just type it in. It takes a little while.
You're blinding fast. And then another cool one that just came out was called WhisperPair. So we talked about how Google FatPair was implemented for convenience.
There you go. Those are vulnerable unless you patch them. I have not.
Okay. So those are Sony XM1000 or WH1000 XM4s. And they are vulnerable to this attack.
There was a patch put out last fall for them. And why isn't everything getting patched? Well, vendors have to care.
And they're going to make business decisions about what's good for the reputation versus what's going to cost too much money. So they're going to make decisions. There's also not a lot of press on these.
So there's not a lot of pressure. So Google implemented this FatPair to make it easy for devices to connect. And what happens is if you're using your headphones, you're connected via Bluetooth to your phone.
You're great. You're happy. An attacker can come in, discover that there's headsets there because they're still advertising.
Because they added this cool feature that said, hey, wouldn't it be nice if you could connect to two devices at once with your headphones?
Adrian Sanabria
Right.
Jon Bundy
And then the attacker just follows the protocol, does all the secure things, and is connected. Now it can hear the audio stream. It can hear the microphone and use it to listen.
So that one was pretty bad. And it's starting to be patched out now. And then the last one was there's an Aroha.
That's a chipset where they had a remote access control engine available. It was hidden. But people found out about it.
They connected. They could issue developer commands to the device and take them over. What kind of devices did this affect?
They were on everything. All devices because it's just a Aroha chip. And sometimes the manufacturers don't even know what they're using.
So they don't know that they're vulnerable.
Adrian Sanabria
It's the Bluetooth, the particular vendor's Bluetooth chip.
Jon Bundy
Yeah, like Sony sometimes uses them. Sometimes they'll use Qualcomm. Sometimes they'll use MediaTek.
But it depends on the version. If you develop a new device, you might pick a different chipset for some reason. And so Aroha had to fix their SDK and firmware.
So it disabled that. And then all of the vendors would have to pick that up and rebuild their firmwares and then push it out. So as you can imagine, it's hard to get this fixed because if you don't patch it or if you don't have a way to patch it or if the vendor doesn't care enough to rebuild it, it won't get fixed.
There's some highlights of Bluetooth vulnerabilities.
Adrian Sanabria
We are going to wrap there. Just a bit of a pause. And we're going to come back in the next episode and go over Bluetooth hacking.
So thanks again Bastille for sponsoring this. Check out Bastille.net forward slash blog for more information on wireless threats. Don't forget to leave us a comment.
This is the end of part one. We'll be right back with part two on Bluetooth hacking.
Anthony Jimenez
Please visit www.Carahsoft.com or email us at bastille@carahsoft.com. Have a great day.