0:00:00.000,0:00:19.909
36C3 preroll music
0:00:19.909,0:00:26.720
Herald Angel: Our next speaker is jiska.[br]jiska is attending this conference since
0:00:26.720,0:00:32.209
ages like a decade? even more?[br]jiska: 20, 22 C3
0:00:32.209,0:00:36.941
Herald Angel: Long, long time. Sometimes[br]she is also doing some talks here. The
0:00:36.941,0:00:42.010
last one last year was about Bluetooth.[br]There she was in depth. This time it will
0:00:42.010,0:00:49.510
be a more general talk about wireless[br]protocols NFC, LTE, Wi-Fi, and, of course,
0:00:49.510,0:00:56.460
Bluetooth. So she will tell us what is[br]broken in all those protocols. So have fun
0:00:56.460,0:01:00.590
and enjoy the talk "All wireless[br]communications stacks are equally broken"
0:01:00.590,0:01:02.820
by jiska.
0:01:02.820,0:01:09.230
applause
0:01:09.230,0:01:14.251
jiska: So welcome to my talk. I thought it[br]first to be a foundation talk, but it will
0:01:14.251,0:01:18.570
also have new topics about everything that[br]is kind of fundamentally broken in
0:01:18.570,0:01:23.999
wireless communication and it will cover[br]anything in your smartphone soul like NFC,
0:01:23.999,0:01:30.450
Bluetooth, Wi-Fi, LTE. You could order[br]them like by communication range or by
0:01:30.450,0:01:36.880
specification length or lines of code. But[br]the thing is, so the specification length
0:01:36.880,0:01:41.200
and line of code also mean increased[br]complexity. And if there is increased
0:01:41.200,0:01:47.549
complexity, you might have issues with[br]security in it, in the very end. And then
0:01:47.549,0:01:52.570
there is something that is even worse than[br]LTE, which is vendor specific additions
0:01:52.570,0:01:56.840
that would be when you open like five[br]instances of IDA and like tried to
0:01:56.840,0:02:04.210
analyze where the wireless message is[br]going and what it is doing. So most of
0:02:04.210,0:02:08.810
this in this talk will be about wireless[br]exploitation and the new stuff will be
0:02:08.810,0:02:14.700
fuzzing techniques and a new escalation[br]target. But everything else is more like a
0:02:14.700,0:02:21.320
general view on wireless exploitation. So[br]first, to understand what the wireless
0:02:21.320,0:02:27.380
exploit does is to separate it in[br]different layers. So there is the lowest
0:02:27.380,0:02:31.459
layer, which is some hybrid chip which[br]runs a firmware, let's say bluetooth
0:02:31.459,0:02:35.889
firmware, which is then attached to a[br]driver. Then there's some privileged
0:02:35.889,0:02:40.430
stuff, it depends a bit on what kind of[br]system you're on. And in the end, there
0:02:40.430,0:02:45.040
will be applications and no matter where[br]you exploit is on that layer that you're
0:02:45.040,0:02:50.060
exploiting, some security measures become[br]ineffective. So, for example, if there is
0:02:50.060,0:02:56.589
encryption and you have an exploit for[br]that layer, it would become ineffective.
0:02:56.589,0:03:02.840
And it depends, so the higher you are, the[br]higher also the exploit prices get. So for
0:03:02.840,0:03:08.159
the Wi-Fi RCE, you would be at 100K, for[br]baseband RCE with local privilege
0:03:08.159,0:03:12.859
escalation, it gets already 200 K, and if[br]it's just a messenger or something, then
0:03:12.859,0:03:17.739
it's like really, really high in the[br]price. So the question is like, why is
0:03:17.739,0:03:27.499
this wireless stuff a bit cheaper? So[br]well, you need a certain distance. And so
0:03:27.499,0:03:31.980
that's probably a thing. And then also,[br]maybe they are just too easy to find. I
0:03:31.980,0:03:37.709
don't know. Like at least, maybe for me, I[br]don't know for normal people. Or maybe the
0:03:37.709,0:03:42.629
market demand is not that high for them.[br]Or they are not privileged enough. I don't
0:03:42.629,0:03:49.549
know. But actually they'd need like only[br]like non or less interaction. So. Yeah.
0:03:49.549,0:03:55.959
Still a thing I would say. So within the[br]group I am working at we had a lot of
0:03:55.959,0:04:00.950
wireless research and also tools that we[br]released. And the first one I think that
0:04:00.950,0:04:07.010
was running on a mobile phone is NFCGate,[br]which is currently managed by Max. Then
0:04:07.010,0:04:11.870
there is nexmon, which is our largest[br]project, which is patching of Broadcom
0:04:11.870,0:04:17.030
Wi-Fi. And Matthias, who did that, reached[br]his goal by just saying, like, I now have
0:04:17.030,0:04:24.900
kind of a software defined radio in a[br]commodity like Broadcom Wi-Fi chip. And so
0:04:24.900,0:04:29.140
he was a bit bored and kicked off two new[br]projects before he left, which he then
0:04:29.140,0:04:33.889
handed over. The first one is Qualcomm LTE[br]and the second one was Broadcom Bluetooth,
0:04:33.889,0:04:39.540
which I ended up with. And then we have[br]someone else who is Milan and he is doing
0:04:39.540,0:04:44.600
stuff that comes more like from the[br]application layer. So he implemented an
0:04:44.600,0:04:51.880
open source solution for Apple Airdrop[br]that you can run on your Raspberry Pi. And
0:04:51.880,0:04:57.680
well hackers gonna hack, so this stuff has[br]been used a lot for exploitation, not by
0:04:57.680,0:05:01.760
us, but by others. So there were three[br]groups using nexmon for Wi-Fi
0:05:01.760,0:05:06.420
exploitation, at least like what is[br]publicly known and like the bigger ones,
0:05:06.420,0:05:10.980
maybe I forget someone, but so there is a[br]lot of exploitation going on there. Then
0:05:10.980,0:05:15.510
internal blue has been used to demonstrate[br]an attack against a key negotiation of
0:05:15.510,0:05:22.470
Bluetooth just this august. And the open[br]Airdrop implementation was used for some
0:05:22.470,0:05:28.150
honeypots at Black Hat and AirDos. And[br]like a lot of stuff is going on there. And
0:05:28.150,0:05:31.940
then you might ask yourself, like, yeah,[br]so, if everybody is using it for
0:05:31.940,0:05:39.060
exploitation why don't we just do it[br]ourselves. And we actually did that and we
0:05:39.060,0:05:44.800
even did that for this very first project,[br]this NFC project. And the most important
0:05:44.800,0:05:49.930
thing you need to know about NFC is that[br]the near field is not really a near field.
0:05:49.930,0:05:54.300
So there's -- it's just communication, but[br]it's not near field communication, which
0:05:54.300,0:06:00.110
means so if you are able to forward the[br]communication, so for example, you have
0:06:00.110,0:06:03.800
like your credit card and then a[br]smartphone with NFC, you could forward it
0:06:03.800,0:06:10.090
over the cloud or some server and then to[br]another smartphone and then to the payment
0:06:10.090,0:06:15.300
terminal. And usually there's no time[br]constraint or distance pounding that would
0:06:15.300,0:06:19.400
prevent this. So you can at least forward[br]and relay messages and you might even be
0:06:19.400,0:06:26.060
able to modify them on the way. And some[br]students of us did like some testing in
0:06:26.060,0:06:32.920
some systems of some third parties who[br]then politely asked them to please stop
0:06:32.920,0:06:40.700
the testing. So it was not really a cool[br]thing overall. Like, not not good to
0:06:40.700,0:06:45.510
publish and so on. And the more happy I am[br]about that there's other researchers who
0:06:45.510,0:06:52.830
actually used some other tooling to look[br]into NFC. So just this month there has
0:06:52.830,0:06:57.530
been a talk at Black Hat, so not by us,[br]but by others about the visa credit cards.
0:06:57.530,0:07:05.780
And it's just all broken and it's cool[br]that some people like just did it anyway.
0:07:05.780,0:07:10.180
Yeah. So this is more about -- the NFC[br]stuff is more about forwarding and the
0:07:10.180,0:07:16.160
actual specification, but something that[br]is also cool is -- If you get code
0:07:16.160,0:07:21.830
execution within a chip and this is very[br]different attack scenario. And for
0:07:21.830,0:07:27.180
Bluetooth, I think it's especially bad[br]because of how everything is designed. And
0:07:27.180,0:07:34.250
the first design issue in Bluetooth is[br]that the encryption key is stored in a way
0:07:34.250,0:07:38.170
that the chip can always ask for[br]encryption keys here at the host, or it's
0:07:38.170,0:07:43.860
even already on the chip. And there is no[br]kind of security there. So whenever you
0:07:43.860,0:07:47.800
have code execution on the chip, it means[br]you can get all the encryption keys, not
0:07:47.800,0:07:52.280
of just the active connection, and then[br]break everything that is kind of a trusted
0:07:52.280,0:07:56.630
connection by this key. And that even[br]breaks features like the Android Smart
0:07:56.630,0:08:02.230
Lock. And Android Smart Lock is a thing[br]you can unlock your Android smartphone, if
0:08:02.230,0:08:06.300
you have a trusted device and if you'd[br]like add this, you might do this for your
0:08:06.300,0:08:12.790
car because it's nice in your car when you[br]have like your audio and your navigation
0:08:12.790,0:08:16.940
and everything without a locked[br]smartphone. But the question is like, how
0:08:16.940,0:08:21.480
secure is the Bluetooth of your car? Would[br]you trust that one to unlock your
0:08:21.480,0:08:28.620
smartphone? I don't know. And the next[br]thing is, so if you have code execution on
0:08:28.620,0:08:33.899
a Bluetooth chip, it also means that you[br]might be able to escalate into some other
0:08:33.899,0:08:42.050
components so that you go up all the[br]layers. The next question, is the exploit
0:08:42.050,0:08:46.589
persistent? So let's say I have something[br]that is running on the chip and I don't
0:08:46.589,0:08:52.700
know, extracting encryption keys or doing[br]whatever. You might ask yourself, so how
0:08:52.700,0:08:56.320
long will it be on the chip? I mean, it's[br]just a Bluetooth chip you switch Bluetooth
0:08:56.320,0:09:02.379
off sometimes and then the specifications.[br]So it's just a page like almost 1000. So
0:09:02.379,0:09:06.819
just like the first third of the[br]specification it says not the HCI_Reset
0:09:06.819,0:09:12.500
command will not necessarily perform a[br]hardware reset. This is implementation
0:09:12.500,0:09:17.339
defined. Then I looked into the Cypress[br]and Broadcom chips and saw, yeah, so if
0:09:17.339,0:09:21.880
you do each day reset, it's obviously not[br]a full hardware reset, it's just flashing
0:09:21.880,0:09:26.600
some queues connection stuff here and[br]there. So there is definitely a memory
0:09:26.600,0:09:33.689
area where you could put your exploit and[br]it would be persistent. So then you might
0:09:33.689,0:09:39.329
say, yeah, OK, so what do I do? I don't[br]know. I put my smartphone into flight mode
0:09:39.329,0:09:46.010
for a hard reset. That usually doesn't[br]work. You might also like reboot your
0:09:46.010,0:09:50.110
phone. In most cases, this works. For some[br]other coexistence stuff, I had the
0:09:50.110,0:09:54.409
impression that sometimes so it's a bit[br]strange, it might not necessarily like,
0:09:54.409,0:10:02.889
reset. Turning off for a while might hard-[br]reset the chip I think. Or you just put
0:10:02.889,0:10:08.240
your smartphone in a blender and then.[br]Yeah. So that might turn off the Bluetooth
0:10:08.240,0:10:16.019
chip finally. Yeah. So the next issue is[br]so let's say we have an exploit running
0:10:16.019,0:10:20.889
there, but we first need an exploit. So[br]the very first step is still missing as a
0:10:20.889,0:10:26.480
building block. And after the talk last[br]year, I did some stuff with the unicorn
0:10:26.480,0:10:31.519
and fuzzing on the chip and it was super[br]slow. And then suddenly Jan showed up and
0:10:31.519,0:10:38.809
Jan said, Hey, I want to build a fully[br]emulated chip for superfast fuzzing and
0:10:38.809,0:10:42.889
attach it to Linux and everything should[br]like run on the real -- like as on a real
0:10:42.889,0:10:47.430
system, just the over the air input will[br]be fast. And I was like, you cannot do
0:10:47.430,0:10:51.480
this for a master thesis. And then he was[br]building that thing within three months
0:10:51.480,0:10:57.350
and the remaining three months he was[br]writing a thesis and e-mails to vendors.
0:10:57.350,0:11:02.819
So here we go. What does Frankenstein do?[br]So it's running on an evaluation board of
0:11:02.819,0:11:07.659
that, yeah, it's just a normal Bluetooth[br]Bord that's connected to a Linux host over
0:11:07.659,0:11:14.999
UART and a modem over the air and then you[br]would snapshot that thing and emulate it
0:11:14.999,0:11:20.540
and give it fast input attached to the[br]real host. And that means that if you find
0:11:20.540,0:11:24.839
some vulnerability, it might be within all[br]the components or it might also be under
0:11:24.839,0:11:30.209
Linux host or it might be something that[br]is full stack. So you have something that
0:11:30.209,0:11:34.630
starts on the chip, gets to the host, the[br]host requests further things and then it
0:11:34.630,0:11:38.690
goes back to the chip. So you could build[br]like quite complex stuff. And for this I
0:11:38.690,0:11:45.420
have a short demo video. So the reason why[br]I do this as a video is that it might
0:11:45.420,0:11:49.640
happen that it finds heap overflows[br]otherwise. And then also it's not super
0:11:49.640,0:11:54.550
stable at the moment. So you can see it's[br]scanning for LE devices and then Wireshark
0:11:54.550,0:11:58.369
most of the time would get malformed[br]packets, but sometimes it could also get
0:11:58.369,0:12:08.690
normal packets and like some mesh stuff,[br]whatever. So this is Frankenstein running.
0:12:08.690,0:12:16.140
Ja, so what Jan focused on is early[br]connection states. That means stuff
0:12:16.140,0:12:21.980
where you don't need a pairing. And then[br]he found like heap overflows there in very
0:12:21.980,0:12:28.741
basic package types. So quite interesting.[br]And then the stuff was fixed, I think, or
0:12:28.741,0:12:33.220
hope, whatever. So at least like in very[br]recent devices and then the iPhone 11 came
0:12:33.220,0:12:37.870
out and in contrast to the specification,[br]over the air, the iPhone 11 says, hey, I'm
0:12:37.870,0:12:42.899
Bluetooth 5.1. I was like, wow, first[br]consumer device, Blueotooth 5.1. And I was
0:12:42.899,0:12:48.019
like, I don't really mind my way of the[br]exploitation as long as I can get code
0:12:48.019,0:12:53.139
execution on chip. So if it is with user[br]interaction and a pairing and whatever, I
0:12:53.139,0:12:57.990
don't care as long as I get code execution[br]on it. And then I was like, okay, let's
0:12:57.990,0:13:02.870
add some fuzz cases to Frankenstein,[br]continue fuzzing. And then I found that
0:13:02.870,0:13:08.259
specific evaluation board that Jan was[br]building this for has a problem with the
0:13:08.259,0:13:14.849
heap configuration for certain packet[br]types. And so if you change that, you
0:13:14.849,0:13:19.490
would hard-brick the device. I mean, I[br]bricked two evaluation boards trying to
0:13:19.490,0:13:25.139
fix stuff. So, yeah, it's just[br]bricked. And so that means for me to
0:13:25.139,0:13:30.420
continue fuzzing to write like to port[br]something like 200 handwritten hooks to
0:13:30.420,0:13:35.769
another evaluation board. It's almost[br]running. So there's just some stuff with
0:13:35.769,0:13:40.309
thread switching that's not super smooth[br]yet, but like it's almost on the next
0:13:40.309,0:13:46.069
board. And further plans are to add more[br]hardware. So we're also working on the
0:13:46.069,0:13:52.839
Samsung Galaxy S 10 and probably a MacBook[br]to get it in there. So then it would not
0:13:52.839,0:13:57.460
just be Linux, but at least macOS, maybe[br]Android. I don't know yet. And another
0:13:57.460,0:14:01.069
thing that would be cool and also we[br]didn't build yet, but it might be feasible
0:14:01.069,0:14:07.999
with some USRP X310 over PCI Express and[br]with FPGA and all the fancy stuff to get
0:14:07.999,0:14:12.790
real over the air input, which then would[br]mean that you would have a full queue like
0:14:12.790,0:14:19.879
from over the air real Bluetooth packets[br]going all the way up and then to a host
0:14:19.879,0:14:23.839
and the way back. And you could also use[br]that just to test your new emulation
0:14:23.839,0:14:31.200
scheme or whatever you want to change. So[br]not just security. Ja, so the next thing
0:14:31.200,0:14:36.679
is, so if you have code execution, what do[br]you do with it? And the normal approach is
0:14:36.679,0:14:43.360
to try to go all the layers up. But there[br]might also be some chip level escalation
0:14:43.360,0:14:50.269
and you might immediately see it on the[br]next picture. So this is from a Broadcom
0:14:50.269,0:14:55.519
chip, but that's something that you would[br]also see in many other chips, which is
0:14:55.519,0:14:59.960
that you have a shared antenna. And you[br]could also have two antennas, but they are
0:14:59.960,0:15:04.179
both on 2.5GHz and it's in the very same[br]smartphone super close next to each other
0:15:04.179,0:15:07.970
and you would get interference. So usually[br]you just have the same antenna and do some
0:15:07.970,0:15:12.899
coordination like when it's Bluetooth[br]sending, when it's Wi-Fi sending so that
0:15:12.899,0:15:19.230
they don't interfere. And this feature is[br]called coexistence and there is tons of
0:15:19.230,0:15:24.020
coexistence interfaces. So this is just[br]the one from Broadcom. And when I saw it,
0:15:24.020,0:15:29.290
I was like, oh, Francesco, let's look into[br]this. You know, all the Wi-Fi stuff, I
0:15:29.290,0:15:32.920
know all the Bluetooth stuff let's do[br]something. And he was like, no, it's just
0:15:32.920,0:15:37.499
it's just a marketing feature so that it[br]can like sell one chip for the price of
0:15:37.499,0:15:41.620
two chips or something. And I was like,[br]no, no, no, it must be an exploitation
0:15:41.620,0:15:47.999
feature. So, and then to end this[br]discussion, I went to Italy for eating
0:15:47.999,0:15:53.259
some ice cream and saw reality somewhere[br]in between. It's more like it's hardcoded
0:15:53.259,0:15:58.430
blacklisting for wireless channels and[br]stuff. It's traffic classes for different
0:15:58.430,0:16:02.889
types of traffic for Bluetooth and Wi-Fi.[br]And you can look it up in tons of patents
0:16:02.889,0:16:08.949
and it's like super, super proprietary.[br]And so we let's say we played a game which
0:16:08.949,0:16:14.311
was like I tried to steal his antenna and[br]he tried to steal my antenna. And so it
0:16:14.311,0:16:18.779
turned out, if you do that, yeah, you can[br]turn off Wi-Fi via Bluetooth, Bluetooth
0:16:18.779,0:16:24.709
via Wi-Fi. And then also like on most[br]phones, you need to reboot them and some
0:16:24.709,0:16:28.009
of them even reboot them themselves. So[br]this is just like a speed accelerated
0:16:28.009,0:16:33.879
thing with an Samsung Galaxy S 8 that is[br]not up to date. For iPhones, you would
0:16:33.879,0:16:38.999
just immediately see a reboot without any[br]interaction of things going off and on. So
0:16:38.999,0:16:42.689
Broadcom is still in the process of fixing[br]it. I don't know if they can fix it, but
0:16:42.689,0:16:46.899
they said they could fix it. But something[br]you should definitely fix is like the
0:16:46.899,0:16:50.339
driver itself so that the smartphone[br]reboots and so on. So I don't know. I
0:16:50.339,0:16:55.560
thought it would be fixed, actually, in [br]iOS 13 because it mentions Francesco and
0:16:55.560,0:17:00.689
me, but still on 13.3 I don't know, it, [br]it's still - um - you can
0:17:00.689,0:17:04.059
still crash the iPhone that way. But
0:17:04.059,0:17:08.430
it's just some resource blocking so it's[br]like not super dangerous thing, I would
0:17:08.430,0:17:13.850
say. And you still need a Bluetooth RCE[br]before you could do it and so on. But
0:17:13.850,0:17:21.370
still not cool that it's still not fixed.[br]Yeah, so what about the other stacks and
0:17:21.370,0:17:26.820
the escalations? So there is tons of[br]different Bluetooth stacks, so it's really
0:17:26.820,0:17:32.910
a mess. And obviously because of[br]Frankenstein, we had this first Linux
0:17:32.910,0:17:39.480
Bluetooth stack attached and so on. But,[br]yeah. So what has been there for a
0:17:39.480,0:17:43.780
wireless 2017, these BlueBorne attacks,[br]you might have heard of them. And they
0:17:43.780,0:17:47.491
found escalations like on Android,[br]Windows, Linux, iOS, whatever. And then
0:17:47.491,0:17:52.530
you might say, like in security, you often[br]say, so someone looked into it. It must be
0:17:52.530,0:17:57.760
secure now. And then there's so many[br]features coming. So there's all these IoT
0:17:57.760,0:18:01.750
devices. So everybody nowadays has[br]wireless headphones and fitness trackers
0:18:01.750,0:18:06.650
and Bluetooth always on. And in the Apple[br]ecosystem, it's really a mess. So if you
0:18:06.650,0:18:11.080
have more than one Apple device, you would[br]have Bluetooth enabled all the time.
0:18:11.080,0:18:14.150
Otherwise you couldn't use a lot of[br]features. And then there is like stuff
0:18:14.150,0:18:18.450
like Web Bluetooth so Bluetooth LE[br]support from within the browser. So it's
0:18:18.450,0:18:23.450
like a lot of new attack surfaces that[br]arised since then. I think -- So that's
0:18:23.450,0:18:31.570
more my personal estimation is, 2020 might[br]be more BlueBorne like attacks. The
0:18:31.570,0:18:34.980
saddest Bluetooth stack somehow is the[br]Linux Bluetooth stack. So I don't want to
0:18:34.980,0:18:39.000
blame the developers there. I mean, it's[br]not their fault, but it's not enough
0:18:39.000,0:18:43.720
people contributing to that project. And[br]if you would try to to analyze something
0:18:43.720,0:18:48.050
that is going on in the stack and you[br]don't really know what is going on, you
0:18:48.050,0:18:52.090
would do git blame or whatever and you[br]would always see the same guy as the
0:18:52.090,0:18:56.710
commiter. So at least if you're on a[br]specific problem, then there's only one
0:18:56.710,0:19:01.620
person committing there. And so the[br]picture down there actually has the same
0:19:01.620,0:19:06.820
guy thrice. So this is also a bit of a pun[br]here intended. We did some fuzzing in
0:19:06.820,0:19:12.030
there. We still need to evaluate some of[br]the results. So yeah, but I also feel like
0:19:12.030,0:19:16.880
nobody's really using it and it's kind of[br]sad. I mean, there's some Linux users, I
0:19:16.880,0:19:23.110
guess, but ... Yeah. Then there is the[br]weirdest stack I would say. So there's the
0:19:23.110,0:19:27.852
Apple Bluetooth stack and this one is[br]actually three. So there is there is the
0:19:27.852,0:19:31.380
MacOS Bluetooth stack. There's an iOS[br]Bluetooth stack. They are definitely
0:19:31.380,0:19:34.750
different. And then there is a third[br]embedded one, for example, for the
0:19:34.750,0:19:43.300
AirPods. They are all running different[br]different things. So, yeah, whatever. And
0:19:43.300,0:19:47.850
then they also have tons of proprietary[br]protocols on top of their Bluetooth stuff
0:19:47.850,0:19:52.170
that they're also very special. And I had[br]like at least two students, just one
0:19:52.170,0:19:58.240
porting it to iOS one to MacOS. And then[br]we also have students working on the other
0:19:58.240,0:20:02.711
protocols that are on top of Bluetooth.[br]And if you look into this, it's like, what
0:20:02.711,0:20:06.560
the hell? It's really hard to reverse[br]engineer because you have like three
0:20:06.560,0:20:10.651
different implementations and then[br]sometimes you're like: "yeah, okay. Maybe
0:20:10.651,0:20:15.610
it's also just bad code." And in the end,[br]so from what I saw so far, I would say
0:20:15.610,0:20:23.640
that it's kind of both. And then there is[br]the stack that I played also lots around
0:20:23.640,0:20:29.060
with, which is the Android Bluetooth[br]Stack. And they did a lot for the security
0:20:29.060,0:20:32.780
in the recent releases. And it annoys me[br]so much that when I want to get internal
0:20:32.780,0:20:36.770
blue running on it, I just echo to the[br]serial port instead so I bypass everything
0:20:36.770,0:20:42.860
that the operating system does. And so[br]something that Android cannot do, which
0:20:42.860,0:20:46.030
Apple does, is so Apple has all the[br]proprietary protocols. And if something
0:20:46.030,0:20:50.320
goes wrong, they immediately cut the[br]connection. But Android doesn't because of
0:20:50.320,0:20:54.580
compatibility and stuff. So you could just[br]send garbage for like two minutes and try
0:20:54.580,0:20:57.840
and see what happens. And it would[br]continue listening and asking and
0:20:57.840,0:21:04.980
confirming. But that's kind of an[br]overall design issue, I think. And yet
0:21:04.980,0:21:10.630
there's Windows and I couldn't find any[br]students to work on Windows. laughter
0:21:10.630,0:21:19.140
If someone wants to do this, that would be[br]great. And so another stack that's kind of
0:21:19.140,0:21:26.440
missing here is LTE. And I would call this[br]like the long term exploitation plan. So
0:21:26.440,0:21:30.620
it's not. I think if the long term[br]evaluation, evolution, whatever, but
0:21:30.620,0:21:37.320
exploitation I think is the best thing for[br]the E. So we have like tons of wireless
0:21:37.320,0:21:42.540
stuff where we are working on and I mean[br]like even PowerPC. And then there is
0:21:42.540,0:21:48.380
Qualcomm and they have they have this[br]Qualcomm hexagon DSP. I hate it so much.
0:21:48.380,0:21:53.420
So there's even source code leaks for[br]their LTE stuff. But it's just such a pain
0:21:53.420,0:21:58.900
to work on it. So you might have noticed[br]is that ARM has this LTE project with
0:21:58.900,0:22:05.430
Qualcomm, but it's just not fun. But other[br]people were doing a lot in this area and
0:22:05.430,0:22:12.410
they've already presented here today and[br]yesterday. So the first thing is the SIM
0:22:12.410,0:22:18.310
card in the phone. So the SIM cards should[br]be a thing like. From from my perspective,
0:22:18.310,0:22:23.540
that should be secure because it protects[br]your key material. And then it runs tons
0:22:23.540,0:22:27.040
of applications. I don't know. And then[br]you can exploit them and get the victim's
0:22:27.040,0:22:31.400
location, dial premium numbers and launch[br]a browser. And then I didn't really
0:22:31.400,0:22:38.891
understand, like there's just this WIB set[br]browser whatever, and then there's launch
0:22:38.891,0:22:42.150
browser what, is it? And I think it even[br]launches a browser then on the smartphone,
0:22:42.150,0:22:48.340
whatever. It's just crazy. And then I was[br]trying to call Deutsche Telekom and I'm a
0:22:48.340,0:22:52.120
business customer. So it's just like[br]three minutes for a call for me. So giving
0:22:52.120,0:22:57.700
a call there is nice. And then the first thing[br]they told me is: "You are secure. We know
0:22:57.700,0:23:03.080
you have three SIM cards and they are all[br]up to date." So I have to say, one of them
0:23:03.080,0:23:08.130
is more than 10 years old, but maybe it's[br]up to date. And my answer is like, what
0:23:08.130,0:23:12.520
exactly is running on my SIM card? They of[br]course not answered. So yeah, something is
0:23:12.520,0:23:16.750
running there. If you want to know more[br]about SIM cards, there has been talk
0:23:16.750,0:23:22.570
already yesterday evening and it's already[br]online. And then there's also a lot of
0:23:22.570,0:23:27.170
people looking into LTE. And I think the[br]most popular one is to work by Yongdae
0:23:27.170,0:23:33.220
Kim. He did even some LTE fuzzing[br]framework that he didn't release publicly
0:23:33.220,0:23:39.220
so far, because of the findings. So it's[br]like, should you publish? Should you not
0:23:39.220,0:23:44.200
publish? But so the findings are super[br]interesting. And he also has students here
0:23:44.200,0:23:51.750
who just did a talk this morning.[br]Responsible disclosure. So that's the
0:23:51.750,0:23:57.560
thing. When you find stuff you need to do[br]is responsible disclosure. And so I said
0:23:57.560,0:24:02.360
Jan was writing a lot of e-mails. And one[br]of the first that he wrote was to ThreadX,
0:24:02.360,0:24:08.060
because ThreadX is the operating system[br]that runs on the Broadcom Bluetooth
0:24:08.060,0:24:14.470
chip. And so he said, like, your[br]heap is a bit broken and does not have any
0:24:14.470,0:24:18.640
checks. You could implement the following[br]checks, which are pretty cheap and it
0:24:18.640,0:24:22.440
should be cool. And then I could not[br]attack it anymore. And then ThreadX was
0:24:22.440,0:24:28.040
answering, which was a bit unexpected,[br]that they already knew about this
0:24:28.040,0:24:33.380
exploitation technique and that it is up[br]to the application to not be vulnerable to
0:24:33.380,0:24:37.830
memory corruption, so not to cause any[br]memory corruption. So it's the programmers
0:24:37.830,0:24:42.020
fault if they do something and it's not[br]the operating system that has to take care
0:24:42.020,0:24:51.640
of the heap. Okay. Yeah. Next issue. So[br]the bin diffing and the testing if a
0:24:51.640,0:24:56.590
vulnerability is still there. So you might[br]not always get feedback from all the
0:24:56.590,0:25:01.460
vendors. If they fix it, they may just fix[br]it at a certain point in time and then you
0:25:01.460,0:25:04.621
tell them all we tested the next release[br]and it's still vulnerable. And then they
0:25:04.621,0:25:08.380
would say, like for Samsung said, Yeah, we[br]cannot send your patches in advance
0:25:08.380,0:25:12.090
without an NDA because Broadcom, blah,[br]blah, blah and so on and so forth. And
0:25:12.090,0:25:17.250
then Broadcom offered to send us patches[br]in advance. And I said, Yeah. Nice. And I
0:25:17.250,0:25:21.500
also sent them a device list because they[br]already knew it from the previous process.
0:25:21.500,0:25:24.610
So if you tell them the following 10[br]devices have an issue, then you would
0:25:24.610,0:25:28.770
already know that we can test those[br]devices anyway. And so and after I sent
0:25:28.770,0:25:33.520
them the list, they said: "Oh, wait, but[br]you need an NDA." So no, I mean, we are
0:25:33.520,0:25:40.560
doing this for free anyway. And signing an[br]NDA, I wouldn't do that. Yeah. So overall,
0:25:40.560,0:25:44.550
it also did Broadcom Product Security[br]Incident Response Team is a bit strange so
0:25:44.550,0:25:49.550
they wouldn't hand out any CVEs. And what[br]I mean what I do is like I first get a CVE
0:25:49.550,0:25:53.060
and then informed them and the other[br]customers because I also don't get any
0:25:53.060,0:25:56.500
incident number or something. So if I[br]wouldn't do this, I wouldn't have any
0:25:56.500,0:26:03.140
number to refer a vulnerability to. And[br]well, at least they are also not doing
0:26:03.140,0:26:07.480
that much legal trouble. But it's just.[br]Yeah, not really something happening
0:26:07.480,0:26:13.860
there. But some of their customers were[br]nice at least to my students, so they paid.
0:26:13.860,0:26:17.950
So one customer, they don't want to be[br]named here, but they payed to fly to DefCon
0:26:17.950,0:26:22.160
for one of my students and Samsung gave a[br]bounty off one thousand dollar. I mean,
0:26:22.160,0:26:26.630
still I mean we are in the range of of[br]very very more expensive exploits if it
0:26:26.630,0:26:31.040
would be on the black market, but for[br]students it's definitely nice. Yeah.
0:26:31.040,0:26:34.860
Responsible disclosure timelines. So this[br]is something that I thought like maybe
0:26:34.860,0:26:38.500
some of this responsible disclosure[br]timeline is just because of how I
0:26:38.500,0:26:42.350
communicate with the vendor. And sometimes[br]I'm writing e-mails like a five year old
0:26:42.350,0:26:49.400
or something - I don't know. But actually.[br]So this is a timeline of Quarkslab, who
0:26:49.400,0:26:54.490
also found just this year vulnerabilities[br]in Broadcom Wi-Fi chips. And so they've
0:26:54.490,0:27:00.840
also asked about NDA and then also their[br]exploit timeline. It's a bit fun because
0:27:00.840,0:27:04.651
they had similar exploitation strategies[br]as the very first exploit that you could
0:27:04.651,0:27:10.710
see by Google Project Zero and then, yeah,[br]more distorted timeline, whatever. And in
0:27:10.710,0:27:18.810
the end, well. So it's just taking time.[br]And again, no CVE id issued and so on and
0:27:18.810,0:27:26.110
so forth. So it's the very same stuff for[br]others, which is pretty sad. And then so
0:27:26.110,0:27:31.230
for Cyprus, which is partially having[br]source code of Broadcom, it also
0:27:31.230,0:27:36.590
manufactures chips. It's also very slow[br]for the response of disclosure. And then I
0:27:36.590,0:27:40.220
got told by other people, like, yeah, if[br]you would disclose something to Qualcomm,
0:27:40.220,0:27:46.101
it also takes very long. And luckily we[br]didn't find something in an Intel CPU. But
0:27:46.101,0:27:49.710
yeah, there is ... so on the wireless[br]market, there still so many other vendors
0:27:49.710,0:27:56.310
to become friends with. So yeah. So[br]practical solutions to end my talk. What
0:27:56.310,0:28:01.110
could you do to defend yourself if you[br]don't have a tinfoil hat? Other things I
0:28:01.110,0:28:06.620
can recommend is the secure Wi-Fi set up.[br]So don't use antennas, just use antenna
0:28:06.620,0:28:13.390
cables. If you do that in our lap a lot.[br]So this is a setup by Felix. And so when I
0:28:13.390,0:28:17.710
was sending my slides to Francesca in[br]advance she just said "cool, I have the
0:28:17.710,0:28:23.960
same one right now at my desktop". So it's[br]a very common setup. Maybe not at your
0:28:23.960,0:28:30.450
home, but for us it is. Or you'd just go[br]to the air-gapped device. So this is my
0:28:30.450,0:28:37.400
Powerbook 170, that's a really great[br]device. Almost impossible to get it online
0:28:37.400,0:28:45.310
and it has Word and Excel.[br]So ask all the questions.
0:28:45.310,0:28:54.150
Applause
0:28:54.150,0:28:58.250
Herald Angel: Thank you very much to[br]jiska. We still have several minutes left.
0:28:58.250,0:29:03.000
You will find eight microphones in the[br]room. Please line up in behind the
0:29:03.000,0:29:08.190
microphones to ask a question. And the[br]first question goes to the Internet.
0:29:08.190,0:29:12.520
Signal Angel: So at jiska, the question[br]is, are the Bluetooth issues you are
0:29:12.520,0:29:17.740
talking about also present in Bluetooth[br]Low Energy IoT devices.
0:29:17.740,0:29:22.830
jiska: Yes. So, I mean, there is IoT[br]devices, I cannot tell the vendor, but
0:29:22.830,0:29:28.620
there is also some popular devices that[br]have like Cypress Broadcom chips and then
0:29:28.620,0:29:33.380
it's even worse because they don't have a[br]separate stack, but often they have an
0:29:33.380,0:29:37.110
application running on the same arm core[br]and then you don't even need any
0:29:37.110,0:29:40.070
escalation.[br]Herald: All right. We have another
0:29:40.070,0:29:42.720
question at the microphone number one,[br]please.
0:29:42.720,0:29:47.390
Microphone 1: Thank you for the talk. My[br]question is, could you like did you
0:29:47.390,0:29:53.850
actually when you fuzzed the Bluetooth low[br]energy chip, did you when you managed to
0:29:53.850,0:29:57.710
get code execution, did you actually[br]climb up the protocol?
0:29:57.710,0:30:01.070
Did you like access Bluetooth profiles or[br]something like this?
0:30:01.070,0:30:06.810
jiska: Ah, so we, for example with the[br]link key extraction, we were building some
0:30:06.810,0:30:14.800
proof of concepts. But so it depends. We[br]don't currently have like a fully exploit
0:30:14.800,0:30:18.930
chain in terms of first on the chip and[br]then on the host. We have something that
0:30:18.930,0:30:25.970
goes directly on some hosts, but yeah,[br]there's tons of things there to do. Sorry?
0:30:25.970,0:30:30.170
Microphone 1: Yeah. And when you fuzz the[br]... how did you actually fuzz the chip
0:30:30.170,0:30:33.610
itself? How did you extract the[br]firmware from the chip?
0:30:33.610,0:30:37.201
jiska: So there is ... so Broadcom and[br]Cyprus are very nice because they have a
0:30:37.201,0:30:41.890
read RAM command so you don't need any[br]secure bypass or something. And for the
0:30:41.890,0:30:50.710
evaluation kits, there is even symbols[br]that we found in it. So symbols only means
0:30:50.710,0:30:55.700
like function names and global variable[br]names, that's it. But that's something to
0:30:55.700,0:30:59.320
work with.[br]Herald: Thank you. Another question from
0:30:59.320,0:31:02.740
the Internet, please.[br]Signal: Would you like the return of
0:31:02.740,0:31:06.480
physical switches for[br]the network controller?
0:31:06.480,0:31:11.380
jiska: Yeah, so that would be nice to like[br]physically switch it off. Actually, I
0:31:11.380,0:31:14.730
don't know where Paul is, but he is[br]building ... There is Paul. He is building
0:31:14.730,0:31:22.440
such a device. When is your talk at 10[br]o'clock. Paul is giving a talk about a
0:31:22.440,0:31:25.880
device where you have a physical[br]controller to switch off your wireless
0:31:25.880,0:31:28.890
stuff.[br]Herald: OK. The next question is again
0:31:28.890,0:31:33.560
microphone number one, please.[br]Microphone 1: Yes. Thank you. We just
0:31:33.560,0:31:38.980
bought a new car and by because[br]connecting the Bluetooth of my phone to
0:31:38.980,0:31:45.620
the car's system was very, very hard. And[br]I had to reboot the radio several times.
0:31:45.620,0:31:51.550
And then I found a message that the radio[br]must be directly connected to the CAN-bus
0:31:51.550,0:31:57.090
of the car. So you have a blueooth stack[br]connected directly to a CAN-bus. It was a
0:31:57.090,0:32:02.250
very cheap car. But if you[br]have an idea of what this means then...
0:32:02.250,0:32:08.221
jiska: Can you can you borrow me that car?[br]Microphone 1: It's a Toyota Aygo, you can
0:32:08.221,0:32:13.820
have it everywhere.[br]jiska: Well, that shouldn't be.
0:32:13.820,0:32:17.240
Herald: Alright, do we have a question at[br]microphone number eight, please?
0:32:17.240,0:32:21.590
Microphone 8: Hi and thank you for the[br]talk first of all. Uh well, if I
0:32:21.590,0:32:26.730
understood correctly, you said that the[br]vendors didn't mention if they fixed it or
0:32:26.730,0:32:32.090
not or they don't know if they fixed it.[br]jiska: Umm, yeah. So it depends. I know
0:32:32.090,0:32:36.650
like so if you look into the Android[br]security updates, so for example, August 5
0:32:36.650,0:32:40.920
has some Broadcom issue that was fixed and[br]I know which one that was and so on and so
0:32:40.920,0:32:46.990
forth. But so then it also means I like to[br]get that one onto a Samsung device. I
0:32:46.990,0:32:50.390
would need ... so they wouldn't build it[br]in the August update, but only in the
0:32:50.390,0:32:55.160
September update and then release it to[br]Europe, which is like mid or end of
0:32:55.160,0:32:59.370
September. And then I could download it to[br]my phone and test it over the air if it's
0:32:59.370,0:33:06.630
like really fixed and so on and so forth.[br]So it's ... there is like the first thing
0:33:06.630,0:33:10.190
is like that is listed publicly that it is[br]fixed. And then the next thing is that it
0:33:10.190,0:33:14.890
is actually fixed and it's really hard.[br]And for the communication with Apple, I
0:33:14.890,0:33:18.059
don't know. So sometimes they fix it[br]silently without mentioning us. And then
0:33:18.059,0:33:24.440
there's this iOS 13 thing where they[br]mentioned us but didn't fix it. So, yeah.
0:33:24.440,0:33:27.720
Microphone 8: Were there any issues like[br]that they found and they didn't know if
0:33:27.720,0:33:31.200
they fixed it or not. And you did like[br]patch-diffing or something like that?
0:33:31.200,0:33:35.059
jiska: Yeah, I did a lot of patch-diffing[br]and I currently have a student who is
0:33:35.059,0:33:40.210
doing nothing else than developing diffing[br]tools for the particular issues that I
0:33:40.210,0:33:42.830
have.[br]Microphone 8: And did you find that they
0:33:42.830,0:33:45.929
fixed it or not?[br]jiska: So it's first of all ... so we are
0:33:45.929,0:33:50.750
... so first of all, it's currently about[br]speed and stuff and I gave him some some
0:33:50.750,0:33:54.330
iPhone stuff for the next task.[br]But yes, it's work in progress. So most of
0:33:54.330,0:33:59.700
the other stuff I did by hand, so I also[br]have a good idea about like what a changed
0:33:59.700,0:34:05.200
within each kind of chip generation.[br]Microphone 8: Okay. Thank you very much.
0:34:05.200,0:34:09.180
Herald: All right. We had another question[br]from the Internet.
0:34:09.180,0:34:13.820
Signal: Yes. So from Mastodon, how exactly[br]was the snapshot of the Samsung Bluetooth
0:34:13.820,0:34:18.200
stack extracted for the fuzzing process?[br]jiska: The Samsung is ... so for Samsung
0:34:18.200,0:34:24.150
we have snap shotting, but for Samsung, we[br]don't have the rest of Frankenstein. The
0:34:24.150,0:34:30.860
other stuff is running on an evaluation[br]board. So the first part is mapping all
0:34:30.860,0:34:34.680
the hardware registers. So this is the[br]first trip that runs and tries to find
0:34:34.680,0:34:40.619
like all the memory regions. And once that[br]is done, there is a snapshotting hook that
0:34:40.619,0:34:44.129
you set to the function. So let's say you[br]want to look into a device scanning so you
0:34:44.129,0:34:48.760
would set the function into device[br]scanning. And once that it's called by the
0:34:48.760,0:34:53.530
Linux stack, he would freeze the whole chip[br]and disable like other interrupt stuff,
0:34:53.530,0:34:57.580
whatever that would kill it otherwise and[br]then copy everything that is in the
0:34:57.580,0:35:02.680
registers ... so that is kind of the snap[br]shotting. And once you have a snapshot,
0:35:02.680,0:35:08.119
then you can try to find everything that[br]kills your emulation like interrupts again
0:35:08.119,0:35:12.740
and thread switches and so on.[br]Herald: All right. We have one more
0:35:12.740,0:35:15.810
question from microphone, number one,[br]please.
0:35:15.810,0:35:21.380
Microphone 1: OK. So do you think that[br]open source, the driver or that open
0:35:21.380,0:35:25.500
hardware design will improve the[br]situation?
0:35:25.500,0:35:30.950
jiska: So open source? I think it would[br]improve the situation. But also one thing.
0:35:30.950,0:35:36.630
So I had to talk at mrmcd in September[br]this year. Another thing which is not
0:35:36.630,0:35:41.190
about open source is that the patching[br]capabilities of the Broadcom bluetooth
0:35:41.190,0:35:47.980
chips are very limited in terms of how[br]much can be fixed. So just open sourcing
0:35:47.980,0:35:54.120
wouldn't help Broadcom, for example.[br]Microphone 1: Like you mean like the
0:35:54.120,0:35:59.510
firmware is burnt into the chip and it's[br]limited to ...
0:35:59.510,0:36:01.180
jiska: Yeah[br]Microphone 1: Yeah, it's limited, right?
0:36:01.180,0:36:06.430
jiska: Yes, it's in the ROM. And then you[br]have patch ROM slots and you have like 128
0:36:06.430,0:36:10.900
patch ROM slot and each patch ROM slot is[br]a four byte override breakpoint thingy
0:36:10.900,0:36:14.880
that branches then somewhere else into[br]RAM. And then RAM is also limited.
0:36:14.880,0:36:21.430
So you couldn't like branch into large[br]chunks of RAM all the time. Yeah.
0:36:21.430,0:36:25.280
Microphone 1: Thank you.[br]Herald: All right. If there are not any
0:36:25.280,0:36:28.190
more questions?[br]jiska: Internet!
0:36:28.190,0:36:31.869
Herald: Internet? Oh, more Internet[br]questions. Then, please go ahead.
0:36:31.869,0:36:36.240
Signal: Yes. So winfreak on Twitter asks[br]what stack was tested when mentioning
0:36:36.240,0:36:40.700
Android? There are several and Google is[br]convinced rewriting it every year is a
0:36:40.700,0:36:45.220
good idea.[br]jiska: Ah, yeah. So this stuff that's like
0:36:45.220,0:36:51.140
the standard stack that runs on a Samsung[br]phone for example. So I think, like for
0:36:51.140,0:36:55.000
the main entry, there's only one ... I[br]know that there's like legacy stacks, but
0:36:55.000,0:37:02.340
they switch to only one.[br]Herald: So Signal Angel, do you have more
0:37:02.340,0:37:10.200
for us?[br]Signal: Yes. What is your hat made of?
0:37:10.200,0:37:18.440
jiska: My hat? So it's like aluminum foil.[br]And then there is the cyber cyber thingy.
0:37:18.440,0:37:26.270
So that's also important. Yeah. So but as[br]I said, it doesn't really help. It would
0:37:26.270,0:37:31.870
more help to put the smartphone in a[br]blender, for example.
0:37:31.870,0:37:35.950
Herald: Alright. Thank you very much for[br]this awesome talk. Give her a huge round
0:37:35.950,0:37:37.740
of applause to jiska.
0:37:37.740,0:37:40.985
applause
0:37:40.985,0:37:44.290
36c3 postroll
0:37:44.290,0:38:08.000
subtitles created by c3subtitles.de[br]in the year 2020. Join, and help us!