0:00:09.210,0:00:12.820
applause
0:00:12.820,0:00:16.360
Karsten Nohl: Great to be back. Thank you[br]very much, talking once again on mobile
0:00:16.360,0:00:21.080
security, taking two very different[br]angles, though, from what we talked about
0:00:21.080,0:00:26.670
the last couple of years. This time we want[br]to dive into the same topic that Tobias
0:00:26.670,0:00:31.890
Engel just did, looking at insecurities[br]that arise from the interconnect networks
0:00:31.890,0:00:38.150
between different operators and we want to[br]add another angle. And that is how YOU
0:00:38.150,0:00:43.190
can start self defending yourself from the[br]insecurities that many of your operators
0:00:43.190,0:00:49.410
have left open for many years, including[br]the new ones that Tobias and myself talk
0:00:49.410,0:00:56.190
about. If you do watch this on a download,[br]do go back and also watch Tobias's talk,
0:00:56.190,0:01:00.110
it's well worth it and also covers a lot[br]of the basics that I'm just going to skip
0:01:00.110,0:01:06.320
over now for the sake of time. Great talk,[br]by the way. Thank you Tobias. So aside
0:01:06.320,0:01:17.460
from. applause Aside from those SS7[br]based attacks, we want to talk about 3G
0:01:17.460,0:01:23.780
insecurities, not too many of them, but[br]severe as ever, as well as in the last
0:01:23.780,0:01:30.210
chapter. Then a few tips, as well as a new[br]tool to help you start self defending
0:01:30.210,0:01:36.320
against these mobile attacks. Now, just[br]briefly, then, what is the SS7 Network
0:01:36.320,0:01:40.920
Tobias has already covered the basics. So[br]just a quick definition from me. It's this
0:01:40.920,0:01:45.890
network that different mobile operators[br]are connected to, to exchange data among
0:01:45.890,0:01:51.530
each other. For instance, text messages[br]are sent over this network. So without SS7,
0:01:51.530,0:01:57.920
you couldn't be using this ancient chatting[br]technology SMS. Thank you SS7. But also
0:01:57.920,0:02:05.280
more security relevant information is[br]exchanged over SS7. For instance, if you're
0:02:05.280,0:02:10.530
using your phone in another country, as[br]many of you currently do, you still want
0:02:10.530,0:02:15.510
this visiting network to be able to use[br]encryption with your phone, but how is that
0:02:15.510,0:02:20.030
network going to know the right encryption[br]key? So this visiting network, the German
0:02:20.030,0:02:24.190
network has to ask your home network for[br]the correct encryption key and that goes
0:02:24.190,0:02:29.700
over SS7. And you can already see if[br]there's cryptographic information being
0:02:29.700,0:02:33.560
exchanged, if the wrong people ask and[br]still receive an answer, insecurities
0:02:33.560,0:02:39.950
arise. More interesting from a security[br]perspective, though, are messages that are
0:02:39.950,0:02:46.099
exchanged within one network over SS7.[br]So SS7 is often misunderstood as this
0:02:46.099,0:02:50.840
technology that's used for worldwide[br]exchange of information. The same network,
0:02:50.840,0:02:54.640
though, is used inside an operator. So[br]there's no need for interconnect. There's
0:02:54.640,0:03:01.290
already SS7 flows going on between those[br]different mobile switching centers, MSC.
0:03:01.290,0:03:07.530
And each mobile switching center covers[br]one area, let's say a city. So imagine a
0:03:07.530,0:03:13.340
situation where you are. You're in a call[br]and you're traversing from one area to
0:03:13.340,0:03:17.110
another. You're crossing, let's say, your[br]state boundary. So there's new MSC,
0:03:17.110,0:03:21.560
doesn't know how to handle your call. It[br]needs the decryption key for the already
0:03:21.560,0:03:28.610
ongoing conversation. So there's another[br]SS7 message that allows you to query for
0:03:28.610,0:03:33.650
the key of a transaction that's currently[br]going on. OK? And again, you can already
0:03:33.650,0:03:38.739
see how if the wrong people send this type[br]of message and they receive an answer,
0:03:38.739,0:03:46.730
insecurities arise. The insecurity that[br]that has most been talked about in recent
0:03:46.730,0:03:52.670
years, again, up until Tobias's talk, was[br]tracking. And tracking was often understood
0:03:52.670,0:03:57.720
as: There's this evil message, the any time[br]interrogation and The Washington Post
0:03:57.720,0:04:01.621
focused a lot an article on just one[br]message. And it's a it's really evil. It
0:04:01.621,0:04:06.451
should not been I have been ever[br]standardized. And whenever it's used, it's
0:04:06.451,0:04:12.101
for evil purposes. There's no[br]usefulness in this message. And Tobias
0:04:12.101,0:04:16.209
quoted a number that I think The[br]Washington Post found in a lot of
0:04:16.209,0:04:21.709
marketing material, 70 percent of mobile[br]networks respond to this message. Now,
0:04:21.709,0:04:26.000
this is information from earlier this year.[br]A lot of networks, very good news, have
0:04:26.000,0:04:32.770
moved to to stop responding to anytime[br]interrogation message. This evil spying
0:04:32.770,0:04:37.509
message is not being responded to by, for[br]instance, all German networks. You can't
0:04:37.509,0:04:44.460
use this message in Germany anymore.[br]However, this is a very retroactive
0:04:44.460,0:04:51.729
approach to securing SS7 because there's a[br]number of other messages that, consider them
0:04:51.729,0:04:57.169
Gadgets, get you to the same place, take a[br]phone number and take you all the way to
0:04:57.169,0:05:03.439
somebody's location. And here's just a[br]snapshot of of which messages you can use
0:05:03.439,0:05:08.960
and Tobias went into a greater level of[br]detail in how these different messages
0:05:08.960,0:05:13.689
come together. So if anybody thinks that[br]just barring anytime integration, you
0:05:13.689,0:05:20.642
solved the tracking problem, they are wrong.[br]But at the same time, it's not that SS7 is
0:05:20.642,0:05:26.900
not secureable. It's just a much larger[br]challenge that people consider currently
0:05:26.900,0:05:33.869
to be. So you see how stringing[br]together some of these messages get you to
0:05:33.869,0:05:39.039
intermediate values that also shouldn't be[br]public and then all the way to a cell ID.
0:05:39.039,0:05:42.849
And up until all these messages or at[br]least every path that takes you from left
0:05:42.849,0:05:49.759
to right is blocked by a network, tracking[br]to the same accuracy, to cell ID stays
0:05:49.759,0:05:54.949
possible. Now, this is just one of many[br]areas in which SS7 can become an issue.
0:05:54.949,0:06:03.559
Here is 4 more, it's an intercept risk.[br]If people can read your SMS text or listen
0:06:03.559,0:06:08.169
to your calls, it's a denial of service[br]risk. If people cut you off from
0:06:08.169,0:06:13.490
phone connectivity for anywhere from an[br]hour until the next location update or
0:06:13.490,0:06:19.319
until your next reboot your phone, so you[br]can really cut people off badly from it,
0:06:19.319,0:06:24.559
from the phone network. This area of fraud[br]that I don't think many people want to
0:06:24.559,0:06:29.249
talk about publicly, certainly I don't.[br]But there's many fraud risks in SS7
0:06:29.249,0:06:34.089
in which you can easily put charges[br]on somebody else's bill, or more
0:06:34.089,0:06:39.899
interestingly, you can remove limits on[br]your own prepaid cards, basically run up
0:06:39.899,0:06:46.240
infinite charges on prepaid cards and, you[br]know, running up a lot of bills to a two
0:06:46.240,0:06:50.960
to premium numbers, for instance. And then[br]there's the risk of spamming, which from
0:06:50.960,0:06:55.930
what I hear is already happening, SS7[br]based spam attacks. Now, for the sake of
0:06:55.930,0:07:01.560
this talk, I want to focus on intercept,[br]which I consider aside from tracking the
0:07:01.560,0:07:06.099
most intrusive and the most relevant for[br]us, just as a risk, they're more relevant
0:07:06.099,0:07:09.649
for the network operators. And if they[br]don't solve them, well, so be it, as long
0:07:09.649,0:07:14.469
as they foot the bill for it. So[br]intercept. And I want to go into three
0:07:14.469,0:07:21.250
possible scenarios in which SS7 assisted[br]intercept can happen. The first abuses
0:07:21.250,0:07:24.719
the exact message, as we looked at in the[br]introduction, these messages where
0:07:24.719,0:07:29.889
different parts of networks ask each other[br]for encryption information and it's a
0:07:29.889,0:07:35.860
pretty straightforward attack. You record[br]the airwaves. Around somebody in
0:07:35.860,0:07:41.129
somebody's vicinity and you record[br]somebody's encrypted transaction as part of
0:07:41.129,0:07:47.050
that, right? So and 3G transaction, for[br]instance, are pretty well secured, but
0:07:47.050,0:07:53.080
they're not very hard to record. In fact,[br]3G is a little bit easier than 2G because
0:07:53.080,0:07:58.039
it doesn't jump around all these[br]frequencies. So you record, let's say, 3G
0:07:58.039,0:08:02.949
data and you have a bunch of transactions.[br]And all of them encrypted. And you can use
0:08:02.949,0:08:09.939
this message over SS7 to decrypt them.[br]It's called Send ID. And as a as I said on
0:08:09.939,0:08:16.129
one of the earlier slides, it's supposed[br]to be used when you're moving from one MFC
0:08:16.129,0:08:20.810
into another MSC, but still within your[br]own network so that the call doesn't get
0:08:20.810,0:08:27.099
disrupted. It's not supposed to be used[br]when when somebody foreign wants to
0:08:27.099,0:08:31.779
query your phone, if they need a new[br]encryption key, a new call needs to start
0:08:31.779,0:08:36.270
anyway. There's no way to hand over a call[br]from one operator to another operator
0:08:36.270,0:08:43.209
without disruption. So this message is[br]used only for internal purposes. However,
0:08:43.209,0:08:47.780
out of the four German operator earlier[br]this month, all four responded to this
0:08:47.780,0:08:52.100
request coming from another country,[br]another country that doesn't even border
0:08:52.100,0:08:57.170
Germany. So there's no way to even[br]conceptually think a call would be handed
0:08:57.170,0:09:03.950
over. So four out of four. And that's not[br]an anomaly. Most networks require an
0:09:03.950,0:09:08.940
international response to an[br]outside number when asked for the current
0:09:08.940,0:09:14.030
decryption key. I'll show you a quick demo[br]on this at the end of this chapter.
0:09:14.030,0:09:17.650
But I first finish the enumeration of[br]all the different possibilities in which
0:09:17.650,0:09:24.920
3G calls can be intercepted. The second[br]one, the good old IMSI catchers, which we
0:09:24.920,0:09:31.540
also wouldn't work on 3G. And I guess for[br]the most part they don't unless SS7
0:09:31.540,0:09:36.010
comes to the help. So why don't they[br]work without SS7? An IMSI catcher
0:09:36.010,0:09:42.070
pretends to be a base station. And if[br]it's 2G technology, the phone has no way
0:09:42.070,0:09:47.720
of knowing the difference between the real[br]base station and a fake base station. But
0:09:47.720,0:09:53.180
then 3G, the 3G standard introduced what I[br]call mutual authentication. So this time
0:09:53.180,0:09:57.630
the base station has to prove to a phone[br]that in fact it's legitimate and unless it
0:09:57.630,0:10:03.530
does that, the phone won't connect. Now,[br]this only solves part of the IMSI catcher
0:10:03.530,0:10:08.530
problem. Just taken by the name even the[br]catching is still possible, IMSI catching
0:10:08.530,0:10:14.660
in the sense of creating a list of all the[br]IMSIs in a location. Because there's
0:10:14.660,0:10:19.150
certain chicken and egg problem.[br]If you want me as a base station to
0:10:19.150,0:10:23.430
authenticate to you, you first have to[br]tell me who you are. There's no such thing
0:10:23.430,0:10:28.370
as SSL or any type of public key on the[br]mobile network. It's all symmetric key. So
0:10:28.370,0:10:32.900
you first have to tell me which key to use[br]and by that I know who you are. So IMSI
0:10:32.900,0:10:36.811
catching is always possible. And that's why[br]if you Google for 3G IMSI catcher, those
0:10:36.811,0:10:43.240
things exist. But they aren't capable of[br]recording phone calls or SMS because those
0:10:43.240,0:10:49.080
then required a mutual authentication. They[br]aren't capable of doing so unless they ask
0:10:49.080,0:10:55.960
over SS7 for an authentication key. So[br]IMSI catchers are back in the 3G world
0:10:55.960,0:11:05.328
big time, unless we solve these SS7[br]problems, right? The third possibility of
0:11:05.328,0:11:10.880
of intercept - this is probably the[br]scariest because it can happen completely
0:11:10.880,0:11:15.470
remotely - Boaster once enumerated so far,[br]you have to be somewhere in the vicinity
0:11:15.470,0:11:19.540
in the vicinity of somewhere. So the third[br]possibility, I want to call the rerouting
0:11:19.540,0:11:24.640
attacks and they work in both directions.[br]Rerouting is the idea. And to be as
0:11:24.640,0:11:31.270
touched on this, of taking… of taking[br]somebodies phone calls and changing
0:11:31.270,0:11:36.799
the destination number so that, in fact,[br]you call somebody else unbeknownst to you,
0:11:36.799,0:11:42.590
of course, as the victim. And this will[br]expose for incoming calls and outgoing
0:11:42.590,0:11:46.600
calls, but using very different methods.[br]So it just kind of accidentally works in
0:11:46.600,0:11:52.970
both directions. And this part, I just[br]briefly want to demonstrate to BSN that
0:11:52.970,0:11:56.870
coordinated on most of this. But this[br]part, I guess we kind of misunderstood
0:11:56.870,0:12:01.870
each other as we both showed us. I'll[br]keep this very brief. And the point I want
0:12:01.870,0:12:07.998
to get across is that, one, a single SS7[br]message is already a big intercept
0:12:07.998,0:12:15.660
problem. Let's see. Connected here. Um, so[br]I'll try not to make the same mistake as
0:12:15.660,0:12:26.600
Tobias and try to cut off part of my[br]number here. So 31C3 demo phone.
0:12:26.600,0:12:32.713
So I'm calling a a phone that in fact,[br]accidentally we left in. So … fuck
0:12:32.713,0:12:36.190
Laughter and applause[br] Ring-back tone starts
0:12:36.190,0:12:40.491
So I am calling this number and I don't [br]know if you can hear it, but it's ringing.
0:12:40.491,0:12:43.813
And we did leave his phone back in Berlin[br]accidentally. But for the sake of this
0:12:43.813,0:12:48.100
demo, that makes no difference. So it's a [br]it's a phone somewhere in Berlin. Nobody
0:12:48.100,0:12:50.912
answers to. Here is another phone.
0:12:50.912,0:12:52.002
Ring-back tone stops
0:12:52.002,0:12:54.329
So if I if I register what they call a
0:12:54.329,0:13:01.220
supplementary service to this number. And [br]that's just fancy language for, for, for
0:13:01.220,0:13:09.392
call forwarding, if I call this exact same[br]number again.
0:13:13.758,0:13:16.659
Ring-back tone starts
0:13:16.659,0:13:18.877
Phone ringing also starts
0:13:18.877,0:13:21.140
This phone is ringing.
0:13:21.140,0:13:23.930
Applause
0:13:23.930,0:13:25.800
Both ring-back and ring-tone stop
0:13:25.800,0:13:28.059
Still applause
0:13:28.059,0:13:33.120
Now, of course, to make this real[br]intercept, I wouldn't forward it to a
0:13:33.120,0:13:37.740
phone, I would forward it to a computer[br]that then is smart enough to very quickly
0:13:37.740,0:13:43.960
erase the call forwarding and call the[br]original number and then connect it to so
0:13:43.960,0:13:48.260
that the phone, the phone call actually[br]goes to where it was supposed to go. Just
0:13:48.260,0:13:53.451
I'm sitting in the middle and I'm[br]receiving a copy of it. OK, so that's the
0:13:53.451,0:13:57.710
idea in this direction, in the other[br]direction, the exact same thing works as
0:13:57.710,0:14:03.875
well. And Tobias already told you how [br]these services that say, let me rewrite
0:14:03.875,0:14:07.510
your phone number for you because you [br]don't know how to dial a phone number when
0:14:07.510,0:14:12.279
you're on vacation. Right. Those services[br]can be set by anybody, at least on a lot
0:14:12.279,0:14:16.880
of networks. And you can see how the exact[br]same thing works there so that every time
0:14:16.880,0:14:21.430
you dial a number that just move their own[br]number in place of that number and then
0:14:21.430,0:14:26.912
connect those two calls. So, as I said, I[br]consider those to the scariest type of
0:14:26.912,0:14:30.680
attacks because they were completely[br]remotely you don't have to be in the radio
0:14:30.680,0:14:35.140
vicinity of anybody. And surprisingly,[br]this still works against a bunch of
0:14:35.140,0:14:41.690
networks, even against those networks that[br]move to solve some of the earlier issues.
0:14:41.690,0:14:49.285
So networks [are] still very retroactive.[br]So what do what do those mobile networks
0:14:49.285,0:14:54.920
now have to do to to solve those issues? [br]Well, as always, of course, the answer:
0:14:54.920,0:14:59.921
It depends. It depends in this case on the[br]tech type. Some of the techs can simply be
0:14:59.921,0:15:05.710
blocked. Like the AnytimeInterrogation,[br]that earlier this year they said 70% of
0:15:05.710,0:15:10.170
the networks are vulnerable. Now in[br]Germany it's zero. So something happened
0:15:10.170,0:15:16.440
there. And the same is true for the for[br]the first type of attack that I've shown.
0:15:16.440,0:15:20.550
The passive intercept I said when we[br]tested earlier this month for other four
0:15:20.550,0:15:27.100
networks are vulnerable. Now it's down to[br]two. So within two weeks, two networks put
0:15:27.100,0:15:33.970
in a firewall rule that says this message[br]has no purpose. Traversing our outside
0:15:33.970,0:15:39.940
network boundary, just block it. The[br]typical firewall is the same isn't
0:15:39.940,0:15:45.100
possible for these other two types of[br]attacks because those messages are
0:15:45.100,0:15:50.550
actually useful. They do something, at[br]least in certain circumstances. If you
0:15:50.550,0:15:55.210
block the second type of query here to[br]send authentication info, you couldn't be
0:15:55.210,0:15:58.930
roaming in another country anymore. If you[br]blocked a third one, you couldn't be
0:15:58.930,0:16:04.400
changing your your voice mail forwarding[br]from another country anymore. So these are
0:16:04.400,0:16:10.390
needed. Still we couldn't, we can't accept[br]that just anybody who asks over SS7 ...
0:16:10.390,0:16:11.990
Phone ringing [br] Nohl sighs
0:16:11.990,0:16:15.658
You guys![br] Laughter
0:16:15.658,0:16:23.750
Switched this off. We can't accept[br]that just anybody who asks over SS7
0:16:23.750,0:16:29.370
receives an answer, at the very least[br]we would expect networks to only answer to
0:16:29.370,0:16:33.500
their friends on SS7, and[br]that is their roaming partners. That's
0:16:33.500,0:16:38.980
already a lot fewer companies and[br]especially a lot fewer sketchy companies
0:16:38.980,0:16:44.791
than everybody else on SS7. We would[br]then want those networks to do some
0:16:44.791,0:16:51.390
plausibility checking. Right. So this does[br]phone in Berlin that just put a
0:16:51.390,0:16:56.670
supplementary service on. The network[br]operator knows the phone is in Berlin and
0:16:56.670,0:17:02.760
I send us from the other end of the world.[br]Still, they are not on it. Right. Any type
0:17:02.760,0:17:08.310
of possibility checking what would clearly[br]see that this is not possible for a phone
0:17:08.310,0:17:12.760
to be in one country and for this user to[br]want to change their voicemail setting
0:17:12.760,0:17:17.809
from somewhere completely different. And[br]then thirdly, networks need to limit the
0:17:17.809,0:17:22.020
rate at which this happens. Those services[br]that The Washington Post talked about is
0:17:22.020,0:17:26.240
tracking services. These are large[br]operations. They seem to be tracking
0:17:26.240,0:17:33.620
thousands of people, constantly. This will[br]show in logs, you don't allow some random
0:17:33.620,0:17:38.300
network somewhere else in the world to[br]constantly interrogate hundreds of your
0:17:38.300,0:17:44.200
users, right? It's clearly abuse. Has any[br]network move to put such sensible rules
0:17:44.200,0:17:48.429
in? I'm not aware of it, but it's[br]certainly the next step. And I'm not ready
0:17:48.429,0:17:54.860
to give up on SS7 yet. I've heard one too[br]many times that SS7 is an old technology
0:17:54.860,0:18:01.389
built with no security in mind and we just[br]can't fix it. The Internet also is an old
0:18:01.389,0:18:06.399
technology built was not secured in mind,[br]and we did fix it since the 90s, since
0:18:06.399,0:18:10.679
when you connected to Windows 95 computer[br]to the Internet, it got infected with the
0:18:10.679,0:18:16.580
virus right away. We have moved to put in[br]firewalls. We're not exposing our printer
0:18:16.580,0:18:21.190
daemon and now file-sharing daemon on the [br]entire Internet anymore for four billion
0:18:21.190,0:18:25.680
people to connect to and the same as[br]possible on SS7. Which is, we we're still
0:18:25.680,0:18:34.508
in the nineties. Thank you.[br] Applause
0:18:34.508,0:18:38.484
Having said that though, let me show you[br]what what happens if we don't do that,
0:18:38.484,0:18:46.972
the fun part. So. We argued whether or not[br]we wanted to show this as a live demo.
0:18:46.972,0:18:50.096
You'll understand why we don't show it as[br]a live demo. There is just too much stuff
0:18:50.096,0:18:54.470
that could go wrong. But here's the setup.[br]We start with just a phone number
0:18:54.470,0:19:00.389
and we want to string together a couple of[br]SS7 gadgets while also having this radio
0:19:00.389,0:19:05.105
handy that can capture 3G information to[br]capture yet more information that's not
0:19:05.105,0:19:10.870
available over SS7. Right. So we start[br]with a phone number and we send what's
0:19:10.870,0:19:18.195
called an SRI-for-SM message, which gives[br]us, if the network is configured answer,
0:19:18.195,0:19:26.441
the IMSI and the MSI that the subscriber[br]currently is connected for. Those two are
0:19:26.441,0:19:31.001
used as parameters into another call.[br]Called the PSI message, provide
0:19:31.001,0:19:37.191
subscriber info. And then that call then [br]gives us the Cell ID. This is just how
0:19:37.191,0:19:41.440
you get more and more information with[br]different gadgets. Now the Cell ID tells
0:19:41.440,0:19:45.840
us where somebody is physically. So imagine[br]we now move our radio to that
0:19:45.840,0:19:54.309
location and we again send a PSI. We record[br]the PSI. We set radio, not the PSI, what
0:19:54.309,0:19:59.779
happens over the airways when we send the[br]PSI and the phone gets paged. So when we
0:19:59.779,0:20:05.889
send the PSI over SS7, the phone receives[br]some information. Right. This radio plus a
0:20:05.889,0:20:11.070
little bit GNU radio scripting gives us[br]that information: Who has been paged
0:20:11.070,0:20:18.749
during that short window of time that we[br]that we recorded? Now when we record
0:20:18.749,0:20:22.929
something on UMTS, we always record for[br]different cells – they share frequencies.
0:20:22.929,0:20:27.419
But you see that the one cell with the [br]Cell ID came back over SS7 is included
0:20:27.419,0:20:33.012
in our set. So we filter the data for[br]that cell and we look for which IMSIs are
0:20:33.012,0:20:36.739
included. And luckily for us, only one[br]IMSI got paged within those few
0:20:36.739,0:20:43.490
seconds on that cell. It's the same. Same.[br]This is now the TMSI that belongs to
0:20:43.490,0:20:48.600
this phone. This is information we can't[br]get over SS7. But what you can do over SS7
0:20:48.600,0:20:54.710
with the TMSI is request a key, so it gets[br]complicated. But so we have the decryption
0:20:54.710,0:21:00.250
key now and the next time this phone[br]receives something, unless it changes the
0:21:00.250,0:21:04.500
key, in which case we can ask again for[br]a new key. Next time this phone receives
0:21:04.500,0:21:07.279
something. And what you don't see in the[br]video is, somebody is now sending a text
0:21:07.279,0:21:12.129
message to the phone. We can also record[br]that right. Again, same radio, the one
0:21:12.129,0:21:17.990
shown in the picture, now the phone that[br]received a text message. And there's a few
0:21:17.990,0:21:26.980
more steps. So the phone received a text[br]message and we also, again, recorded the
0:21:26.980,0:21:38.629
airwaves. We again run it through some GNU[br]radio script. Now, was was UMTS
0:21:38.629,0:21:42.529
everything? It is kind of complicated, so[br]there's a different connection, of
0:21:42.529,0:21:45.779
course, happening all at the same time,[br]and then they'll get allocated to
0:21:45.779,0:21:49.999
different channels. So now, in order to to[br]decode this text message, we're going to
0:21:49.999,0:21:55.950
find out which channel is used. So this[br]command gives us the list of which which
0:21:55.950,0:22:00.909
channels have been allocated. And we got[br]to find a TMSI from earlier in one of
0:22:00.909,0:22:06.040
these channel allocations. And Wireshark[br]is a great help in this. We didn't have to
0:22:06.040,0:22:11.050
do anything with Wireshark. I just knows[br]all that 3G stuff right out of the box. So
0:22:11.050,0:22:14.970
luckily, the first of these five[br]connecting requests is the right one and
0:22:14.970,0:22:19.379
scroll all the way down, there's then the[br]parameters that say which channel this
0:22:19.379,0:22:23.919
transaction happened on. So those two[br]numbers, 15 and 48 is the channel. So we,
0:22:23.919,0:22:31.324
we need to cell frequency, but we need[br]those those two two numbers, that, that
0:22:31.324,0:22:36.749
are the channel and the key, you know,[br]this is only 64 bit. I'll discuss that
0:22:36.749,0:22:46.675
a little later. And that's all we need to[br]decrypt an SMS. And there it is.
0:22:46.675,0:22:55.382
Applause [br]Thank you.
0:22:57.359,0:23:03.540
This still works today, but only against[br]two out of the four German networks. Some
0:23:03.540,0:23:10.351
of them move to to to stop some of these[br]messages, of course, most importantly,
0:23:10.351,0:23:14.940
this SI message that gives you the[br]decryption key. But even if you block this
0:23:14.940,0:23:22.539
message, just acquiring somebody's[br]location can already be intrusive enough.
0:23:22.539,0:23:27.389
All right. Moving on to 3G security or[br]rather extending on 3G security since this
0:23:27.389,0:23:34.919
already touched through 3G in a big way.[br]You remember the good old days where where
0:23:34.919,0:23:40.489
you could just intercept all phone calls[br]was the Osmocon phone. Thank you, by the
0:23:40.489,0:23:45.059
way, for that open source project that[br]helped us so much over the years. And you
0:23:45.059,0:23:52.849
combine that with the kraken software to[br]decrypt the phone call. So with 20 year
0:23:52.849,0:23:57.919
old vers of phone and the server you can[br]listen to anybody's GSM calls as long as
0:23:57.919,0:24:03.940
they're using the A5/1 cipher. Some[br]networks recently moved into A5/3.
0:24:03.940,0:24:10.720
So it doesn't work this way anymore. Now,[br]how does this now compare to 3G security?
0:24:10.720,0:24:16.039
As I've just shown, basically the same[br]attacks are possible. Instead of the
0:24:16.039,0:24:21.419
Osmocom phone, we use a programable radio,[br]some more software, but again, very
0:24:21.419,0:24:26.509
affordable 400 euros or[br]something. And you combine that using
0:24:26.509,0:24:34.409
instead of kraken SS7 queries. So unless[br]we fix SS7, 3G is no more secure than 2G
0:24:34.409,0:24:41.460
and neither is A5/3, the recent[br]upgrade of GSM because those keys are
0:24:41.460,0:24:50.500
again exposed over SS7. Now, some[br]networks, you don't even need that second
0:24:50.500,0:24:57.559
part, so they have bigger things to worry[br]about and then SS7 attacks and our data
0:24:57.559,0:25:01.919
set isn't all that large. Some of you[br]provided measurements through through a
0:25:01.919,0:25:07.260
software release last year. So thank you[br]very much for that. And we have captures
0:25:07.260,0:25:14.619
from maybe 20, 25 countries out of those[br]five having to use no 3G encryption at
0:25:14.619,0:25:21.200
all. Well, four countries. Five network[br]operators. Right. Which I find shocking.
0:25:21.200,0:25:26.249
Some of these even have encryption turned[br]on on their GSM network and then forgot to
0:25:26.249,0:25:31.216
turn it on or deliberately left it out[br]because it's harder to intercept on the 3G
0:25:31.216,0:25:38.330
variant. Right. So those networks, as I [br]said, have much more, much more worrisome
0:25:38.330,0:25:45.350
issues than SS7 attacks. And they really[br]need to be called out. And we do that with
0:25:45.350,0:25:49.659
an extension of a website that we've been[br]maintaining for a couple of years, gsmmap,
0:25:49.659,0:25:55.860
big update of gsmmap launched today[br]with all the 3G measurements, we, we
0:25:55.860,0:26:01.590
collected and you collected over the last[br]couple of years. Now, some of you may have
0:26:01.590,0:26:07.951
used gsmmap before. The idea as to to rank[br]operators in the three categories. How
0:26:07.951,0:26:13.509
hard is it to intercept phone calls and[br]SMS? Is it easy to impersonate a person
0:26:13.509,0:26:17.950
and then put charges on a bill, for[br]instance, or receive the calls? How hard
0:26:17.950,0:26:22.760
is it to track them? And as you see, over[br]the last years, networks have improved
0:26:22.760,0:26:31.220
their security, at least some, as always.[br]God. And as you also see, these are the 2G
0:26:31.220,0:26:39.049
networks, even the best secure 2G network.[br]And in Germany anyway, in our opinion, is
0:26:39.049,0:26:44.450
less secure than the worst secured 3G[br]networks. These are for 3G networks, still
0:26:44.450,0:26:50.399
we want networks to implement all security[br]features. And as you saw before, some
0:26:50.399,0:26:57.399
other countries don't have that luxury of[br]all 3G secure networks reasonably secure.
0:26:57.399,0:27:01.909
Not the first version of our metric is[br]very crude and we want to improve upon
0:27:01.909,0:27:06.210
this over time. But currently how we[br]calculate the score is we'll give ninety
0:27:06.210,0:27:10.779
percent of the points to anybody who[br]switches on encryption. That's the main
0:27:10.779,0:27:16.330
security feature and the remaining 10[br]percent you earn by changing the TMSI
0:27:16.330,0:27:22.149
quickly. TMSI is what we needed for these[br]SS7 attacks to work well. So if you keep
0:27:22.149,0:27:28.440
changing it, it really confuses the that[br]the person trying to to haunt you also
0:27:28.440,0:27:32.559
this makes other types of attacks more[br]difficult, will factor in a couple of more
0:27:32.559,0:27:38.989
values as we collect more data. But this[br]is it for now. So, yeah, big update on
0:27:38.989,0:27:43.880
gsmmap. If you haven't checked it out,[br]check out your country on gsmmap, read the
0:27:43.880,0:27:52.149
country report. So does a six page or so[br]report, auto generated, that explains what
0:27:52.149,0:27:56.759
types of measurements we included into[br]into these graphs and why we think they
0:27:56.759,0:28:01.529
they constitute certain risks. Maybe[br]forward it to to your network and say if
0:28:01.529,0:28:08.870
you're not improving, I'm going to change,[br]switch to another network. Now, not
0:28:08.870,0:28:14.210
everything is on, on gsmmap yet because we[br]don't have enough data. And there's one
0:28:14.210,0:28:19.080
problem in particular that I want to start[br]warning about, because I really think
0:28:19.080,0:28:24.399
we're running into an issue here. And that[br]is the lengths of encryption key you saw
0:28:24.399,0:28:29.759
in the in the capture, in the video data[br]that I showed that the key that came back
0:28:29.759,0:28:37.419
over SS7 was actually only 64bit from this[br]particular network. And the SIM card that
0:28:37.419,0:28:41.440
was there was used in this attack, was[br]bought that very same week. So we recorded
0:28:41.440,0:28:46.039
this video last week. So it's the the most[br]recent SIM card you can buy from this
0:28:46.039,0:28:51.340
network. And still it only uses 64 bit.[br]And that, in my view, is incompatible with
0:28:51.340,0:28:57.710
what we have learned from from recent[br]Snowden documents that the NSA in 2011,
0:28:57.710,0:29:06.149
2012 funded a project to break A5/3.[br]This is a 64 bit cipher. And we had
0:29:06.149,0:29:09.919
estimated at this very conference a year[br]ago that you'd need about a million
0:29:09.919,0:29:14.759
dollars to break A5/3. Now, they[br]did it a little bit earlier. So Moore's
0:29:14.759,0:29:19.300
Law, everything's more expensive and[br]probably to have overhead, too. But they
0:29:19.300,0:29:25.000
spend apparently four billion pounds. I[br]don't know why pound, not dollars, but it
0:29:25.000,0:29:31.200
may have been some GCHQ Corporation. So[br]for four million pound a couple of years
0:29:31.200,0:29:36.791
ago, you could already break 64 bit crypto and[br]64 bit is more prevalent in mobile
0:29:36.791,0:29:44.499
networks than you would have thought when[br]they upgraded the GSM networks to A5/3.
0:29:44.499,0:29:49.342
They didn't actually upgraded it to UMTS[br]security, as everybody claimed they did.
0:29:49.342,0:29:57.771
They upgraded it to the cipher used in[br]UMTS with a key half the size. When
0:29:57.771,0:30:02.958
writing the A5/3 standards though, the [br]people were smart enough to also put in
0:30:02.958,0:30:10.669
the real UMTS cipher with full key size, [br]they called it A5/4 and it has never
0:30:10.669,0:30:15.029
been seen anywhere since. It's written in [br]the standard. It was released the same day
0:30:15.029,0:30:20.960
that A5/3 was released. Nobody has ever[br]moved to implement that. So GSM for the
0:30:20.960,0:30:26.049
time being is and will be vulnerable to[br]anybody. It was a one million dollar
0:30:26.049,0:30:30.911
machine in the basement. Certainly NSA,[br]but more and more people as we move
0:30:30.911,0:30:34.570
forward. And what costs a million dollars[br]today, thanks to Moore's Law in a couple
0:30:34.570,0:30:40.869
of years, anybody can break it on a[br]computers like we today. Break the A5/1.
0:30:40.869,0:30:45.649
If your network uses certain older[br]SIM cards, differentiation years between a
0:30:45.649,0:30:52.529
SIM card and a USIM as a UMTS SIM card.[br]If your network only uses SIM cards, then
0:30:52.529,0:30:59.590
even your 3G transactions are 64 bit[br]encrypted. So there is no way to generate
0:30:59.590,0:31:02.960
more entropy. You could query for two[br]keys, I guess, but they weren't smart
0:31:02.960,0:31:10.730
enough to do that. So 64 bit encryption[br]for UMTS and that's just not good enough.
0:31:10.730,0:31:15.309
And as I said, the network that we did [br]the demo with we were surprised to see a
0:31:15.309,0:31:20.700
64 bit key. We went back in our database[br]of SIM cards. We found a lot of SIM cards
0:31:20.700,0:31:25.027
that have this problem. We want to add[br]this to gsmmap, but we don't want to be
0:31:25.027,0:31:29.214
unfair just because we see one very old SIM [br]card in the network. We don't want to give
0:31:29.214,0:31:32.987
them a low score versus somebody else,[br]where we only see a new card. So we need
0:31:32.987,0:31:38.596
lots and lots of data. Help us collect [br]those data and we'll make it public.
0:31:38.596,0:31:44.345
Now, that's one reason why we stay on this[br]ball and progress the research. The other
0:31:44.345,0:31:49.405
main reason, and this is really what keeps[br]us awake at night is this question of
0:31:49.405,0:31:57.120
how can we get out of the mess. We've been[br]producing more and more problems. I should
0:31:57.120,0:32:02.679
not say produce, we make you aware of more[br]and more problems over the years and we
0:32:02.679,0:32:06.570
always criticize that at least many[br]networks do not respond to those. So we
0:32:06.570,0:32:11.860
have to stockpile ever growing stockpile[br]of mobile security issues and nobody seems
0:32:11.860,0:32:15.889
to be addressing. And all we do is wait[br]for our networks to do something
0:32:15.889,0:32:20.630
eventually. Now waiting's over for me, at[br]least I'm impatient. I want to do
0:32:20.630,0:32:25.789
something now and I want to address all[br]these issues all at once. Those issues
0:32:25.789,0:32:31.169
that we talked about for several years[br]now, including the SIM card attacks from
0:32:31.169,0:32:39.739
last year, silent SMS based tracking the[br]SMS, the SS7 abuse discussed today,
0:32:39.739,0:32:46.340
IMSI Catcher Vulnerabilities and[br]insufficiently configured networks, 2G as
0:32:46.340,0:32:53.250
well as 3G. All of these problems have one[br]thing in common. Your phone technically
0:32:53.250,0:32:58.269
knows that these attacks are happening and[br]your phone technically knows that a
0:32:58.269,0:33:03.999
network is configured insecurely. But[br]unfortunately it's buried very deep inside
0:33:03.999,0:33:07.869
the phone. It's buried inside the[br]baseband. So as much as you can program
0:33:07.869,0:33:12.259
Android, you don't get access to that[br]information. At least so we saw it and
0:33:12.259,0:33:16.769
then we set out and just took the better[br]part of this year. We wanted to dig the
0:33:16.769,0:33:21.019
information out from these phones. It's[br]somewhere in there. There must be some way
0:33:21.019,0:33:27.321
to hack it out of it. And we found debug[br]possibilities for Qualcomm chipsets, just
0:33:27.321,0:33:31.309
one vendor, but extremely popular. Right[br]now. There seem to be in every LTE phone
0:33:31.309,0:33:36.809
and in a bunch of other phones. And we[br]found, we found ways of producing exactly
0:33:36.809,0:33:42.539
all the data on the right hand side to[br]make it accessible through an Android
0:33:42.539,0:33:48.060
application. And we also wrote an[br]application for you. So: Release today.
0:33:48.060,0:33:57.695
Applause
0:33:57.695,0:34:05.139
Thank you, released today, SnoopSnitch[br]under GPL. A tool that collects all the
0:34:05.139,0:34:09.860
baseband information mostly to keep it[br]on the phone and run some analysis on it,
0:34:09.860,0:34:15.320
warn you about, as I said, SIM card[br]attacks, but also those SS7 attacks that
0:34:15.320,0:34:19.750
Tobias and I talked about today. How do[br]you take those those attacks? Well, by the
0:34:19.750,0:34:24.820
pagings, I showed you in the video[br]that every time we send certain queries to
0:34:24.820,0:34:30.169
the phone, to, over SS7, that the phone[br]actually also receives information useful
0:34:30.169,0:34:35.120
for the attacker. Also useful for the[br]defender. If those empty pagings, we call
0:34:35.120,0:34:38.990
them, are received by the phone, strong[br]evidence that somebody is messing with you
0:34:38.990,0:34:46.890
over SS7. Right. So it collects all that[br]information and it produces warnings. You
0:34:46.890,0:34:52.624
can also upload information issues, so you[br]choose. It's optional of course, it runs,
0:34:52.624,0:34:57.310
as I said, on a bunch of Android phones[br]that are currently popular. It requires a
0:34:57.310,0:35:01.603
somewhat recent Android version we haven't[br]tested was Android 5 yet, but I don't
0:35:01.603,0:35:05.170
see why it wouldn't work, though. We just[br]have to put the time and your phone needs
0:35:05.170,0:35:11.240
to be routed. So we have access to a[br]certain interface that otherwise is not
0:35:11.240,0:35:16.270
accessible. And it needs of course, a[br]Qualcomm chipset, which, as you see by
0:35:16.270,0:35:21.650
this list, is in most current flagship[br]phones. It's on Google Play right now. So
0:35:21.650,0:35:29.080
download it if you're interested. Now, how[br]does this tool work? One example only, of
0:35:29.080,0:35:34.500
course, right, read the source code if you[br]if you want to know the rest. If you, for
0:35:34.500,0:35:38.750
instance, IMSI catcher detection. There[br]have been a bunch of tools so far to do
0:35:38.750,0:35:43.980
IMSI catcher detection. The one we released[br]a couple of years ago was called CatcherCatcher,
0:35:43.980,0:35:49.740
but it had two limitations. One[br]practical, one more bound to experience.
0:35:49.740,0:35:54.790
The practical limitation was that it ran[br]on Osmocom phones and Osmocom phones can't
0:35:54.790,0:35:59.120
do most phone functionality. So always[br]your second phone? And it had to be
0:35:59.120,0:36:03.350
connected to a computer. So very unlikely[br]that you carried this around all the time.
0:36:03.350,0:36:07.411
And we wanted to move it onto a real phone[br]that you can use onto your phone. Right? I
0:36:07.411,0:36:11.690
think we succeeded in that. The second[br]limitation was that we really didn't know
0:36:11.690,0:36:16.440
how IMSI catchers behaved or we also[br]didn't know how real networks behaved. And
0:36:16.440,0:36:20.640
thanks to all the data on gsmmap, we think[br]we have a much better understanding now of
0:36:20.640,0:36:24.880
all the weird corner cases, how real[br]networks behave and created a much better
0:36:24.880,0:36:32.890
ruleset for for an Android based catcher[br]catcher tool now. And the rules go in two
0:36:32.890,0:36:37.111
categories. One is the configuration of[br]the of these different cells. For
0:36:37.111,0:36:41.760
instance, the lack of encryption when, you[br]know, from the gsmmap database that this
0:36:41.760,0:36:46.473
network does usually support encryption,[br]that's a big red flag. Also certain other
0:36:46.473,0:36:51.180
configurations. So that's a configuration[br]of the network, the adjusted behavior and
0:36:51.180,0:36:53.800
the IMSI catcher wants to get[br]information out from you at the very
0:36:53.800,0:36:58.290
least, the IMSI, of course, it's in the[br]name. Right. So that suspicious behavior
0:36:58.290,0:37:04.955
now, none of these things taken by[br]themselves did allow you to detect an
0:37:04.955,0:37:09.860
IMSI catcher. So we compute score over[br]these different events, doing stream
0:37:09.860,0:37:14.830
analysis on everything that happens on[br]your phone and eventually then come out
0:37:14.830,0:37:20.820
with a warning. If the score crosses a[br]certain threshold, there's a bunch more we
0:37:20.820,0:37:25.030
would have wanted to include that's even [br]on a Qualcomm chipset in it's debug mode
0:37:25.030,0:37:29.960
not available. So this is still ongoing work[br]as these chipsets progress and may give
0:37:29.960,0:37:37.168
us more information in the future. Now, if[br]you do find alerts, let's call them alarms
0:37:37.168,0:37:41.044
on your phone. We'd be grateful if you[br]could share them. Now, as I said, this is
0:37:41.044,0:37:48.080
optional, right? You get you get the[br]alerts shown in shown in your little tool
0:37:48.080,0:37:52.730
and then you can choose to upload[br]whichever ones you think should be shared
0:37:52.730,0:37:59.697
if we get enough of them and and think[br]that there's really hot spots of of of
0:37:59.697,0:38:03.419
abuse, of course, we'll try to make that[br]transparent, perhaps even put little dots
0:38:03.419,0:38:07.950
on the GSM website so people know where[br]abuse could be happening around
0:38:07.950,0:38:20.370
demonstrations, around embassies, wherever.[br]Applause
0:38:20.370,0:38:23.410
You can also actively choose to
0:38:23.410,0:38:28.090
submit data by by running an active test[br]now usually the phone looks at everything
0:38:28.090,0:38:32.370
that you produce, your phone calls, your[br]SMS that's always stored on the phone.
0:38:32.370,0:38:37.880
There's no way to upload that. And you[br]compute a score for how secure your
0:38:37.880,0:38:42.410
network is using the exact same metrics[br]that we use on gsmmap. So that's all
0:38:42.410,0:38:47.410
ported to the phone now. But if you feel[br]like the score on gsmmap is heavily outdated,
0:38:47.410,0:38:51.860
click this button. It runs some benign tests, [br]has nothing to do with your transactions. I
0:38:51.860,0:38:55.640
guess your location where you're currently[br]connected would be included in the data
0:38:55.640,0:39:02.030
and it uploads it to gsmmap. So that[br]becomes better and better. And we can spot
0:39:02.030,0:39:09.780
more networks that, for instance, like any[br]encryption at all. Yeah, so what's what
0:39:09.780,0:39:15.370
what are you what I like you to do, I[br]think you should do to better protect
0:39:15.370,0:39:20.076
yourself from mobile abuse, of course you[br]could keep waiting for your mobile
0:39:20.076,0:39:24.900
networks to fix all these issues, which I[br]must say more recently, more networks have
0:39:24.900,0:39:30.150
moved to fix issues, but still not the[br]majority. And no network has even started
0:39:30.150,0:39:35.550
to address the majority of issues. So it's[br]just scratching the surface. So what I'd
0:39:35.550,0:39:41.770
rather have you do is start defending[br]yourself. Check out gsmmap, see if you
0:39:41.770,0:39:45.800
are on a network that generally protects[br]things like encryption. You saw the
0:39:45.800,0:39:51.750
networks that lack encryption. Don't use[br]those. And if you really choose to self
0:39:51.750,0:39:58.241
defense, download, SnoopSnitch, this new[br]tool and actively look out for abuse, for
0:39:58.241,0:40:03.080
Silent SMS, binary SMS that you receive,[br]for empty pagings, for IMSI catcher
0:40:03.080,0:40:10.490
evidence and help us grow this database of[br]abuse. Right. Also help us grow the
0:40:10.490,0:40:15.720
tool base that we use. This is released[br]open source and we put in a lot of work to
0:40:15.720,0:40:20.710
make the data accessible. But now it is[br]accessible, right? Just take it as a
0:40:20.710,0:40:26.920
library and go wild with it. Do whatever[br]you always wanted to do with raw baseband
0:40:26.920,0:40:34.300
data on 2G, 3G, 4G. I am very much looking[br]forward to your contributions to this and
0:40:34.300,0:40:37.720
all that's left for me to say is thank you[br]very much.
0:40:37.720,0:40:47.570
applause
0:40:47.570,0:40:57.240
Herald: Thank you, Karsten, then we will[br]beginning with the Q&A, please, for
0:40:57.240,0:41:03.590
everybody that will be asking questions,[br]please line up on the microphones in the
0:41:03.590,0:41:13.660
room and for people that exit the room,[br]please do it with no noise and quickly.
0:41:13.660,0:41:17.390
Karsten: Now, before getting into the[br]question, let me give you one reason to
0:41:17.390,0:41:22.520
actually do leave now. There's a workshop[br]happening right now or in a few minutes
0:41:22.520,0:41:27.850
that will explain how this tool works and[br]what it can all do. We'll have an IMSI
0:41:27.850,0:41:31.240
catcher there a day or so. You can tell us[br]how that feels like being connected to an
0:41:31.240,0:41:36.210
IMSI catcher. It's happening in room C,[br]which is when you exit here one floor
0:41:36.210,0:41:41.750
down and to this end.[br]Herald: And additional information, the
0:41:41.750,0:41:51.407
workshop that's Karsten says start at[br]nineteen forty five.
0:41:51.407,0:42:00.050
K: And now to your questions.[br] distant noise
0:42:00.050,0:42:04.800
K: Sure.[br]Herald: OK, microphone number two and
0:42:04.800,0:42:10.460
please, before before we before you can[br]start number two, please do it with no
0:42:10.460,0:42:19.270
noise that we hear the question from the[br]audience. OK, number two, please.
0:42:19.270,0:42:23.260
Mic 2: Thank you. Can you quickly say a[br]few words about why it wouldn't work on
0:42:23.260,0:42:27.610
custom ROMs? Because we could just install[br]it into cyanogen phones and apparently
0:42:27.610,0:42:34.750
installed and it seems to work.[br]K: Oh, OK. So the way I understood custom
0:42:34.750,0:42:38.920
ROMs is that they first remove a bunch of[br]stuff from the phone and then put a bunch
0:42:38.920,0:42:44.025
of stuff on it. Part of what we need are[br]these proprietary Qualcomm libraries and
0:42:44.025,0:42:47.050
at least on the phones where we tried[br]cyanogen mod and what they are being
0:42:47.050,0:42:51.730
removed. So if cyanogen mod could stop[br]doing that, it would work beautifully.
0:42:51.730,0:42:56.430
It's not that we need anything additional.[br]We just need less to be deleted.
0:42:56.430,0:43:04.290
Mic 2: OK, thank you.[br]Herald: OK. Microphone number …, will you
0:43:04.290,0:43:09.760
ask. OK, are there some questions from the[br]IRC?
0:43:09.760,0:43:16.090
K: I think we have a bunch of questions.[br]Signal Angel: Actually, there is five
0:43:16.090,0:43:24.030
questions, so I will just ask one or two[br]for starting. The first one is, can all
0:43:24.030,0:43:30.690
these shown attacks that you proved on[br]your speech be mitigated by… by higher
0:43:30.690,0:43:37.300
protocols levels, like encrypted VoIP or[br]TextSecure, things like that? And what
0:43:37.300,0:43:41.910
will be the residual risks?[br]K: Mm, yeah. A good question. So how much
0:43:41.910,0:43:46.740
can you protect yourself by using the[br]mobile network less on using it as a dumb
0:43:46.740,0:43:52.710
pipe, I guess is the question, what if you[br]use just apps to call and send text? Well,
0:43:52.710,0:43:59.090
obviously your calls and texts won't be[br]intercepted anymore if they are encrypted
0:43:59.090,0:44:04.560
one more time in a way that's not[br]breakable. However, this does not solve
0:44:04.560,0:44:09.100
the location tracking. It does not solve[br]the fraud. It does not solve the denial of
0:44:09.100,0:44:13.790
service. It does not solve the spamming.[br]So you are tied to a mobile network and it
0:44:13.790,0:44:18.140
has a lot of control over you, your[br]location and your phone bill. None of that
0:44:18.140,0:44:25.590
is going to go away.[br]Herald: Another question from the IRC, one.
0:44:25.590,0:44:33.380
Signal Angel: Yeah, um, the second one is:[br]Wouldn't it be easier to design from
0:44:33.380,0:44:39.902
scratch a new mobile mobile network than[br]trying to find all flaws from actual
0:44:39.902,0:44:45.080
networks, which is an endless task?[br]K: Or I don't know where you would even
0:44:45.080,0:44:49.770
start designing everything from scratch[br]completely? The closest that I can think
0:44:49.770,0:44:54.280
of designing the mobile network from[br]scratch is LTE in the name of long term
0:44:54.280,0:44:58.500
evolution. It really wants to change[br]everything, but gives it a couple of years
0:44:58.500,0:45:02.690
but as Tobias pointed out, those[br]issues we pointed out today, they are
0:45:02.690,0:45:08.220
again included in LTE. Diameter is the[br]interconnect protocol. So we already
0:45:08.220,0:45:13.410
missed a chance to to remove much of this[br]issues by just upgrade. We'll have to fix
0:45:13.410,0:45:18.950
it through firewalls and monitoring like[br]we never got to update the Internet.
0:45:18.950,0:45:22.540
Herald: OK, microphone number four,[br]please.
0:45:22.540,0:45:27.620
Mic 4: Yet just a short thing. Could you[br]just provide a list of those libraries
0:45:27.620,0:45:35.630
you need from the stock images? So I think[br]it's pretty easy to copy them to this
0:45:35.630,0:45:38.484
cyanogen mod images.[br]K: Ok
0:45:38.484,0:45:40.516
Mic 4: OK, and if the app is open source,
0:45:40.516,0:45:45.900
maybe you can put it on fdroid?[br]K: Oh absolutely. Yes. Thank you.
0:45:45.900,0:45:50.970
applause[br]Herald: The microphone number two, please.
0:45:50.970,0:45:57.560
Mic 2: Got two questions, if I understood[br]correctly, you need to be inside the
0:45:57.560,0:46:02.350
operator network to actually[br]perform those SS7 queries, right?
0:46:02.350,0:46:08.030
K: Um, well, I would I would like for this[br]to be the case. But currently, does
0:46:08.030,0:46:12.020
anybody in the world connected to SS7 can[br]send his queries.
0:46:12.020,0:46:17.960
Mic 2: OK, so my question is that what was[br]your hook point for actually doing this
0:46:17.960,0:46:20.890
test?[br]K: I think I'll quote Tobias here by
0:46:20.890,0:46:23.420
saying I would rather not say anything [br]about that.
0:46:23.420,0:46:29.800
Mic 2: OK, so the second question is about[br]the case you mentioned it's if I am not
0:46:29.800,0:46:37.840
mistaken, is the session key. Right? It's and[br]it should involve that nonce value, right?
0:46:37.840,0:46:42.850
K: Yeah.[br]Mic 2: So if it is, it already has the nonce
0:46:42.850,0:46:48.130
value. So in order the attack to work, we[br]also need to intercept the initial
0:46:48.130,0:46:54.930
messages, the nonce exchange between the[br]target and the basis station. Is that
0:46:54.930,0:46:59.460
correct?[br]K: No, the nonce is… as as they are. So
0:46:59.460,0:47:05.660
the SIM card knows which key to produce.[br]Yes. But it helps the phone to find the
0:47:05.660,0:47:09.780
right encryption key. We are not the[br]phone. We don't have the SIM card. Right.
0:47:09.780,0:47:12.600
If you just give us the encryption key, [br]we don't need the nonce.
0:47:12.600,0:47:18.700
Mic 2: Yes. So what you're saying is that[br]the query you're sending there, it
0:47:18.700,0:47:25.910
actually sends you not only the encryption[br]key, but also the nonce that is required..
0:47:25.910,0:47:30.030
K: It doesn't send us the nonce and we[br]don't need the nonce. We can take that
0:47:30.030,0:47:32.430
offline now, explain how everything works.[br]Thank you.
0:47:32.430,0:47:35.780
Herald: To microphone number three,[br]please.
0:47:35.780,0:47:40.680
Mic 3: First of all, thank you for a very[br]good presentation and very impressive work
0:47:40.680,0:47:45.330
you've done here.[br]applause
0:47:45.330,0:47:50.050
K: Thank you.[br]Mic 3: The question I have might be a
0:47:50.050,0:47:55.090
little naive, but have you also, besides[br]taking a look at this closing this whole
0:47:55.090,0:48:00.630
issue technically wise, also been taking a[br]look into how what measures can be taken
0:48:00.630,0:48:04.900
legally, at least in Germany and some[br]countries in Europe now that we have
0:48:04.900,0:48:11.431
disclosed that basically certain rules /[br]laws have not been fulfilled, that we can
0:48:11.431,0:48:15.950
enforce the operators to implement this[br]stuff on legal ways?
0:48:15.950,0:48:21.420
K: We have not looked into it. Of course,[br]we consider the possibility as soon as
0:48:21.420,0:48:25.470
somebody has an overview of where these[br]attacks happen. And that seems to be the
0:48:25.470,0:48:31.140
issue right now. There's zero attack[br]transparency. Nobody is looking for these
0:48:31.140,0:48:38.300
issues. And partly that's to the to their[br]own disbenefit, because as soon as they do
0:48:38.300,0:48:43.190
look for this issue, some of these attack[br]patterns are very easy to stop, as I said,
0:48:43.190,0:48:49.660
two German networks, mitigated them within[br]two weeks. And these issues had been open
0:48:49.660,0:48:54.510
for 20 years. Had they ever looked into[br]their own data, that would have seen this
0:48:54.510,0:49:00.060
going on. So I'm not very confident that[br]anybody in Germany at least has an
0:49:00.060,0:49:04.650
overview of where abuse would come from.[br]And as soon as it does, I don't think
0:49:04.650,0:49:10.310
there's much point in litigating. Let's[br]just stop the possibility of abuse. Right,
0:49:10.310,0:49:14.990
instead of complaining about it happening.[br]But I'm with you. If there's corner cases
0:49:14.990,0:49:19.660
in which abuse just can't be stopped,[br]let's fight it legally, of course. Right.
0:49:19.660,0:49:24.850
And if all of you contribute information[br]through SnoopSearch, does the empty
0:49:24.850,0:49:29.560
pagings, if we can find patterns of[br]abuse, of course, we'll aggregate them and
0:49:29.560,0:49:36.680
try to move against them.[br]Herald: OK, microphone number four,
0:49:36.680,0:49:40.740
please.[br]Mic 4: You said you can buy your way into
0:49:40.740,0:49:46.790
the SS7 Network, but how easy is it[br]actually to get your access? And what do
0:49:46.790,0:49:50.690
you estimate: How many players are [br]there in the network? Can you give any
0:49:50.690,0:49:54.311
estimation?[br]K: I have absolutely no idea. I know that
0:49:54.311,0:50:01.760
there's some 800 companies who who are[br]legally allowed to access SS7 and then
0:50:01.760,0:50:06.860
those, of course, have subcontractors,[br]legal and illegal, and some people who
0:50:06.860,0:50:11.186
bribe them. Yet other people who hack[br]their systems or the systems of the
0:50:11.186,0:50:14.920
subcontractors, it's very hard to[br]estimate. No idea. But definitely too many
0:50:14.920,0:50:18.650
to trust all of them.[br]Mic 4: And would it be possible for me to
0:50:18.650,0:50:25.710
get access to this without any operator[br]stuff or. I don't want to operate a phone
0:50:25.710,0:50:31.300
network, but I want to have access because[br]I want to provide a service, some service?
0:50:31.300,0:50:35.670
K: Well, I wish the answer was no, but of[br]course, right of to be as an I and a bunch
0:50:35.670,0:50:40.910
of other people can get access. You should[br]be able to get that too. But I'm not going
0:50:40.910,0:50:44.600
to tell you how.[br]laughter and applause
0:50:44.600,0:50:51.680
Herald: Yet another question from the IRC.[br]Signal Angel: We're about nine questions,
0:50:51.680,0:50:58.200
so no problem for me. First one, what[br]about Windows phones, jail breaked
0:50:58.200,0:51:04.890
iPhones, or something like this will the[br]app in the end [be] on this phones?
0:51:04.890,0:51:11.250
K: Our app doesn't run on anything other[br]than Android, but the chipsets are, of
0:51:11.250,0:51:16.670
course, the same. So if you can speak to a[br]chipset through a jail broken iPhone, for
0:51:16.670,0:51:22.070
instance, you could create a similar[br]application. We just wanted to target the
0:51:22.070,0:51:25.990
biggest population of phones, and that[br]seems to be Android phones.
0:51:25.990,0:51:33.160
Herald: Then number two, please.[br]Mic 2: One further thought on self-defense
0:51:33.160,0:51:41.110
as self-defense has don't has to be[br]proportionate, I think, and identities are
0:51:41.110,0:51:46.771
not secure in the digital sphere. How[br]about developing some proactive, as we
0:51:46.771,0:51:52.820
heard the word defense tools?[br]K: Proactive as in hack the networks,
0:51:52.820,0:51:59.010
until they have no chance but to fix?[br]Mic 2: That's what you understood, but.
0:51:59.010,0:52:03.010
But, I support that. laughter [br]K: I'm not going to say that I dislike the
0:52:03.010,0:52:07.620
idea. But you won't see me here next year[br]explaining how I did it.
0:52:07.620,0:52:11.690
Mic 2: Thank you.[br]Herald: Microphone number three, please.
0:52:11.690,0:52:17.070
OK. When did you check the other two[br]German networks didn't fix the identifier
0:52:17.070,0:52:21.800
and the issue.[br]K. Which network do you work for?
0:52:21.800,0:52:27.780
Mic 2: I'm Holger. We talked last week.[br]K: Yeah. So yeah. Maybe you fixed it too.
0:52:27.780,0:52:30.930
We didn't, we didn't check.[br]Mic 2: We fixed it within 24 hour, 24
0:52:30.930,0:52:34.590
hours after our call.[br]K: Wow. OK.
0:52:34.590,0:52:38.300
Mic 2: On both networks.[br]applause
0:52:38.300,0:52:44.430
Thank you. Better late than never. Thank[br]you.
0:52:44.430,0:52:47.320
Mic 2: That's right.[br]K: OK, so that's three out of four now,
0:52:47.320,0:52:52.610
that fix one out of 100 problems.[br]Mic 2: No, it's… I know that's why we
0:52:52.610,0:52:59.610
don't go to the press and don't tell that[br]SS7 is fixed and we know we still have
0:52:59.610,0:53:06.920
problems also. It's all four. I work for[br]Telefonica, which is O2 and eplus.
0:53:06.920,0:53:11.291
K: Oh yeah. Well, congratulations. Sorry.[br]Sorry for spoiling your Christmas.
0:53:11.291,0:53:13.440
laughter
0:53:13.440,0:53:19.400
Herald: Microphone number two, please.[br]Mic 2: I'd like to know why these empty
0:53:19.400,0:53:24.180
pagings occur in the context of the[br]location tracking, I thought, as soon as
0:53:24.180,0:53:30.620
the phone registers in the network, the[br]base station, which is this connected to,
0:53:30.620,0:53:32.630
is known in the network anyway. Is that[br]the case?
0:53:32.630,0:53:37.490
K: That's a very good question. And let me[br]let me go back to one earlier slide to to
0:53:37.490,0:53:45.590
explain that, one second, so that the[br]empty pagings do not occure when you send
0:53:45.590,0:53:50.380
these creepy AnytimeInterrogation[br]messages. They are just there for spying
0:53:50.380,0:53:55.280
and there's no way to page the customer.[br]But since this got blocked and Tobias went
0:53:55.280,0:53:59.070
into great level of detail explaining[br]this, you need a couple of other messages
0:53:59.070,0:54:03.320
to now track some of this location and[br]these messages when meant for location
0:54:03.320,0:54:09.530
tracking them and ment for other purposes.[br]For instance, as I provide subscriber info
0:54:09.530,0:54:14.950
that however you reach it is always the[br]last message you need. This does do a
0:54:14.950,0:54:19.020
paging and then to provide subscriber info[br]really makes no sense unless you send
0:54:19.020,0:54:23.890
something afterwards also, deliver an SMS[br]connect to call or whatever. So the paging
0:54:23.890,0:54:29.690
is already sent in anticipation that an[br]SMS will come or that the call will come.
0:54:29.690,0:54:33.880
But if you're only the creepy guy tracking[br]it, they're going to send it SMS and
0:54:33.880,0:54:38.410
that's where the empty paging comes from.[br]Mic 2: OK, but still also in these cases
0:54:38.410,0:54:43.610
where something follows the paging, isn't[br]it a type of double checking whether it's
0:54:43.610,0:54:50.230
really there or I mean, the location info[br]itself should already be present and the
0:54:50.230,0:54:53.510
network, isn't it?[br]K: Yeah, yeah. It just reconfirms that the
0:54:53.510,0:54:57.640
subscriber is really there. So it's[br]basically saying: Somebody you just
0:54:57.640,0:55:01.370
interrogated your location because they[br]want to send you something. Let's check
0:55:01.370,0:55:05.350
that you're really still there because[br]otherwise we'll tell them something wrong.
0:55:05.350,0:55:10.420
But Tobias do you want to comment on that.[br]Tobias: Yeah. OK, so the empty paging is
0:55:10.420,0:55:15.930
not anticipation or something that's[br]coming after. It's to get the current cell
0:55:15.930,0:55:20.970
that you are located at, because when you[br]are moving around in your location area
0:55:20.970,0:55:24.850
and the area that is covered by the[br]switching center that you're currently
0:55:24.850,0:55:31.120
being served by, your phone doesn't[br]necessarily contact the base station. So
0:55:31.120,0:55:37.790
it could be that that the networks last[br]position of you is somewhere you received
0:55:37.790,0:55:43.950
an SMS or text or call, and then you moved[br]to a completely different area if your
0:55:43.950,0:55:49.130
phone didn't have network contact in the[br]meantime, the network would still only
0:55:49.130,0:55:55.610
know the last point of contact. So that's[br]why the why the empty paging happens so
0:55:55.610,0:56:01.310
that the that the network knows the base[br]station that's actually currently closest
0:56:01.310,0:56:06.780
to you. That's also why the law[br]enforcement uses a lot of Silent SMS so
0:56:06.780,0:56:12.530
that that they can get the last position[br]in the network. And it's also an option if
0:56:12.530,0:56:17.240
you send provide subscriber information,[br]you can just send it and get back the last
0:56:17.240,0:56:23.720
known position without a paging or you can[br]set the current location flag and provide
0:56:23.720,0:56:29.860
subscriber information. And only then the[br]subscriber gets paged and you will receive
0:56:29.860,0:56:33.530
the current location.[br]K: And that's that's one good example for
0:56:33.530,0:56:37.880
how SS7, which is supposed to be[br]so insecure we can never fix it, can
0:56:37.880,0:56:42.750
easily be fixed. There's an option that[br]says we're using this as normal feature
0:56:42.750,0:56:46.480
that's absolutely needed. And we have this[br]creepy extension to also ask for the
0:56:46.480,0:56:51.140
location. And some networks choose to not[br]answer that. The answer was zero zero zero
0:56:51.140,0:56:57.540
zero and nothing broke. Right. So you can[br]just ignore the insecure parts of SS7 and
0:56:57.540,0:57:01.890
do whatever you think is right. And for[br]the most part, it continues to work. But
0:57:01.890,0:57:04.040
I think we're well beyond answering [br]your question now right?
0:57:04.040,0:57:11.230
Mic 2: No, but from your answers. Thank[br]you very much. But another question
0:57:11.230,0:57:16.710
arises, because if it's actually to locate[br]your phone and to find out which cell
0:57:16.710,0:57:23.310
you're actually in, then it implies that[br]it's not only one base station that since
0:57:23.310,0:57:29.190
the paging call, but a whole bunch of base[br]stations. Do you know something about the
0:57:29.190,0:57:35.260
algorithm? I mean, how many around the[br]last known location are paging everybody
0:57:35.260,0:57:39.560
nationwide or how does..[br]K: Everybody can implement this as they
0:57:39.560,0:57:45.340
wish? And I don't have much insights into[br]how 3G does it, but in 2G typically is:
0:57:45.340,0:57:49.730
There's one paging send in the last cell[br]that saw you. You don't respond. It's send
0:57:49.730,0:57:53.600
in a larger area. You don't respond. It's[br]sent for the whole location area. And then
0:57:53.600,0:57:58.100
some networks, you don't respond. They[br]send it in the entire country. But that's
0:57:58.100,0:58:01.589
rare. Right?[br]Mic 2: Thank you very much.
0:58:01.589,0:58:12.790
Herald: Okay. Questions from the IRC?[br]Signal Angel: Did SnoopSnitch allow you to
0:58:12.790,0:58:20.740
reveal any kind of attack in countries.[br]Not special name in mind.
0:58:20.740,0:58:26.920
K: Does it allow you to detect attacks in[br]countries? Yeah, yeah, some kind of
0:58:26.920,0:58:32.520
Tapsell. I think the answer is yes. Its[br]whole purpose is to detect attacks. And it
0:58:32.520,0:58:35.852
also works in countries…[br] laughter
0:58:35.852,0:58:39.840
Herald: Did you succeed in detecting attacks.[br]K: Did we succeed in
0:58:39.840,0:58:46.590
detecting. Yes, we did. And if you go down[br]to the Saal C, Room C, you can see how it's
0:58:46.590,0:58:53.880
currently people are being attacked and[br]currently they detect that. Ok
0:58:53.880,0:58:59.280
Herald: OK microphone number five, please.[br]Mic 5: Yes, thanks, it's going back to SS7
0:58:59.280,0:59:05.670
basics. Can you quickly explain how SS7 is[br]implemented? Is this a VPN on the public
0:59:05.670,0:59:10.610
Internet through the providers? What's the[br]technical reality of transport?
0:59:10.610,0:59:16.640
K: That's a very good question. Of course,[br]that's a very good question. And I only
0:59:16.640,0:59:21.890
have half of the information, too. I keep[br]learning. But so it seems that it was
0:59:21.890,0:59:27.430
implemented initially as a network between[br]Western European telcos and their run
0:59:27.430,0:59:33.961
cables, dedicated cables for SS7.[br]SIGTRAN they called this and then a couple
0:59:33.961,0:59:38.250
more networks connected to it. And each[br]of them had to run the cable to one of the
0:59:38.250,0:59:42.690
other telcos. But eventually they changed[br]that and then introduced what I call
0:59:42.690,0:59:46.741
routing providers. So telcos are not[br]connected to each other usually, but
0:59:46.741,0:59:52.240
through a routing provider like on the[br]Internet and those routing providers, they
0:59:52.240,0:59:56.710
typically don't run a cable to your house[br]anymore. If you are a new telco, they give
0:59:56.710,1:00:00.790
you a VPN over the Internet. So it's[br]diverse. I'm sure there's still some
1:00:00.790,1:00:04.790
dedicated lines between Germany and[br]France, say, and there's some others
1:00:04.790,1:00:08.510
connecting and these big clouds that are[br]routing providers. And it's actually
1:00:08.510,1:00:12.290
really difficult to get your address[br]routed everywhere in the world. So even if
1:00:12.290,1:00:16.886
you connect to SS7, all you're connected [br]to is one routing provider and that
1:00:16.886,1:00:21.690
routing provider knows that you own these[br]addresses. Now it's up to you to convince
1:00:21.690,1:00:25.850
every other of the big seven or nine,[br]depending on how you count routing
1:00:25.850,1:00:34.250
providers that you are that guy with those[br]addresses. So the BGP equivalent of SS7 is
1:00:34.250,1:00:40.410
to get nine roaming agreements signed with[br]people on these other nine operators and
1:00:40.410,1:00:44.810
then fax those roaming agreements to[br]everybody else involved. So they type it
1:00:44.810,1:00:49.530
into your computer, into their computers,[br]very manual and very hard to grow the
1:00:49.530,1:00:52.830
network. But for the most part, it doesn't[br]change, of course-
1:00:52.830,1:00:57.940
Mic 5: So that the low level transport is[br]not really an attack surface from the
1:00:57.940,1:01:00.840
public Internet.[br]K: It can be the low level transport can
1:01:00.840,1:01:07.090
be an attack surface if people just[br]stupidly leave open their local networks.
1:01:07.090,1:01:11.156
But it's rare. It's much more common,[br]speaking about our talk next year,
1:01:11.156,1:01:15.844
hopefully on the other interconnect[br]networks, there's one interconnect network
1:01:15.844,1:01:22.240
for data roaming. It's called GRX. And[br]since everything is IP anyway on data
1:01:22.240,1:01:26.610
roaming, people sometimes do leave it out[br]on the Internet or just do it unencrypted
1:01:26.610,1:01:31.010
over the Internet. And it does seem to[br]become more popular also with the SS7
1:01:31.010,1:01:37.440
replacement Diameter, which again is pure[br]IP. So there's no dedicated thing that you
1:01:37.440,1:01:41.660
first have to encapsulate in a VPN before[br]you can route it over the Internet. You
1:01:41.660,1:01:47.060
can run Diameter over the open Internet if[br]you want. It's stupid, but people seem to
1:01:47.060,1:01:52.170
do it anyway.[br]Herald: OK, the microphone number six,
1:01:52.170,1:01:55.310
please.[br]Mic 6: OK, my question is, if you could
1:01:55.310,1:02:00.451
comment why these message were put in the[br]protocol at the first place, it they are
1:02:00.451,1:02:07.270
so easy to block and to fix. And the other[br]question is, if all the other problems
1:02:07.270,1:02:11.620
that you pointed out are as easy to fix[br]for the network operators.
1:02:11.620,1:02:16.780
K: So I don't have an answer to your first[br]question. Why do you put a tracking
1:02:16.780,1:02:22.470
message in the standard and then call it[br]AnytimeInterrogation, gosh, like that
1:02:22.470,1:02:25.610
invokes feelings for me,[br]interrogation room and all. I mean, this
1:02:25.610,1:02:30.440
is spy stuff, right? And there's no[br]practical, purposeful but. Right. Who
1:02:30.440,1:02:35.000
wrote SS7 standard? Western European[br]governments being afraid of the Russians,
1:02:35.000,1:02:39.060
of their own citizens, who knows? Right. I[br]don't know why they put every single
1:02:39.060,1:02:44.280
message in, though. So your second[br]question was what again?
1:02:44.280,1:02:49.060
Mic 6: If the other vulnerabilities are as[br]easy as to fix? Or just blocking messages.
1:02:49.060,1:02:55.730
K: No they're not. And I tried to point[br]that out in one of the slides that… that
1:02:55.730,1:03:02.270
AnytimeInterrogation can be fixed, as can,[br]for instance, as does SendIdentification
1:03:02.270,1:03:07.310
message, right. You just block that has no[br]purpose, routing this internationally. But
1:03:07.310,1:03:11.600
the other queries on this page, at least[br]you need those internationally, at least
1:03:11.600,1:03:17.430
to enable roaming. So the best you can do[br]is, as I said, first block these queries
1:03:17.430,1:03:21.010
from anybody who's not your roaming[br]partner, right? Don't respond to those
1:03:21.010,1:03:26.520
people and then do some plausibility [br]checking, secondly, make sure that if a
1:03:26.520,1:03:31.380
subscriber is actually in your own network, [br]that you don't honor requests from another
1:03:31.380,1:03:36.600
country. Right. And that should remove most [br]of the issues because most abuse comes from
1:03:36.600,1:03:40.340
other countries. It's just more likely if[br]there's 800 parties connected to this
1:03:40.340,1:03:46.901
network that the one doing the abuse is[br]not yours. Good question. Thanks.
1:03:46.901,1:03:59.000
Subtitles created by c3subtitles.de[br]in the year 2021. Join, and help us!