All right. We are here with our next QA session with Jiska and Francesco for the Spectra wireless,
new wireless escalation targets talk. Do you guys want to give yourself a little bit of an intro?
Jiska, do you want to start?
Yeah, okay, then I'll start. I'm a postdoc at TU Darmstadt in Germany at the Secure Mobile
Networking Lab, and I've been, yeah, recently working a lot with Bluetooth. Before, I've been
working also a bit on Wi-Fi and IoT devices and all sorts of wireless communication.
Hi, I'm Francesco Gringoli. I'm an assistant professor at the University of Brescia and
have been playing with wireless technologies in the last 15 years.
That's great. Thank you both. So, I mean, I'm going to start off with some a little bit simpler
questions. So, you talked a lot about this new vulnerability that's between the two cores.
Is this something that can be patched? It's hard to say. So, there are parts that
definitely are not patchable because they are for the performance improvements. So,
the stuff that goes, like, between the U-code that Francesco modified and the communication
with the serial interface on the Bluetooth side, this is something that you need, at least if you
don't want to lose performance. And this is also all in hardware, I guess. So, this is something,
like, in a future chip, it might be changed in a way that you can infer less information,
but it's probably not patchable in that sense or not easily patchable.
The shared RAM is something that they should remove, but I didn't see them remove it yet.
And I don't know if they can actually unmap it in the generation of chips or if this also needs
a new generation of chips. I didn't see the shared RAM actually being used anywhere. So,
that's the weird thing, right? The shared RAM exists. Yeah. So, it exists, but it's really
not being used for anything or at least for nothing that I could see. So, this is the thing
that they should remove, because it's the most dangerous part.
So, we got a question from Cooper Q, and this was actually something that I was interested in
as well. You mentioned LTE is on some of the same frequencies, and I know that there are some
all-in-one chips that include LTE in addition to their Bluetooth and wireless stacks. Have you
tried going through the LTE baseband or use the Bluetooth interface to get at the LTE radio?
Not yet. So, what we tried is we tried to see if this connection exists at all. And I can tell that
in the Cypress Bluetooth symbols, there's definitely symbols that are called LTE or MWS
something. And then I also took some logs on an iPhone and like iPhone 7 and newer. And on those
devices, what you can see is that there are HCI commands. So, that's from the operating system
Bluetooth daemon to the chip that include MWS, which is the configuration for the LTE coexistence.
So, they are definitely using it. I just didn't try to exploit it yet.
Cool. Fair enough. This one, this one's one I'm going to, I'm going to have to read verbatim
because it's a little out of context. I don't know what it was. In the talk, you mentioned
Frankenstein. Can you talk a little bit about it?
Yeah. So, that's another paper. So, actually, the main work of this is from Jan, who is not here,
but that's one of my former students. And he made some snapshotting for Bluetooth chips
of Broadcom and then also emulation. And the interesting part about this emulation is that
it includes thread switches and a virtual modem so that you can attach it to your Linux host and
you actually can start scanning for devices and get back random devices. So, you have like a full
stack emulation in that sense. And this is something that we are going to present next week
at USENIX security. The paper is already public. And also, the software is on GitHub since a while.
Cool. Could you send me links for that information? You can do it after the Q&A. I just want to be
able to drop it in track one for anyone that's interested in following up with that information.
So, anyone that's paying attention, if you want the extra information, the links to the
paper and everything else will be in the track one room as soon as this is over.
Okay, on to the next question. So, regarding the CVE-2019-15063 denial of service Bluetooth
Wi-Fi exploit, was that the specific one that you guys were working on? I don't remember CVE numbers
off the top of my head. Anyways, the question is, how are you manipulating the register that
results in crashes? Are you physically accessing the chipset? Or can this be done remotely?
Ah, so yeah, that's, so it's kind of two stages, right? So, you first need some remote code
execution, either on Wi-Fi or on Bluetooth. And then you could write to the register.
And what we do for debugging is actually, so for Bluetooth, when we modify Bluetooth,
then we have internal blue, which is a framework that supports the vendor specific commands from
Broadcom to manipulate the Bluetooth part. And for Wi-Fi, there's another thing next month,
I think Francesco can tell a bit more about next month. Yeah, it's a project that allows people to
do binary patching of the wireless driver, so that you can modify and then add functionalities.
But of course, this is not the remote execution, it's just for modifying the binary image
without having access to the source code, which is a proprietary. And this allows to modify both the
ARM, the ARM core, and also the U-code part that is the lowest part accessible in the hardware.
That's really cool. Is that a tool that is going to get released like
upcoming? Is that part of the Usenix talk? No, next one is, I just pasted it also in our
private chat, so you can copy it later. Next one is something, since when is it public? I don't
know, 2016, 17? Yeah. And the interesting part about next month is so next month was just built
to actually modify the Wi-Fi firmware without the intention to really hack it. So like,
more for sending arbitrary signals, turning your smartphone into an SDR. And the interesting part
here is that back then in 2017, actually, Google Project Zero and Itay Eisenstein used this
knowledge to dig a bit further into the Broadcom chips. So like Broadcom and stuff like this was
also not only but also based on next month, and also later work, they always use next month.
So that's a very interesting thing about this. And then for the Bluetooth stuff, we said like,
well, how do you guys go about researching phones, since for the most part, everything
seems to be closed source? They're asking to talk about like the research process,
like if you were going to try and exploit a new phone?
Ah, yeah, so that's, that's the thing. So the first part is, I mean, if you don't have,
already have a working over the air exploit, which is hard to get, especially if you don't
have the ROM of a device and so on, even if you had an exploit, like getting it working on a new
device would be hard. So usually we start with a rooted smartphone, or a jailbreak. Or, I mean,
also MacBooks have Broadcom chips. So and there you are already root. So it depends a bit. And
then we would dump the ROM. And the ROM, I mean, for Wi Fi and for Bluetooth, it's pretty much the
same. And for Wi Fi, the ROM also contains the U code. And the U code is the thing that runs in
the D11 core. So what Francesco modifies, and for me, it's more the Bluetooth firmware.
And then it's very annoying, because like the stuff is still without any symbols. And
especially Bluetooth also doesn't have any debug strings, the U code doesn't have any
debug strings, the Wi Fi firmware has a few debug strings. And since this is like,
so even the memory layout is somewhat unknown, and you need to get it and so on. And because of
this really horribly loads into IDA. So it really looks ugly. Yeah, fair. And I think Francesco,
for you, it's even the case that you get new instructions, right? Yes, for the U code,
there is no actually corresponds between the U code and the any known CPU. So we had to do this
reverse engineering for understanding the meaning of these instruction set, and then adding
instructions, because Broadcom, during the years, added new instructions. And yeah, the reason this
was very difficult, because it's not ARM that you compile or disassemble, but you have to develop
your own tool chain for this. So what helped is that Broadcom didn't change much the platform,
since they introduced it 15 years ago. So they are additionally adding instructions. And
also what helps is that the U code is very short is less than 64 kilobytes.
Have you either of you looked into any of the newer, like mesh Bluetooth protocols?
Bluetooth mesh. So a colleague of mine did that Lars, and he looked into the friendship together
with a few other people in our team. So it's so yeah, we did it in our team. But the mesh is not
really interesting. I mean, it's just using Bluetooth LE advertisements. So from a, at least
from a lower level perspective, it's nothing special. I mean, of course, implementations on
top are interesting then. But I mean, I do a lot of lower layer stuff. He just showed that the
encryption and so on in the, in the friendship of groups is broken, and Bluetooth SICK send funny
responses. Of course it is. Someone else is shouting out that a lot of your and related
work on BLE is also available as pre prints from YSEC 2020. And they also threw through a link in
there. I just wanted to shout that out. Francesco also has done stuff with Bluetooth sniffing,
right? You've built a Bluetooth sniffer. Yeah, this real time sniffer using a software defined
radio for capturing all the channels at the same time and GPU for decoding and brute forcing
lowest address part address and low energy session ID.
Yeah, I know that there's a lot of like kind of a wide range of like capabilities of SDR stuff. Is
there like a minimum requirements for the SDR hardware to do that level of sniffing and
for Bluetooth?
Well, if you have SDR that can sniff 80 megahertz is better. But for sniffing Bluetooth classic,
we demonstrated that it's enough to capture only 16 channels out of 80. Then you can also use one
of these cheap SDR like, like Hacker F or Blader F. So you do not need to buy a very expensive
1000 euro 80 megahertz, but you can buy one of these for 100 bucks.
That's awesome.
It should work.
Yeah, accessible hacking. It's nice.
Got one person asking, do you think Broadcom is relying a little bit too much on security
through obscurity with some of these chips?
I mean, so what you can actually see, and that's an interesting development. So
on the first bug that Jan discovered with Frankenstein is one in the enhancing viral
response. And when he submitted that one, they said, we already know the bug, and we just didn't
find it anywhere. And then I got like the newest Samsung Galaxy S10e and extracted the ROM. And
this one actually had a patch and it had a compile date of April 2018. And that also means like they
cannot change the ROM, so they cannot tell us lies about the ROM. And we reported it afterwards.
So that actually means they knew it before. But, and now that's the interesting part of the story.
They didn't patch it backwards in the older devices because it was not publicly known as
a bug and you could easily unroll the patches. Now, the thing is, they definitely increased
the security, I would say, after the bugs in 2017 were public. So, I mean, it took them a year
probably to do some pen testing and so on. But you can see like 2017, the first public incidents
happened. 2018, the first kind of secret patches make it into the firmware. And also they started
using like, I don't know, stuff like secondaries. They didn't have it before. So this is things that
now are going into the firmware. It's still not like super perfect and everything. It's still,
of course, closed source. But I mean, most firmware in wireless chips is closed source.
Yeah. So at least they are trying to work on it. And I think they are there on that,
like security by obscurity doesn't really work.
Fair enough. So someone is asking where people could find the source code for that Bluetooth
sniffer. Francesco, I think that's it. Yeah, I can send you. Yeah, I can send you a link.
If you send me a link, I will post that with everything else.
Yeah. And another one. Do you think a Bluetooth or Wi-Fi based worm is feasible in the wild or
interoperability between implementations too difficult to bridge?
So I think for Wi-Fi, it's hard because for most stuff, you need to actually join an access point
or something like this. But for Bluetooth, you have this master slave mode. So you can actually
have a device like a smartphone is usually capable of being master and slave. Some like
cheap devices, cheap IoT devices sometimes are only in slave mode and cannot do master.
But if you can be slave and master, then you can be part of this, let's say,
network and distribute the malware. And I think there is, let's say, a sufficient fraction of
popular devices. So it depends if it's in the operating system, then it would have to be like
compatible iPhones or something. And I mean, if you just there's not much diversity in iPhones.
So if you just take like the top selling iPhones or something that also would work on the chip
base. On Android, you have more diversity. But still, if you would say you just pick the top
Samsung and Galaxy, and maybe the pixels or something. Yeah, that could work. So Jan actually
uncovered vulnerability in the Android Bluetooth daemon. And that one would have been vulnerable.
And it was fixed in February. I mean, still, yeah. So you couldn't infect like 100% of devices.
Considering that you have your Bluetooth on and walk around and so on, that would be a threat.
So the reason why I think people wouldn't build it is how do you control it? Because then you need
to have some communication over the internet or something like how do you do like a command and
control server for Bluetooth form in a way that is like stealthy and really, I don't know. So I
think it's really more the bigger threat is definitely taking over nearby devices or like
hacking someone or like going next to an office train station somewhere where you know, like
interesting people are and taking over their devices. But I think even if it's vulnerable,
I think this is nothing that people would build. But I mean, maybe someone builds it someday.
So I won't build it because, well, I wouldn't. But I mean, maybe someone is crazy enough to do
this, right? It's just true. I mean, you could potentially just do it without a financial
motivation, just to see if it works or something. Yeah. So switching gears just a little bit.
Did you guys report this to vendors? Like how was how did that communication like turn out?
Was it positive? Was it negative? Was it? Tell me. Yeah, so the very first report about this
denial-of-service was in August last year. So that's like a year ago. And I think they didn't
really take it serious because it was just denial-of-service, right? And even if you have
denial-of-service with an operating system reboot, it's like nothing that you could really control,
right? So like writing FF to one register, it reboots. Okay. But who cares? Because you need
RCE first. It's just it's hard to control. And interestingly, in September that year,
the iOS 13 update came out, and it actually mentioned Jan, Francesco, and me. So and so
Jan was working mainly on Frankenstein. I also worked a bit on Frankenstein. And
the coexistence was what I did with Francesco. So I was like, okay, if they also mentioned
Francesco and me, they should have fixed it. But they didn't. So I was a bit confused that
all the names were mentioned there in the iOS 13 update. And also a month is a bit too short.
And everything that they patched but silently already before was the enhanced inquiry response
issue. And then like I poked them from time to time, did you already patch it? Why didn't you
patch it? And so on. And at 3063 on stage, I also showed that this is still unpatched and so on.
And they still didn't patch it. And back then I already had in mind. So that was when I already
called Francesco and said, like, in January, we are going to build speculative transmission.
So that was, I was like, please get things in that direction of a text
fixed. But yeah, and then end of January, I actually knew that this is probably unpatchable.
And that was when I sent Apple that email, you know, why Broadcom didn't send you a fix because
it's unpatchable. What are you telling us? And yeah, so at least so that that means like Broadcom
and also like some of their customers got like some, some notice already in January, about those
things like that they are broken. And I mean, also like the ones before just about denial of service.
And then I was building a few more pox beginning of March, because I was very busy in between.
But that were like the final proof of concepts like that there's even this ram sharing and it
is exploitable and stuff like this, which I mean, Broadcom should have known it already.
And they already introduced this, this one patch that you no longer can write
to the Bluetooth ram after drive initialization that one was already pushed to devices
somewhere around March. So this is like the thing that they did against it and that they could
easily do because they were like informed quite a long time before. And then in March, when all
the proof of concepts were also like, easy to run running and so on. Then I also started informing
the other vendors who I found to have coexistence in their data sheets mentioned. So
it's probably not everyone who uses it, but at least people I know that they use it.
So this is something that like if other people were going to go look at other chipsets,
the coexistence is what they'd be looking for, for a similar style of vulnerability.
I'd be something else. So I'm not sure how it is with all the other devices,
but it's definitely existing in a couple of devices and all proprietary.
And that coexistence is controlled by that one. Was it CC10 chip?
I forget the name of the chip. It was the microcode portion that...
Ah, the D11, you mean?
Yes, that's the D11.
Yes, it's controlled by this low level stuff, because it must be real time. So it's an
arbitration between the Bluetooth and the wireless, and the wireless needs to run this
into the lowest part of the stack that is directly on this microcontroller.
Could you... is there anything else about that microcontroller that you
want to talk about or share with people that are watching right now?
Well, I think that it's very interesting if you can have the ability to hack this,
because it's the part that can decide what to transmit and whether the received frame should
be pushed to the host. So it's very interesting because you can also develop a very small stack
over there, and the behavior of this stack would be completely not detectable by the host. So there
is no way for the host to understand what the U-code might do. So if you find a way for changing
the U-code over the air, then wow, that's amazing what you can do.
But so is this something that could like proactively drop packets with like a magic value
or something like that?
Yeah, yeah, yeah. For this test that we were doing with the coexistence, we were
sending command to the wireless interface over the air, and the U-code is the D11 core is receiving
them, then dropping them, and changing the configuration of the wireless interface.
This is totally unnoticed by the host.
That's awesome. What are the next areas that you guys are looking into for like future research?
Do you have anything already lined up? Anything you can talk about?
Probably the can talk about is the part, right? I mean, obviously like wireless security, but
yeah. So there will be stuff coming up. So I will definitely do further research
and I mean, Francesco has been doing this for so many years, probably nobody else is like
questioning what he's going to do in the future when he has been doing it for the last 15 years.
Fair enough. Yeah, I'm running out of questions. We do have a couple more people that are
are typing now. Yeah. So I mean, we've got a few moments. Is there anything that you guys
want to talk about proactively that we haven't already covered?
I mean, so something that is kind of interesting is that like people currently like also if you
look into the first YouTube comments of the talk, it's like they are like, you are just publishing
this because I don't know there is this exposure notifications for Corona and stuff like this.
But actually, we have been working on this, I mean, since much longer time than this. So it's
nothing that's like connected to Corona or something in that sense. And also, I think like,
for average people who just keep their system up to date and just use it. I don't think that it's
like a big threat in that sense. I mean, of course, like if you go on DEF CON, where a lot
of hackers are around you, you might want to disable Bluetooth and Wi Fi, but like disabling
Wi Fi also has been a well known practice in the past. So yeah, it's in your experience,
in your experience, does disabling like Bluetooth and Wi Fi in the device actually turn off the
full radio? It doesn't turn off the chip, but it disables the host deck usually in a way
that you cannot establish active connections anymore. It depends. But so yeah, I mean,
of course, like switching off your device if you don't want it to be hacked is a good practice,
probably even taking out the battery. It really depends. It really depends on your on your level
of paranoia, of course. But so yeah, so those those people who who are afraid because they
have like, I don't know if you if you have something on your smartphone that's like worth
100,000 bucks or something, then maybe consider being hacked because this is like the range where
exploits for those devices start, right? So yeah, so that's probably the threat model here.
And I don't think that like, I mean, until someone writes that Bluetooth form, who knows?
But I don't think that until then, like, Bluetooth would be the preferred way to hack people.
What I still don't like about like, or how all this stuff like goes is that still Wi Fi and
Bluetooth are like, I mean, they have been exploited back in 2017, very publicly, and they
are still very insecure. And that's, that's the part here, like they have been insecure for years.
And there's, I mean, some things are happening, but really vendors and so on, they really need
like some motivation to fix stuff even further. And so I wouldn't really say like, we are making
it more insecure. It's really like kicking them somewhere and saying like, please, please fix it,
make it better. Like we have seen like at least some improvements within the Broadcom firmware,
it's still not super secure, but it's secure after the things that happened in 2017. And
yeah, so I hope to move it a bit more in this direction.
Do you have a general feeling for like, if there's any particular chips that
are seen more secure than others, like a better coding practices or
anything like that? Or are they all kind of roughly the same?
There are at least some that are more obscure than others. I mean, Qualcomm has their own
hexagon DSP, which you can emulate, but there are, I think there's a disassembler plugin for
Ghidra, which partially works. And then there is two for IDA, but they also don't support like
all commands. Then you just have disassembler and not the compiler, Ghidra you would also have
the compiler. So it's really bad quality of those tools for Qualcomm. And then still
last year at DEF CON, there has been a talk about Qualcomm Wi-Fi having a bug. And they,
so after the talk, I just went to them, I was like, how did you find it? I said,
just like static reverse engineering. I was like the hexagon, right? But yeah, so
not sure if Qualcomm is more obscure or really more secure, at least they have more people on
security conferences and, but yeah, it's, it's hard to tell. So I think in general,
if you have newer hardware, then you have more security measures in it and like newer chips.
So if you buy like the most expensive Google or iPhone or whatever, it's probably more secure
than if you buy some very cheap smartphone with cheap chips that didn't have so much money for
development, but it's still no guarantee. So it just, it could have the budget to make it secure
if they wanted to make it secure. It's no guarantee, right? Right. Fair. And the last
question that I think that we can take, and this one's not directly about your presentation. Someone
wants to know how you displayed your hand behind your presentation in the actual recorded video.
So that's actually a method that I stole from Daniel Crusoe, the guy who did the spectra.
So for his lectures, he's using OBS and he has a white wall. I mean, I also have the white wall
behind me, right? And then I point with my hand and this is the part that I'm filming. And so
this, this part would be like behind the slide and in the slide, I said white as an opaque color,
and then I put my hand off. So behind it, so then I have the layers and I can do the
the pointing. So this would be the pointing.
Nice. I'm sure some other presenters will appreciate that touch.
Okay. Well, that's all the time that we have for you. Thank you both for joining us for the Q&A
session. Thank you both for getting content into the virtual DEF CON and yeah, have a nice day.
Thank you, too.
Take care.
Thank you, too.