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