Yes, okay. Thank you for the kind introduction, John.
Hello, DEF CON crowd, Car Hacking Village crowd,
anyone after the fact, if you happen to be watching this sometime in the future.
My name is Kamel. Today I'm going to be talking to you guys about Bluetooth in automotive.
So, quick introduction for myself.
This is just to make sure you believe that I'm, you know,
qualified to be talking about the things I'm speaking about.
So, I'm an automotive cybersecurity technology architect at WhiteMotion.
WhiteMotion is a little-known, is a very small subsidiary of Morelli,
the former Italian automotive OEM Magneti Morelli.
They merged with a Japanese automotive supplier called CalSonic Kansai a few years ago.
And since at the time, WhiteMotion was a subsidiary of CalSonic Kansai,
we're now fully owned by Morelli Corporation.
I'm based in Tokyo in Japan. I'm trilingual.
I speak English, Arabic, and Japanese.
I've been involved in the automotive cybersecurity industry for about three years now.
I've been on all sides of the table, including, you know, private consultant,
you know, trainer, red team, blue teamer, so on and so forth.
I've kind of, I've worn a lot of hats in the last few years because
auto cyber is a very new and, you know, expanding field and no one's, you know,
job is as well-defined as they might like to think it is.
I got involved in the community side of things a while back.
I was a big, I was an administrator on the ASRG board in Detroit,
and I started the ASRG chapter here in Japan.
ASRG, by the way, stands for Automotive Security Research Group.
It's a group that is, I believe we're sponsoring the Car Hacking 101 this year at DEF CON.
So we're kind of managing things through that.
But yeah, it's a group dedicated to sharing automotive security resources
and information and helping, you know, expand awareness for the industry
and help grow it as not only an industry for work and stuff, but also as a community.
So I consider myself a jack of some trades and a master of none.
I'm not especially good at anything that I do, I like to think, but I have a lot of interests.
So lately I've been doing a lot of Bluetooth stuff.
Bluetooth has kind of become my pet project, right?
Studying Bluetooth vulnerabilities and techniques for car hacking as it relates to what I do at work,
as well as things like RF, digital forensics and USB.
My other hobbies are listed down there and, you know, they're not incredibly interesting.
But the picture in the background, you might be able to see this is me.
And this was my team for the 2019 Car Hacking Village CTF.
So my team actually came in first place, we're Team Canucks, we're the best and no one is better than us.
And I think it's just worth saying, right, just more for the qualification.
But anyway, enough about me, enough of that boring stuff, let's get into the actual presentation.
So what is Bluetooth?
Bluetooth is a very common cable replacement technology.
It's found in virtually all smartphones, all computers.
And a lot of the wireless IoT devices worldwide use Bluetooth as their main mode of transportation.
Communication, right?
It operates in the 2.4 gigahertz frequency range, which is the same as some of the Wi-Fi standards, right?
The 802.11 standards.
And as a result, there's a lot of Wi-Fi chips that are bundled together with like a Bluetooth chip, right?
So some manufacturers that make both Wi-Fi and Bluetooth hardware,
they'll actually bundle those together because they're pretty similar from a physical frequency perspective, right?
Some of the more unique things about Bluetooth compared to Wi-Fi, though, is that it utilizes something called frequency hopping,
which makes it harder to monitor, right?
Which is something I'll talk a little bit more about when we get to why Bluetooth is such a hard technology to research from a security standpoint, right?
But I'm sure that at this point, you know, for most of you, Bluetooth is something you talk about in your everyday life, right?
Like if you're using AirPods, they're using Bluetooth, right?
If you connect your phone to your car stereo system, which, by the way, we'll be talking about, you're using Bluetooth, right?
So in automotive, Bluetooth is mostly used for, well, exactly what I mentioned earlier, right?
Connecting to your vehicle's stereo system, sharing your phone book with your car, right?
That's a source of confidential information, which is, of course, of interest from a security perspective.
But the main task delegated to Bluetooth is not, you know, a very high-impact one.
It's mostly just controlling your music, you know, hands-free phone calls, etc.
And, you know, things like your phone book access so that you can actually see who's calling you when you're on the road and you receive a text message.
You know, some cars will actually support text message integration, too, right?
So this is the basic use case for Bluetooth in automotive, right?
And this is probably common sense to a lot of you, but what might be less common sense is how the Bluetooth protocol is actually organized.
So I said Bluetooth protocol, but Bluetooth itself is actually a specification.
It's not one specific technology. It is a set of specifications maintained by a company, or rather, it's a group.
It's a group of companies called the Bluetooth Special Interest Group, right?
They manage the specification for Bluetooth, they publish the standard, and they kind of monitor how it's performing, you know, make updates to it whenever a new version of the technology comes out.
But at the end of the day, it's up to each individual manufacturer to actually implement the Bluetooth, you know, stack on their hardware however they like, right?
And so this is where we get to the big divide in the different protocols that make up Bluetooth, right?
So you can see on the screen here, I have the different protocols that make up Bluetooth split into a couple of categories.
We have the blue ones up here, the RFComm, right? Radio Frequency Communication, SDP, Service Discovery Protocol, L2Cap.
This is logical something. I don't remember what this stands for exactly, but it's one of the higher layer protocols, right?
And then down here, you have the ones in red, right? This is Device Manager, Link Manager, Baseband Resource Manager, Link Controller, and the PHY, right?
And then in the middle, you have the Host Controller Interface, right? Which begs the question, what does that mean, Host Controller Interface?
Well, I made this box here purple for a reason, right? So the ones on the top, they're blue, right?
These are controlled by the host, right? Your operating system. Your operating system will have its own Bluetooth stack.
And according to that Bluetooth stack, it operates in a certain way, right?
So for those of you who are familiar with Linux, BlueZ is one of the more common Bluetooth stacks running on most Linux distributions.
And it's made specifically for Linux, right?
But then the controller side, right? We have Host Controller Interface.
So the reason this whole architecture exists is because it makes it easier to interface with different hardware from the actual hardware manufacturers, right?
Because they kind of abstract away everything that happens down here through the Host Controller Interface,
the host doesn't need to worry too much about what's going on down here, right?
So these are controller side protocols, right?
And each one of these is going to be programmed a different way based on the actual manufacturer of the hardware itself.
And by the hardware, I'm not talking about your laptop manufacturer, I'm talking about the actual Bluetooth chip manufacturer, right?
So going over a short history of Bluetooth security, right?
When Bluetooth first came out in the early 2000, there were a lot of gimmicks that exploited like protocol level issues in early Bluetooth, right?
I would call these like... I call them gimmicks because they're kind of like, okay, the first time they designed it, they decided encryption wasn't important.
So they didn't include encryption, right? For certain things like that.
So a lot of these were fixed in 2007, when the Bluetooth 2.1 plus extended data rate update arrived, right?
This introduced mandatory encryption for connection based data, except for service discovery protocol.
And it introduced secure simple pairing, right?
So legacy pairing was the process by which Bluetooth devices connected before this.
The only way you could pair two devices was through inputting a pin, right?
So a four digit pin, right? So 0000 or 1234, right?
This sounds like a good enough way to do authentication for the connection process between two trusted devices.
But for some devices, right? Say, for example, a pair of cheap Bluetooth headphones you bought online, they don't have a user interface.
So you can't really pick the pin that the corresponding connecting cell phone is supposed to put in, right?
So they usually be hard coded with something like 0000 or 1234, right?
And this was kind of a bad system.
And so that's why they introduced secure simple pairing, which introduced a couple of more options for pairing your device.
So now they have passkey, you know, they still have the passkey input, but then they also have numerical comparison.
They also have out of band, right? Out of band pairing is essentially you pair through a different mechanism other than Bluetooth, right?
So you might have like NFC or something else, another technology entirely used to do the pairing.
But then the actual data transfer, et cetera, is done over Bluetooth.
And there's another one called just works, which is exactly what it sounds like.
And it needs to go, to be honest. It's essentially no authentication at all.
But that's for things like I mentioned earlier, things like headphones that don't have a user interface or like a keyboard or monitor where you can actually do a number comparison.
They have to have something in place to work. So they introduced just works.
But anyway, so after that happened, right, after the introduction of secure simple pairing,
sorry, I got a little bit sidetracked. There was a pretty long year, long period of about eight years where there wasn't a lot of research done on Bluetooth.
Right. So mostly old gimmicks didn't work anymore. Bluetooth low energy, which came out alongside Bluetooth 4.0, started out pretty insecure and was a pretty hot topic for research.
But eventually a lot of those got patched out. And I think nowadays, Bluetooth low energy is getting closer to traditional Bluetooth security grade.
Right. And so. What I mean by the traditional Bluetooth security grade is after all those protocol level bugs got, you know, hammered out,
it's not it wasn't as easy to do research of Bluetooth, because if you think about it in comparison to Wi-Fi, I made that comparison earlier because they're very physical.
Sorry, they're very similar from the physical perspective that they both occupy the 2.4 gigahertz space.
Bluetooth uses that frequency hopping, which makes it a little bit harder to analyze.
You can't buy a 10, 15 dollar Bluetooth sniffer online and just monitor Bluetooth traffic going through the air.
Right. Another thing. Sorry. So I have a couple of these listed. Right. These problems surrounding Bluetooth security research.
Right. So one of these one of the other problems, you know, I mentioned the earlier that it's not a specific technology.
It's a specification defined by the Bluetooth special interest group and that the implementations will vary based on the operating environments and the chip firmware implementations.
Right. And I also talked about how the frequency hopping means so you can't actually sniff it out of the air like you can with Wi-Fi.
There does exist equipment for that, but that's going to cost about twenty thousand dollars minimum.
Right. Like these are very high grade, like I would say, like government, military grade equipment.
You cannot be expected to buy this if you want to do research on Bluetooth. Right.
So and then what I mentioned before, I'm going to go back a couple of slides and show you the breakdown of the different the different protocols. Right.
It's not as easy to analyze the lower level protocols as it should be. Right.
Because if we think about this here. Right. So you have your your host layer protocols, right. RFCOM, STP and L2CAP.
And these are decently well explored and the host controller interface exists and you have the ability to log host controller interface data on all Linux and all Android platforms,
which I'll be showing later on in the presentation. But all of these red processes, all of these red protocols are essentially a black box.
And because they're going to be so different from manufacturer to manufacturer, you know, there's no real understanding of what's going on inside these chips. Right.
So that's another reason why security and Bluetooth is has been kind of on the down low for, you know, for a while, up until pretty recently. Right.
And, you know, I said the spec is very complicated. And that is a big part of it. Right.
Because, you know, there are certain parts of the Bluetooth specification that you wouldn't you wouldn't from a security perspective,
you wouldn't assume that somebody read this and said, yes, this is OK, and then put it into the spec.
And then it went undetected for, you know, since the birth of Bluetooth until last year, actually. Right.
The this scenario I'm talking about actually happened. A vulnerability was released that essentially disclosed the fact that any Bluetooth device,
when it's pairing with another device, it has the option to negotiate the entropy of the encryption keys used for the communication.
Right. OK, that's a sounds like a good idea from from one perspective. Right.
You have the option to if you have hardware that only supports, say, you know, a couple of bytes of entropy,
you can negotiate, say, OK, well, I can only support this much. So can you please lower the security of the communication?
Right. It's a compatibility thing. But the researchers that published the vulnerability found out that the minimum,
according to the Bluetooth specification, right, the minimum allowed entropy for this encryption was only one byte.
So they could forcibly, by modifying the firmware of one of their devices, they could negotiate down the connection,
you know, the encryption entropy of the connection they were making down to one byte of encryption. Right.
And one byte of encryption, one byte of entropy for encryption, sorry, is enough to essentially brute force in real time and monitor Bluetooth communications.
Right. If you have some some cheaper hardware, you don't need the twenty thousand dollar hardware.
You need some slightly less expensive hardware and you can actually sniff some of the packets, some of the packets out of the air. Right.
That vulnerability itself is pretty interesting. It's called NOB. Right. K-N-O-B. Right.
It's an acronym for key negotiation of Bluetooth. I'm not going to go too far in detail on that one because I have a couple more things I want to talk about.
But that is a good segue into the fact that recently there has been more of a look at Bluetooth security, especially from some labs out in Europe.
They have been putting out a lot of great research that I'll have linked to in the end of this demonstration.
But back to the automotive things. I'm kind of going in circles because there's a lot to talk about here.
But coming full circle to the automotive side of things, this is a diagram from a piece of research that was published by Tencent's Keen Security Labs.
They published this in March of 2020. So this is really cutting edge research.
Basically, there were some unpatched Bluetooth vulnerabilities on some Toyota vehicles that were in circulation that had been made outside of Japan, I want to say as early as 2016 or 2017.
Unpatched Blueborn led to daemon level access. For any of you that have followed Bluetooth security at all, you might have heard of Blueborn before.
Blueborn was a series of high profile Bluetooth vulnerabilities that were released, or I guess publicized, I believe in 2017 by Armist Labs.
That's the name of the lab that came up with these vulnerabilities.
It was essentially the ability to remotely execute code on any device that had Bluetooth enabled, even if the device wasn't in discoverable mode.
Discoverable mode is when you make your Bluetooth device visible for the intent of pairing with another device, you have to make it visible through discoverable mode just so that it's easier to find.
But they essentially showed that even without having to pair with the device, without the device being in discoverable mode, they could execute code on any device running Bluetooth remotely.
The scenario behind this disclosure that happened this year by Tekine Labs, they showed that through exploiting these unpatched vulnerabilities in these automotive head units inside these Toyota slash Lexus vehicles,
they were able to gain daemon level remote code execution because the Bluetooth service on the main board here,
this board here, this is a wiring, a logical diagram of the inside of that head unit.
This main board, which is running the Bluetooth service, was running Bluetooth at a pretty high privilege.
It was running it at a daemon level privilege.
So from there, they were actually able to get remote code execution, escalating privileges to root and establishing a Wi-Fi backdoor was the next thing they did.
So they made a Wi-Fi backdoor that allowed them to SSH back into it from a slightly longer range than Bluetooth allows, because Wi-Fi has a better operating range than Bluetooth does.
And through that, they were then able to make use of this main board's position inside the head unit to actually push updates to some of the other devices inside the head unit.
Specifically, this UConn board. This UConn board is connected to the CAN buses that the head unit itself is connected to.
And for those of you who are coming from an automotive background and just wanted to learn a little bit about Bluetooth, you know that being connected to the CAN bus is essentially getting access to the car's nervous system.
This is the in-vehicle, the controller area network, the in-vehicle network, along which a lot of the vehicle controls happen.
So long story short, I could talk about this particular bit of research for about an hour on its own.
But long story short, Bluetooth vulnerability led to further exploitation in the installation of a backdoor, which allowed the researchers to reflash this UConn board,
which, by the way, didn't have any checks on the software that was pushed to it for updating it, which is an entirely separate problem.
But we're then able to pivot from there onto both the CAN buses, the dedicated CAN bus and the infotainment CAN bus.
One of the lucky, I suppose, features of this entire scenario is that the CAN buses were pretty well segregated by this central gateway ECU.
So despite having this foothold, it was a big deal that the vehicle's steering, braking and acceleration were actually not affected.
I believe that is in part due to the central gateway in place and the fact that the different CAN buses were physically separated.
But anyway, that's a good, you know, just a good point to keep in mind. I'm going to double check and make sure there are no points I missed.
So, yeah, one of the things that they had to do the updating for was the ability to remove filters on arbitrary CAN message sending.
So that's the update that they actually sent to the UConn board was the ability to, they added the ability to send arbitrary CAN messages.
The full technical report isn't out, but it's hopefully scheduled to be released in 2021.
And it really, you know, anybody can say how well the rest of 2020 is going to go.
But anyway, we have now time for a live demo.
Right. So this is going to be a quick demo showing how to get started with Bluetooth in a Linux environment.
As always, when it comes to live demos, you know, something always goes wrong.
I actually have a automotive head unit that I was hoping to show a live interaction with it through Bluetooth.
But unfortunately, today it decided it didn't want to stay on.
So I'm going to be actually just showing how those Bluetooth tools work.
But I'm going to be using my cell phone as the target for analysis instead.
So I will switch over to my virtual machine and we'll head right back into the recording.
OK, so let me increase the font size here.
How's that look? A little bit bigger.
OK, so for any of you wondering, I'm running a stock Kali Linux distribution on this virtual machine right on my Windows desktop.
I don't have anything incredibly interesting installed from a Bluetooth perspective.
So all of the tools I'm going to be showing are actually available in Kali Linux, you know, as you know, fresh upon installation.
Right. So there's no there's no fancy software. It's no secret hardware I'm using.
I'm just using the Bluetooth chip inside my computer.
I want to give a disclaimer that sometimes things get a little bit strange if you use Bluetooth through a virtual machine.
The reason is because your virtual machine and the actual hardware and your actual host machine are sharing the same hardware, right?
The same Bluetooth hardware. So if I start connecting to something with my virtual machine, it will sometimes confuse the host machine.
And that's, you know, it's a little bit of an annoyance. But for the sake of today's educational demonstration, I think we can we can live with that.
Right. So the first thing I need to say, of course, a disclaimer that we're not I'm not going to be showing any, you know, vulnerabilities or exploits,
you know, that could lead to compromise of any systems. Right. I'm just going to be showing some basic surveillance tools and showing
what you can find very easily with the proper knowledge, with some, you know, open source software.
I'm not talking about anything incredibly expensive, you know, you know how it is. But, you know, it's important that we understand, you know,
the whole purpose behind all of this is that we understand what security risks might be present in the vehicles we operate.
You know, the other devices running Bluetooth, any privacy concerns that might be, you know, unaddressed otherwise. Right.
We don't learn these things in order to harm people. We use these techniques to arm ourselves with the appropriate knowledge to protect ourselves
from those who may do us harm or may mean us harm. Right. Anyway, so now that that's out of the way, let's get to the actual interesting stuff.
So the first thing I have to do is pseudo service Bluetooth start. Right. Put in my password and let that work. Right.
So a lot of times, I don't know why this is, but the Bluetooth service will actually be disabled by default. Right.
When you start up your device, you can actually change that in your settings so that it turns on by default.
But whether or not you want to do that is up to you. But in any case, the next thing we're going to do is check what Bluetooth controllers are available
on our machine. So that's done in Linux with hci-config. Right. That's host control interface configuration.
So this now here shows all of the devices I have, all the Bluetooth devices. I have just one right now.
I have my internal, you know, my laptop's Bluetooth chip. Right. Primary bus is USB. Depending on how your computer is built,
this might actually be something different like I2C. Right. So on and so forth. But the way mine is, is set up to be USB.
You can see the Bluetooth address of that Bluetooth chip. Right. Mine is currently up and it's running a PSCAN right now.
You can see a lot more information if you say pseudo hci-config-a. Right. We can see a little bit more now. Right.
So we see the same information as before. We have the Bluetooth address. We have the status. You know, it's up and it's running.
We see I haven't really sent very much, so I don't have any errors. You know, nothing incredibly special is happening here.
And most of this information isn't incredibly useful. Right. Like off, you know, off the bat, it's not incredibly useful.
I'll be perfectly honest. Right. But there are a couple of interesting things here. For example, the name. Right. Name is Kali.
This is how my device appears when I go into discoverable mode and another device kind of scans me or finds my device through its scan for Bluetooth devices,
because that's how Bluetooth devices find one another is they do a scan and any device that's discoverable in your area, you'll be able to pick up on it.
Right. I'll be showing that in just a quick second. So more than that, there is this class object here. Right.
So the class in this scenario is talking about the class of device. This, you know, this one, two, three, four, five, six, this three byte number or, you know,
hexadecimal number is actually used to identify what type of device belongs to this or this Bluetooth chip belongs to.
So the class will identify your device as a phone, as a laptop, as a desktop, as a pair of headphones, so on and so forth.
Sometimes this is a big deal, right, because if you think about a car, most cars aren't designed with the expectation that they'll connect to a laptop over Bluetooth.
It's not like the most outlandish thing to think in the world, but a lot of cars will actually refuse Bluetooth connections from devices that have their class identifying them as, you know, a laptop or a desktop computer.
So depending on the actual type of Bluetooth chip you're using, you might be able to change the class of device that your device actually identifies as, right?
So I don't believe I have the ability to do that with my internal laptop Bluetooth chip, right?
This is entirely a metric of the Bluetooth chip installed inside of my laptop. I'm actually going to go ahead and give it a shot and see if I can change it, right?
But the first thing I'll do is I'll show you guys, right, hci-config-hci0-class. This will give us a little bit more information about what my class is reporting, right?
Currently my class is set to 0c0000. This is actually, I think, because I'm using a virtual machine, right? It's just labeled as miscellaneous. It doesn't have a actual, you know, real class of device because this is a virtual machine.
But let's see if I can't change it, right? I'm actually doing this for the first time. I've never done this myself on this machine.
But if I go for sudo hci-config-hci0-class and I enter the class ID I want to set it as 0x5a020c. I know that's for cell phone.
Huh, let's see if that worked. Oh, there we go, right? So now I've successfully changed the class of device associated with my Bluetooth chip to that of a cell phone.
So see the device class here now shows phone, smartphone. So you might be familiar with this, like when you're trying to pair your phone to your car, right?
When you're searching for your car on your cell phone in the Bluetooth menu, it'll actually show like a little symbol next to each device, kind of giving you an idea of what kind of device that is, right?
Is it a pair of headphones? Is it like, it'll show like a laptop, like a little, you know, clipart laptop if it's an actual computer, right?
Or if it's another smartphone, it'll show a smartphone. So now when I scan or go discoverable with my laptop, it will display itself as though it was a smartphone, right?
This is useful for spoofing if you want to copy someone else's device and try and do some research on intercepting a, you know, pairing request, for example.
That's, you know, that's, you're getting very, very creative there at that point, right?
But, you know, I'm glad this worked out. This gives me something to show for. But anyway, on with the demonstration, right?
So the first, you know, in general, when you're doing a security test, the first thing you need to learn how to do is actually find what you're looking for, right?
And so that means you need to scan. So HCI tool, scan. Let me, so because like I mentioned before, the actual device I'm using, the, or I wanted to use the extracted head unit currently isn't working.
I'm going to actually turn Bluetooth on on my smartphone, and we're going to see if I can't find it by scanning.
So HCI tool, scan, scanning, scanning. I'm currently discoverable, so it should pop up any minute now. If it doesn't, I'll have to think fast because, well, okay.
Anyway, here we go. Okay, so this is my, these are my headphones, right? The name is in Japanese, so don't worry about it if you can't read it.
But this here is my cell phone, right? It shows my cell phone's name, right? This is the name that my cell phone broadcasts itself as over Bluetooth.
And this is my cell phone's Bluetooth address, right? I don't mind sharing this information. There's not a whole lot you can do with this.
But there is a little bit more than you think that you can do with this, right? And I'll show off some of the features of what's actually contained inside a Bluetooth address in just a second.
So this basic scan here gives us a very basic idea of what's around us. But if we say instead, this sudo hci-tool info, and then I copy this, right, and paste it into my command line,
it's requesting information from my phone. And now we have this whole little dump here. This dump is great, right? This is really, like, the first thing you want to do when you're testing a Bluetooth device.
And I'll show you why. The first thing it shows you is the OUI company, the Organizationally Unique Identifier company, Samsung Electronics, right?
I've been exposed. I'm using a Samsung phone, right? So you can find out what kind of phone I'm using without ever looking at my phone just by scanning my Bluetooth address, right?
The reason for this is because the first half of a Bluetooth ID is actually this OUI. It's the Organizationally Unique Identifier. This identifier identifies Samsung Electronics Corporation, right?
You see that DC748? It's right there, right? So all Samsung Galaxy S8 Pluses, I assume, will have this same Bluetooth address. I don't know if there are, like, sub-classifications for this, but, for example, what I mean by that is if there are...
How should I say? I don't know if there are, like, different, like, lots of different Samsung Electronics OUIs. Maybe there are. I don't know exactly, but, you know, it might be.
But the point is, the point is, there's actually a website, you know, where you can go and look up, I believe, on the Bluetooth Special Interest Group's website, they have a OUI lookup tool.
So you can find any OUI, right? If you find it, you know, just by war driving in the street or something, and you find a device, but it doesn't return here, you might be able to look it up on the website and find out what kind of device or what the manufacturer of that device was.
More interestingly here, right, is the actual LMP version of that device. So the LMP is the Link Manager Protocol.
This is showing the version of the Link Manager Protocol that I'm running, right? And this information might come in handy because, you know, obviously the more information you have on your target, the better.
You have more vectors by which to search for vulnerabilities or other ways to compromise the device, so on and so forth. So this is always a good bit of information to have because this will also give you information on what actual version of Bluetooth that device is running.
But going on, so here, the manufacturer tab here, this is usually a big deal. I want to see if I can't find another Bluetooth device. Let's actually scan this one instead because I think that Samsung decided to obfuscate this, so it's not actually showing what the manufacturer is.
But that manufacturer field is actually supposed to show the chip manufacturer. Okay, so this one isn't showing up either. This could be because I'm doing this on a virtual machine. I don't know why this is not showing an actual, how should I say, an actual company's name.
Normally this will show something like Broadcom or Cambridge, you know, like any of the actual chip manufacturers, their name will usually show up here. This is the first time I've seen the whole not assigned thing, but well, not everything can go right, right? I mean, we already lost the head unit I wanted to test on.
But anyway, now that we're here, we scan my headphones, you can see they're Bose Corporation. So any company that's making Bluetooth devices will usually have their own OUI registered, and you can find that out through here. I'm still not sure why this isn't showing up, but normally it does. I promise, I'm not making that up.
Let me try and add one more device onto my Bluetooth network and see if I can't scan it and introduce another test subject. So let's scan, scanning, scanning, scanning. I just turned on my Xbox controller, so let's see if I can't find this through the Bluetooth scanning here.
Aha! Okay, so we have this new address. Let's copy that and let's come over here and paste it. Let's see if we get lucky this time. So once again, not assigned. I don't know what's going on here. I suspect it might be an issue with the virtual machine setup, but that's surprising in and of itself.
Anyway, so I've kind of gone in a circle here, wasting some of your time. I apologize for that, but let's get on with the rest of the tools. So after scanning, I mentioned earlier that one of the protocols running on the host side of Bluetooth is the Service Discovery Protocol. So Service Discovery Protocol is the only connection-based protocol that doesn't require encryption.
And this is because what Service Discovery does is it advertises what services, what functionalities this Bluetooth device has. If it's a car, it's got to have phone book access, it's going to have audio-visual control. Each of these is its own set of functionalities that's dictated by those services. We call those services.
So the way you actually look at what services are available on a device, right, let's go back to my cell phone and copy this here. Copy that. So if we come back down here to the command line and we go sdptool, Service Discovery Protocol tool, browse. I just paste that. Let's see if we can't ask it for some information.
So sometimes it will refuse it based on the device. Sometimes you have to be paired with the device before it will actually concede any information to you. This is, the embarrassing part about this is that I wish I could tell you that all of these tricks worked 100% of the time, the first time, every time. Sometimes that's not, that doesn't actually work. Sometimes you have to just try it more than once.
Sometimes the device just doesn't want to talk to you unless you do a fully established connection, right? So it looks like my cell phone is being pretty stubborn today, but...
Okay, I might have to come back to this after I try and connect to it. Okay, yeah, so it looks like it's not working. But anyway, we're going to skip over Service Discovery Protocol and we're going to look at another part of Bluetooth in Linux, right? This is the last main thing I'm going to be showing. This is Bluetooth CTL.
Bluetooth CTL is short for Bluetooth Control. This is the agent that BlueZ, right? The Linux Bluetooth Protocol stack uses to manage connections and stuff. So when I enter this, you know, Bluetooth Control, I get this like special little different terminal here, right? It's like blue and I have my own separate set of commands, right? Each of these is its own talk in itself. So I can't really go too far into detail, but I'll show you all the important ones.
So the first one you want to show or I'd like to show is list, right? List will show me all of my controllers and it will tell you which one is the default controller, right? So this is important because sometimes you'll have more than one controller on your system. For example, if your controller, the internal controller, Bluetooth controller on your system doesn't allow you to change the class, for example, a USB, you know, an external one might allow you to do that, right? So you might have two and then you need to select which one you want to use. So in my case, I'm going to say select...
to a tab complete. Yeah, it's my only one. So it's kind of redundant to do that, but it's a good thing to know how to do, right?
So devices, what did my devices show? So I have my, these are not my AirPods. These are one of my friend's AirPods, but they're there. And if I go remove, will that remove them? Yes, it will.
So now I go back to devices. So now we're back to an empty list of devices, right? So devices is used to show all the, well, devices that you encountered, right?
So let's see if there's a part of this help screen here. It doesn't actually show. No, it does. Yeah, it lists the available devices. So anything that you've scanned, anything that you know is in your vicinity, right?
will appear in that devices list. I removed this because these aren't with me right now. So they're not actually around here.
But let's go ahead and turn on the scanning feature of Bluetooth control. It's a little bit different from the HCI control, but set scan on and then see what shows up, right?
So as before, we have my phone, right? It shows up as a new device, which is now populated in my devices tab. And from here, I can go ahead and connect to it.
Oh, there are my headphones again. Let's turn this scan off now because I've got my target device, right? It's already shown up here. There's no need to keep poking around and exposing my neighbor's Bluetooth devices.
But from here, we have a couple of more cool things we can try. We can say info DC, right? And see what we got. You know, through this interface here, we have a similar
dump of information that we got when we use HCI tool info. But here we can actually see the class of my cell phone, right? So it's showing that this is class 005A020C, right?
This is the same one that I changed my internal computer to. But it shows like, you know, it shows what the class of the opposing device is, which might be useful information.
And you know, icon is going to be a phone, not paired, not trusted, so on and so forth. And it does support legacy pairing, right? This might be a piece of information that you're interested in, right?
Depending on what you're looking for. So let's go ahead and actually try and pair with my phone. Let me just unlock this thing and get to the pairing process.
So if I say pair dc, tell me to pair with this. Okay, it says connected. Yes, so I have a connection. Okay, I have a added device. I'm going to hit OK on my phone.
Because I'm doing this in a virtual machine, this might not work as I hope it will, but it's something, right? Okay, so now I have shows Allendite here saying I'm connected to it.
I'm going to actually open a new tab and say SDP tool, browse this and see if this time we get a response from it. Hopefully this will work. If it doesn't, I'll have to include like a post recording, like screenshot of what the output of this tool looks like, but I'd like to be able to show it live if possible.
Yeah, I knew doing this on a virtual machine was a mistake.
Let's try this in sudo. I don't know if it got stalled somewhere before reaching the actual communication part because it's not showing the requesting information part that it was last time.
In my experience doing Bluetooth, a lot of times things just don't work. That's the second time, right? Like they just don't.
So as embarrassing as that is to admit, this is a genuine part of working with these tools, right?
So here, if I come here and I say paired devices.
Okay, so this didn't work.
Let's try pairing to it again.
Failed to pair in progress.
Hold on a second, failed to connect.
Operation now in progress.
Okay, everything is going wrong right now.
Okay, remove DC.
Okay, authentication canceled.
Okay, we have removed it.
No longer my devices.
Okay, so let's try this again from the top, right?
No matter what the demo shows you, this is what working with Bluetooth is actually like, right?
Sometimes it's just a real pain to deal with.
So we found it again.
Here it is.
I'm going to copy that.
I'm going to say pair this device.
Something to pair.
Yes.
Okay.
And...
So they're connected, but my phone is no longer receiving the request to pair, right?
You saw earlier how when I asked it to pair,
this was a Windows notification that showed up saying, like,
click here to set up your Bluetooth device.
That's because I'm running a virtual machine.
The host OS actually kind of grabs that connection
and is like, what would you like me to do with this, right?
So I think that I'm going to have to call it here for the Bluetooth demonstrations
just because of the limitations of my hardware right now.
Because I don't have an actual Linux machine that I can run this on bare metal, unfortunately.
But anyway, hopefully, you know, despite all of the hiccups I ran into along the way,
you were able to learn something about Bluetooth hands-on.
I'm going to switch back over to the PowerPoint
and just give you guys some resources to try out
and just some closing remarks before ending this talk.
So let's go over there real quick.
All right, we're back in the PowerPoint.
And the last thing I want to go over is a couple of tools
that I would suggest looking into for anyone who's new to Bluetooth
and wants to, you know, get into Bluetooth research, right?
This is a great time to be getting into it.
I'll point out why I feel that way in just a second.
But here listed on the screen are a couple of resources that I found very helpful in the past
and I think that are very relevant for modern day Bluetooth, you know, understanding, right?
So pull out the laser pointer.
So first and foremost, BlueZ, the Linux Bluetooth stack.
There are APIs available for both Python and C.
There is a guide online that I have linked in the next slide.
It's kind of old. Okay, it's not kind of old. It's really old.
But it still does a decently good job of explaining how to get started
writing your own very basic Bluetooth programs
and just running through that little... it's a pretty short textbook,
but running through it is a good way to just get more familiar with how Bluetooth works,
what the different components are, what kind of access to Bluetooth you have
through BlueZ on your Linux system.
I definitely recommend reading that book.
Like I said, it's linked in the next slide.
Bluetooth Stack Smasher, this is a fun little tool that was made a long time ago.
It's not likely going to get you an awesome Pwn of a head unit, right?
But it's essentially an L2 cap layer packet fuzzer, right?
It will just blast random data, the L2 cap layer at a given Bluetooth address of your choice.
It's very, very simplistic, but it has the ability to...
you can actually customize the frame, the data that it sends out to the target device.
So I've used it before with varying degrees of success,
but it is good to know that it exists.
It's about as good an over-the-air Bluetooth fuzzer as you can get.
SpoofTooth, this is another quite old one.
This was a project made for the express purpose of spoofing nearby Bluetooth devices.
So it makes it a lot easier to do what I was showing,
like with changing your class to copy a device.
And you can change your Bluetooth address too, if your Bluetooth chip allows that, of course.
So SpoofTooth kind of simplifies that process, of course, based on the allowances of your hardware.
And then InternalBlue, this is really a big deal.
I think that the lab doing this research here, this is the Simo lab somewhere.
I don't remember the country they're based out of, but it's somewhere in Europe.
And they are the ones who have really kick-started a lot of the recent Bluetooth research.
So I mentioned before the knob attack, right?
The key negotiation issue that was part of the Bluetooth protocol.
That was discovered because the researchers who found that were using this, this InternalBlue.
This is a framework for re-flashing Broadcom Bluetooth chips and essentially using them as very flexible Bluetooth adapters.
I won't go into too much detail because I'll be honest, I'm not really qualified to talk about it.
I don't want to say anything incorrect and have you all assume that I'm qualified at that level.
But it's really, really great.
You know, they have a lot of talks published.
I believe they published a couple more recently that I still have to watch.
But just going to their GitHub page will give you access to all of their papers and, you know, recorded presentations, so on and so forth.
And I think everyone interested in Bluetooth could definitely benefit from checking them out, right?
So speaking of the references page, this is my references page.
The Introduction to Bluetooth Programming is the blue Z one that I talked about before.
The internal blue GitHub, definitely a great resource for anyone.
Like I mentioned, the Knob Attack. This is if you wanted to read more about the Knob Attack or Blueborn, right?
These are the two vulnerabilities that I talked about to some degree of depth in this presentation.
And lastly, but not least, this is the link to Bluetooth Stack Smasher, the tool that I mentioned before for L2 cap fuzzing.
So hopefully you find any of these useful. Hopefully you learned something.
Hopefully this will help you out, maybe in the CTF for our virtual car hacking village.
And if you have any questions, of course, I'm always open to be emailed, right?
Just send me an email at kamel.ghali at white motion dot com.
I'm happy to provide you with these slides or any other resources if they're something that I own and I'm free to share.
But hopefully you have a great DEF CON and yeah, on to the next Car Hacking 101.