1 00:00:09,210 --> 00:00:12,820 *applause* 2 00:00:12,820 --> 00:00:16,360 Karsten Nohl: Great to be back. Thank you very much, talking once again on mobile 3 00:00:16,360 --> 00:00:21,080 security, taking two very different angles, though, from what we talked about 4 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 5 00:00:26,670 --> 00:00:31,890 Engel just did, looking at insecurities that arise from the interconnect networks 6 00:00:31,890 --> 00:00:38,150 between different operators and we want to add another angle. And that is how YOU 7 00:00:38,150 --> 00:00:43,190 can start self defending yourself from the insecurities that many of your operators 8 00:00:43,190 --> 00:00:49,410 have left open for many years, including the new ones that Tobias and myself talk 9 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, 10 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 11 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 12 00:01:06,320 --> 00:01:17,460 from. *applause* Aside from those SS7 based attacks, we want to talk about 3G 13 00:01:17,460 --> 00:01:23,780 insecurities, not too many of them, but severe as ever, as well as in the last 14 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 15 00:01:30,210 --> 00:01:36,320 against these mobile attacks. Now, just briefly, then, what is the SS7 Network 16 00:01:36,320 --> 00:01:40,920 Tobias has already covered the basics. So just a quick definition from me. It's this 17 00:01:40,920 --> 00:01:45,890 network that different mobile operators are connected to, to exchange data among 18 00:01:45,890 --> 00:01:51,530 each other. For instance, text messages are sent over this network. So without SS7, 19 00:01:51,530 --> 00:01:57,920 you couldn't be using this ancient chatting technology SMS. Thank you SS7. But also 20 00:01:57,920 --> 00:02:05,280 more security relevant information is exchanged over SS7. For instance, if you're 21 00:02:05,280 --> 00:02:10,530 using your phone in another country, as many of you currently do, you still want 22 00:02:10,530 --> 00:02:15,510 this visiting network to be able to use encryption with your phone, but how is that 23 00:02:15,510 --> 00:02:20,030 network going to know the right encryption key? So this visiting network, the German 24 00:02:20,030 --> 00:02:24,190 network has to ask your home network for the correct encryption key and that goes 25 00:02:24,190 --> 00:02:29,700 over SS7. And you can already see if there's cryptographic information being 26 00:02:29,700 --> 00:02:33,560 exchanged, if the wrong people ask and still receive an answer, insecurities 27 00:02:33,560 --> 00:02:39,950 arise. More interesting from a security perspective, though, are messages that are 28 00:02:39,950 --> 00:02:46,099 exchanged within one network over SS7. So SS7 is often misunderstood as this 29 00:02:46,099 --> 00:02:50,840 technology that's used for worldwide exchange of information. The same network, 30 00:02:50,840 --> 00:02:54,640 though, is used inside an operator. So there's no need for interconnect. There's 31 00:02:54,640 --> 00:03:01,290 already SS7 flows going on between those different mobile switching centers, MSC. 32 00:03:01,290 --> 00:03:07,530 And each mobile switching center covers one area, let's say a city. So imagine a 33 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 34 00:03:13,340 --> 00:03:17,110 another. You're crossing, let's say, your state boundary. So there's new MSC, 35 00:03:17,110 --> 00:03:21,560 doesn't know how to handle your call. It needs the decryption key for the already 36 00:03:21,560 --> 00:03:28,610 ongoing conversation. So there's another SS7 message that allows you to query for 37 00:03:28,610 --> 00:03:33,650 the key of a transaction that's currently going on. OK? And again, you can already 38 00:03:33,650 --> 00:03:38,739 see how if the wrong people send this type of message and they receive an answer, 39 00:03:38,739 --> 00:03:46,730 insecurities arise. The insecurity that that has most been talked about in recent 40 00:03:46,730 --> 00:03:52,670 years, again, up until Tobias's talk, was tracking. And tracking was often understood 41 00:03:52,670 --> 00:03:57,720 as: There's this evil message, the any time interrogation and The Washington Post 42 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 43 00:04:01,621 --> 00:04:06,451 should not been I have been ever standardized. And whenever it's used, it's 44 00:04:06,451 --> 00:04:12,101 for evil purposes. There's no usefulness in this message. And Tobias 45 00:04:12,101 --> 00:04:16,209 quoted a number that I think The Washington Post found in a lot of 46 00:04:16,209 --> 00:04:21,709 marketing material, 70 percent of mobile networks respond to this message. Now, 47 00:04:21,709 --> 00:04:26,000 this is information from earlier this year. A lot of networks, very good news, have 48 00:04:26,000 --> 00:04:32,770 moved to to stop responding to anytime interrogation message. This evil spying 49 00:04:32,770 --> 00:04:37,509 message is not being responded to by, for instance, all German networks. You can't 50 00:04:37,509 --> 00:04:44,460 use this message in Germany anymore. However, this is a very retroactive 51 00:04:44,460 --> 00:04:51,729 approach to securing SS7 because there's a number of other messages that, consider them 52 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 53 00:04:57,169 --> 00:05:03,439 somebody's location. And here's just a snapshot of of which messages you can use 54 00:05:03,439 --> 00:05:08,960 and Tobias went into a greater level of detail in how these different messages 55 00:05:08,960 --> 00:05:13,689 come together. So if anybody thinks that just barring anytime integration, you 56 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 57 00:05:20,642 --> 00:05:26,900 not secureable. It's just a much larger challenge that people consider currently 58 00:05:26,900 --> 00:05:33,869 to be. So you see how stringing together some of these messages get you to 59 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. 60 00:05:39,039 --> 00:05:42,849 And up until all these messages or at least every path that takes you from left 61 00:05:42,849 --> 00:05:49,759 to right is blocked by a network, tracking to the same accuracy, to cell ID stays 62 00:05:49,759 --> 00:05:54,949 possible. Now, this is just one of many areas in which SS7 can become an issue. 63 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 64 00:06:03,559 --> 00:06:08,169 to your calls, it's a denial of service risk. If people cut you off from 65 00:06:08,169 --> 00:06:13,490 phone connectivity for anywhere from an hour until the next location update or 66 00:06:13,490 --> 00:06:19,319 until your next reboot your phone, so you can really cut people off badly from it, 67 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 68 00:06:24,559 --> 00:06:29,249 talk about publicly, certainly I don't. But there's many fraud risks in SS7 69 00:06:29,249 --> 00:06:34,089 in which you can easily put charges on somebody else's bill, or more 70 00:06:34,089 --> 00:06:39,899 interestingly, you can remove limits on your own prepaid cards, basically run up 71 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 72 00:06:46,240 --> 00:06:50,960 to premium numbers, for instance. And then there's the risk of spamming, which from 73 00:06:50,960 --> 00:06:55,930 what I hear is already happening, SS7 based spam attacks. Now, for the sake of 74 00:06:55,930 --> 00:07:01,560 this talk, I want to focus on intercept, which I consider aside from tracking the 75 00:07:01,560 --> 00:07:06,099 most intrusive and the most relevant for us, just as a risk, they're more relevant 76 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 77 00:07:09,649 --> 00:07:14,469 as they foot the bill for it. So intercept. And I want to go into three 78 00:07:14,469 --> 00:07:21,250 possible scenarios in which SS7 assisted intercept can happen. The first abuses 79 00:07:21,250 --> 00:07:24,719 the exact message, as we looked at in the introduction, these messages where 80 00:07:24,719 --> 00:07:29,889 different parts of networks ask each other for encryption information and it's a 81 00:07:29,889 --> 00:07:35,860 pretty straightforward attack. You record the airwaves. Around somebody in 82 00:07:35,860 --> 00:07:41,129 somebody's vicinity and you record somebody's encrypted transaction as part of 83 00:07:41,129 --> 00:07:47,050 that, right? So and 3G transaction, for instance, are pretty well secured, but 84 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 85 00:07:53,080 --> 00:07:58,039 it doesn't jump around all these frequencies. So you record, let's say, 3G 86 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 87 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 88 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 89 00:08:16,129 --> 00:08:20,810 into another MSC, but still within your own network so that the call doesn't get 90 00:08:20,810 --> 00:08:27,099 disrupted. It's not supposed to be used when when somebody foreign wants to 91 00:08:27,099 --> 00:08:31,779 query your phone, if they need a new encryption key, a new call needs to start 92 00:08:31,779 --> 00:08:36,270 anyway. There's no way to hand over a call from one operator to another operator 93 00:08:36,270 --> 00:08:43,209 without disruption. So this message is used only for internal purposes. However, 94 00:08:43,209 --> 00:08:47,780 out of the four German operator earlier this month, all four responded to this 95 00:08:47,780 --> 00:08:52,100 request coming from another country, another country that doesn't even border 96 00:08:52,100 --> 00:08:57,170 Germany. So there's no way to even conceptually think a call would be handed 97 00:08:57,170 --> 00:09:03,950 over. So four out of four. And that's not an anomaly. Most networks require an 98 00:09:03,950 --> 00:09:08,940 international response to an outside number when asked for the current 99 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. 100 00:09:14,030 --> 00:09:17,650 But I first finish the enumeration of all the different possibilities in which 101 00:09:17,650 --> 00:09:24,920 3G calls can be intercepted. The second one, the good old IMSI catchers, which we 102 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 103 00:09:31,540 --> 00:09:36,010 comes to the help. So why don't they work without SS7? An IMSI catcher 104 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 105 00:09:42,070 --> 00:09:47,720 of knowing the difference between the real base station and a fake base station. But 106 00:09:47,720 --> 00:09:53,180 then 3G, the 3G standard introduced what I call mutual authentication. So this time 107 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 108 00:09:57,630 --> 00:10:03,530 does that, the phone won't connect. Now, this only solves part of the IMSI catcher 109 00:10:03,530 --> 00:10:08,530 problem. Just taken by the name even the catching is still possible, IMSI catching 110 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 111 00:10:14,660 --> 00:10:19,150 certain chicken and egg problem. If you want me as a base station to 112 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 113 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 114 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 115 00:10:32,900 --> 00:10:36,811 catching is always possible. And that's why if you Google for 3G IMSI catcher, those 116 00:10:36,811 --> 00:10:43,240 things exist. But they aren't capable of recording phone calls or SMS because those 117 00:10:43,240 --> 00:10:49,080 then required a mutual authentication. They aren't capable of doing so unless they ask 118 00:10:49,080 --> 00:10:55,960 over SS7 for an authentication key. So IMSI catchers are back in the 3G world 119 00:10:55,960 --> 00:11:05,328 big time, unless we solve these SS7 problems, right? The third possibility of 120 00:11:05,328 --> 00:11:10,880 of intercept - this is probably the scariest because it can happen completely 121 00:11:10,880 --> 00:11:15,470 remotely - Boaster once enumerated so far, you have to be somewhere in the vicinity 122 00:11:15,470 --> 00:11:19,540 in the vicinity of somewhere. So the third possibility, I want to call the rerouting 123 00:11:19,540 --> 00:11:24,640 attacks and they work in both directions. Rerouting is the idea. And to be as 124 00:11:24,640 --> 00:11:31,270 touched on this, of taking… of taking somebodies phone calls and changing 125 00:11:31,270 --> 00:11:36,799 the destination number so that, in fact, you call somebody else unbeknownst to you, 126 00:11:36,799 --> 00:11:42,590 of course, as the victim. And this will expose for incoming calls and outgoing 127 00:11:42,590 --> 00:11:46,600 calls, but using very different methods. So it just kind of accidentally works in 128 00:11:46,600 --> 00:11:52,970 both directions. And this part, I just briefly want to demonstrate to BSN that 129 00:11:52,970 --> 00:11:56,870 coordinated on most of this. But this part, I guess we kind of misunderstood 130 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 131 00:12:01,870 --> 00:12:07,998 to get across is that, one, a single SS7 message is already a big intercept 132 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 133 00:12:15,660 --> 00:12:26,600 Tobias and try to cut off part of my number here. So 31C3 demo phone. 134 00:12:26,600 --> 00:12:32,713 So I'm calling a a phone that in fact, accidentally we left in. So … fuck 135 00:12:32,713 --> 00:12:36,190 * Laughter and applause* * Ring-back tone starts * 136 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. 137 00:12:40,491 --> 00:12:43,813 And we did leave his phone back in Berlin accidentally. But for the sake of this 138 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 139 00:12:48,100 --> 00:12:50,912 answers to. Here is another phone. 140 00:12:50,912 --> 00:12:52,002 * Ring-back tone stops * 141 00:12:52,002 --> 00:12:54,329 So if I if I register what they call a 142 00:12:54,329 --> 00:13:01,220 supplementary service to this number. And that's just fancy language for, for, for 143 00:13:01,220 --> 00:13:09,392 call forwarding, if I call this exact same number again. 144 00:13:13,758 --> 00:13:16,659 * Ring-back tone starts * 145 00:13:16,659 --> 00:13:18,877 * Phone ringing also starts * 146 00:13:18,877 --> 00:13:21,140 This phone is ringing. 147 00:13:21,140 --> 00:13:23,930 * Applause * 148 00:13:23,930 --> 00:13:25,800 * Both ring-back and ring-tone stop * 149 00:13:25,800 --> 00:13:28,059 * Still applause * 150 00:13:28,059 --> 00:13:33,120 Now, of course, to make this real intercept, I wouldn't forward it to a 151 00:13:33,120 --> 00:13:37,740 phone, I would forward it to a computer that then is smart enough to very quickly 152 00:13:37,740 --> 00:13:43,960 erase the call forwarding and call the original number and then connect it to so 153 00:13:43,960 --> 00:13:48,260 that the phone, the phone call actually goes to where it was supposed to go. Just 154 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 155 00:13:53,451 --> 00:13:57,710 idea in this direction, in the other direction, the exact same thing works as 156 00:13:57,710 --> 00:14:03,875 well. And Tobias already told you how these services that say, let me rewrite 157 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 158 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 159 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 160 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 161 00:14:21,430 --> 00:14:26,912 connect those two calls. So, as I said, I consider those to the scariest type of 162 00:14:26,912 --> 00:14:30,680 attacks because they were completely remotely you don't have to be in the radio 163 00:14:30,680 --> 00:14:35,140 vicinity of anybody. And surprisingly, this still works against a bunch of 164 00:14:35,140 --> 00:14:41,690 networks, even against those networks that move to solve some of the earlier issues. 165 00:14:41,690 --> 00:14:49,285 So networks [are] still very retroactive. So what do what do those mobile networks 166 00:14:49,285 --> 00:14:54,920 now have to do to to solve those issues? Well, as always, of course, the answer: 167 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 168 00:14:59,921 --> 00:15:05,710 blocked. Like the AnytimeInterrogation, that earlier this year they said 70% of 169 00:15:05,710 --> 00:15:10,170 the networks are vulnerable. Now in Germany it's zero. So something happened 170 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. 171 00:15:16,440 --> 00:15:20,550 The passive intercept I said when we tested earlier this month for other four 172 00:15:20,550 --> 00:15:27,100 networks are vulnerable. Now it's down to two. So within two weeks, two networks put 173 00:15:27,100 --> 00:15:33,970 in a firewall rule that says this message has no purpose. Traversing our outside 174 00:15:33,970 --> 00:15:39,940 network boundary, just block it. The typical firewall is the same isn't 175 00:15:39,940 --> 00:15:45,100 possible for these other two types of attacks because those messages are 176 00:15:45,100 --> 00:15:50,550 actually useful. They do something, at least in certain circumstances. If you 177 00:15:50,550 --> 00:15:55,210 block the second type of query here to send authentication info, you couldn't be 178 00:15:55,210 --> 00:15:58,930 roaming in another country anymore. If you blocked a third one, you couldn't be 179 00:15:58,930 --> 00:16:04,400 changing your your voice mail forwarding from another country anymore. So these are 180 00:16:04,400 --> 00:16:10,390 needed. Still we couldn't, we can't accept that just anybody who asks over SS7 ... 181 00:16:10,390 --> 00:16:11,990 * Phone ringing * * Nohl sighs * 182 00:16:11,990 --> 00:16:15,658 You guys! * Laughter * 183 00:16:15,658 --> 00:16:23,750 Switched this off. We can't accept that just anybody who asks over SS7 184 00:16:23,750 --> 00:16:29,370 receives an answer, at the very least we would expect networks to only answer to 185 00:16:29,370 --> 00:16:33,500 their friends on SS7, and that is their roaming partners. That's 186 00:16:33,500 --> 00:16:38,980 already a lot fewer companies and especially a lot fewer sketchy companies 187 00:16:38,980 --> 00:16:44,791 than everybody else on SS7. We would then want those networks to do some 188 00:16:44,791 --> 00:16:51,390 plausibility checking. Right. So this does phone in Berlin that just put a 189 00:16:51,390 --> 00:16:56,670 supplementary service on. The network operator knows the phone is in Berlin and 190 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 191 00:17:02,760 --> 00:17:08,310 of possibility checking what would clearly see that this is not possible for a phone 192 00:17:08,310 --> 00:17:12,760 to be in one country and for this user to want to change their voicemail setting 193 00:17:12,760 --> 00:17:17,809 from somewhere completely different. And then thirdly, networks need to limit the 194 00:17:17,809 --> 00:17:22,020 rate at which this happens. Those services that The Washington Post talked about is 195 00:17:22,020 --> 00:17:26,240 tracking services. These are large operations. They seem to be tracking 196 00:17:26,240 --> 00:17:33,620 thousands of people, constantly. This will show in logs, you don't allow some random 197 00:17:33,620 --> 00:17:38,300 network somewhere else in the world to constantly interrogate hundreds of your 198 00:17:38,300 --> 00:17:44,200 users, right? It's clearly abuse. Has any network move to put such sensible rules 199 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 200 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 201 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 202 00:18:01,389 --> 00:18:06,399 technology built was not secured in mind, and we did fix it since the 90s, since 203 00:18:06,399 --> 00:18:10,679 when you connected to Windows 95 computer to the Internet, it got infected with the 204 00:18:10,679 --> 00:18:16,580 virus right away. We have moved to put in firewalls. We're not exposing our printer 205 00:18:16,580 --> 00:18:21,190 daemon and now file-sharing daemon on the entire Internet anymore for four billion 206 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 207 00:18:25,680 --> 00:18:34,508 in the nineties. Thank you. * Applause * 208 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, 209 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. 210 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 211 00:18:50,096 --> 00:18:54,470 that could go wrong. But here's the setup. We start with just a phone number 212 00:18:54,470 --> 00:19:00,389 and we want to string together a couple of SS7 gadgets while also having this radio 213 00:19:00,389 --> 00:19:05,105 handy that can capture 3G information to capture yet more information that's not 214 00:19:05,105 --> 00:19:10,870 available over SS7. Right. So we start with a phone number and we send what's 215 00:19:10,870 --> 00:19:18,195 called an SRI-for-SM message, which gives us, if the network is configured answer, 216 00:19:18,195 --> 00:19:26,441 the IMSI and the MSI that the subscriber currently is connected for. Those two are 217 00:19:26,441 --> 00:19:31,001 used as parameters into another call. Called the PSI message, provide 218 00:19:31,001 --> 00:19:37,191 subscriber info. And then that call then gives us the Cell ID. This is just how 219 00:19:37,191 --> 00:19:41,440 you get more and more information with different gadgets. Now the Cell ID tells 220 00:19:41,440 --> 00:19:45,840 us where somebody is physically. So imagine we now move our radio to that 221 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 222 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 223 00:19:59,779 --> 00:20:05,889 send the PSI over SS7, the phone receives some information. Right. This radio plus a 224 00:20:05,889 --> 00:20:11,070 little bit GNU radio scripting gives us that information: Who has been paged 225 00:20:11,070 --> 00:20:18,749 during that short window of time that we that we recorded? Now when we record 226 00:20:18,749 --> 00:20:22,929 something on UMTS, we always record for different cells – they share frequencies. 227 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 228 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 229 00:20:33,012 --> 00:20:36,739 included. And luckily for us, only one IMSI got paged within those few 230 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 231 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 232 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 233 00:20:54,710 --> 00:21:00,250 key now and the next time this phone receives something, unless it changes the 234 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 235 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 236 00:21:07,279 --> 00:21:12,129 message to the phone. We can also record that right. Again, same radio, the one 237 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 238 00:21:17,990 --> 00:21:26,980 more steps. So the phone received a text message and we also, again, recorded the 239 00:21:26,980 --> 00:21:38,629 airwaves. We again run it through some GNU radio script. Now, was was UMTS 240 00:21:38,629 --> 00:21:42,529 everything? It is kind of complicated, so there's a different connection, of 241 00:21:42,529 --> 00:21:45,779 course, happening all at the same time, and then they'll get allocated to 242 00:21:45,779 --> 00:21:49,999 different channels. So now, in order to to decode this text message, we're going to 243 00:21:49,999 --> 00:21:55,950 find out which channel is used. So this command gives us the list of which which 244 00:21:55,950 --> 00:22:00,909 channels have been allocated. And we got to find a TMSI from earlier in one of 245 00:22:00,909 --> 00:22:06,040 these channel allocations. And Wireshark is a great help in this. We didn't have to 246 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 247 00:22:11,050 --> 00:22:14,970 luckily, the first of these five connecting requests is the right one and 248 00:22:14,970 --> 00:22:19,379 scroll all the way down, there's then the parameters that say which channel this 249 00:22:19,379 --> 00:22:23,919 transaction happened on. So those two numbers, 15 and 48 is the channel. So we, 250 00:22:23,919 --> 00:22:31,324 we need to cell frequency, but we need those those two two numbers, that, that 251 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 252 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. 253 00:22:46,675 --> 00:22:55,382 * Applause * Thank you. 254 00:22:57,359 --> 00:23:03,540 This still works today, but only against two out of the four German networks. Some 255 00:23:03,540 --> 00:23:10,351 of them move to to to stop some of these messages, of course, most importantly, 256 00:23:10,351 --> 00:23:14,940 this SI message that gives you the decryption key. But even if you block this 257 00:23:14,940 --> 00:23:22,539 message, just acquiring somebody's location can already be intrusive enough. 258 00:23:22,539 --> 00:23:27,389 All right. Moving on to 3G security or rather extending on 3G security since this 259 00:23:27,389 --> 00:23:34,919 already touched through 3G in a big way. You remember the good old days where where 260 00:23:34,919 --> 00:23:40,489 you could just intercept all phone calls was the Osmocon phone. Thank you, by the 261 00:23:40,489 --> 00:23:45,059 way, for that open source project that helped us so much over the years. And you 262 00:23:45,059 --> 00:23:52,849 combine that with the kraken software to decrypt the phone call. So with 20 year 263 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 264 00:23:57,919 --> 00:24:03,940 they're using the A5/1 cipher. Some networks recently moved into A5/3. 265 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? 266 00:24:10,720 --> 00:24:16,039 As I've just shown, basically the same attacks are possible. Instead of the 267 00:24:16,039 --> 00:24:21,419 Osmocom phone, we use a programable radio, some more software, but again, very 268 00:24:21,419 --> 00:24:26,509 affordable 400 euros or something. And you combine that using 269 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 270 00:24:34,409 --> 00:24:41,460 and neither is A5/3, the recent upgrade of GSM because those keys are 271 00:24:41,460 --> 00:24:50,500 again exposed over SS7. Now, some networks, you don't even need that second 272 00:24:50,500 --> 00:24:57,559 part, so they have bigger things to worry about and then SS7 attacks and our data 273 00:24:57,559 --> 00:25:01,919 set isn't all that large. Some of you provided measurements through through a 274 00:25:01,919 --> 00:25:07,260 software release last year. So thank you very much for that. And we have captures 275 00:25:07,260 --> 00:25:14,619 from maybe 20, 25 countries out of those five having to use no 3G encryption at 276 00:25:14,619 --> 00:25:21,200 all. Well, four countries. Five network operators. Right. Which I find shocking. 277 00:25:21,200 --> 00:25:26,249 Some of these even have encryption turned on on their GSM network and then forgot to 278 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 279 00:25:31,216 --> 00:25:38,330 variant. Right. So those networks, as I said, have much more, much more worrisome 280 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 281 00:25:45,350 --> 00:25:49,659 an extension of a website that we've been maintaining for a couple of years, gsmmap, 282 00:25:49,659 --> 00:25:55,860 big update of gsmmap launched today with all the 3G measurements, we, we 283 00:25:55,860 --> 00:26:01,590 collected and you collected over the last couple of years. Now, some of you may have 284 00:26:01,590 --> 00:26:07,951 used gsmmap before. The idea as to to rank operators in the three categories. How 285 00:26:07,951 --> 00:26:13,509 hard is it to intercept phone calls and SMS? Is it easy to impersonate a person 286 00:26:13,509 --> 00:26:17,950 and then put charges on a bill, for instance, or receive the calls? How hard 287 00:26:17,950 --> 00:26:22,760 is it to track them? And as you see, over the last years, networks have improved 288 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 289 00:26:31,220 --> 00:26:39,049 networks, even the best secure 2G network. And in Germany anyway, in our opinion, is 290 00:26:39,049 --> 00:26:44,450 less secure than the worst secured 3G networks. These are for 3G networks, still 291 00:26:44,450 --> 00:26:50,399 we want networks to implement all security features. And as you saw before, some 292 00:26:50,399 --> 00:26:57,399 other countries don't have that luxury of all 3G secure networks reasonably secure. 293 00:26:57,399 --> 00:27:01,909 Not the first version of our metric is very crude and we want to improve upon 294 00:27:01,909 --> 00:27:06,210 this over time. But currently how we calculate the score is we'll give ninety 295 00:27:06,210 --> 00:27:10,779 percent of the points to anybody who switches on encryption. That's the main 296 00:27:10,779 --> 00:27:16,330 security feature and the remaining 10 percent you earn by changing the TMSI 297 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 298 00:27:22,149 --> 00:27:28,440 changing it, it really confuses the that the person trying to to haunt you also 299 00:27:28,440 --> 00:27:32,559 this makes other types of attacks more difficult, will factor in a couple of more 300 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 301 00:27:38,989 --> 00:27:43,880 gsmmap. If you haven't checked it out, check out your country on gsmmap, read the 302 00:27:43,880 --> 00:27:52,149 country report. So does a six page or so report, auto generated, that explains what 303 00:27:52,149 --> 00:27:56,759 types of measurements we included into into these graphs and why we think they 304 00:27:56,759 --> 00:28:01,529 they constitute certain risks. Maybe forward it to to your network and say if 305 00:28:01,529 --> 00:28:08,870 you're not improving, I'm going to change, switch to another network. Now, not 306 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 307 00:28:14,210 --> 00:28:19,080 problem in particular that I want to start warning about, because I really think 308 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 309 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 310 00:28:29,759 --> 00:28:37,419 over SS7 was actually only 64bit from this particular network. And the SIM card that 311 00:28:37,419 --> 00:28:41,440 was there was used in this attack, was bought that very same week. So we recorded 312 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 313 00:28:46,039 --> 00:28:51,340 network. And still it only uses 64 bit. And that, in my view, is incompatible with 314 00:28:51,340 --> 00:28:57,710 what we have learned from from recent Snowden documents that the NSA in 2011, 315 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 316 00:29:06,149 --> 00:29:09,919 estimated at this very conference a year ago that you'd need about a million 317 00:29:09,919 --> 00:29:14,759 dollars to break A5/3. Now, they did it a little bit earlier. So Moore's 318 00:29:14,759 --> 00:29:19,300 Law, everything's more expensive and probably to have overhead, too. But they 319 00:29:19,300 --> 00:29:25,000 spend apparently four billion pounds. I don't know why pound, not dollars, but it 320 00:29:25,000 --> 00:29:31,200 may have been some GCHQ Corporation. So for four million pound a couple of years 321 00:29:31,200 --> 00:29:36,791 ago, you could already break 64 bit crypto and 64 bit is more prevalent in mobile 322 00:29:36,791 --> 00:29:44,499 networks than you would have thought when they upgraded the GSM networks to A5/3. 323 00:29:44,499 --> 00:29:49,342 They didn't actually upgraded it to UMTS security, as everybody claimed they did. 324 00:29:49,342 --> 00:29:57,771 They upgraded it to the cipher used in UMTS with a key half the size. When 325 00:29:57,771 --> 00:30:02,958 writing the A5/3 standards though, the people were smart enough to also put in 326 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 327 00:30:10,669 --> 00:30:15,029 been seen anywhere since. It's written in the standard. It was released the same day 328 00:30:15,029 --> 00:30:20,960 that A5/3 was released. Nobody has ever moved to implement that. So GSM for the 329 00:30:20,960 --> 00:30:26,049 time being is and will be vulnerable to anybody. It was a one million dollar 330 00:30:26,049 --> 00:30:30,911 machine in the basement. Certainly NSA, but more and more people as we move 331 00:30:30,911 --> 00:30:34,570 forward. And what costs a million dollars today, thanks to Moore's Law in a couple 332 00:30:34,570 --> 00:30:40,869 of years, anybody can break it on a computers like we today. Break the A5/1. 333 00:30:40,869 --> 00:30:45,649 If your network uses certain older SIM cards, differentiation years between a 334 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 335 00:30:52,529 --> 00:30:59,590 even your 3G transactions are 64 bit encrypted. So there is no way to generate 336 00:30:59,590 --> 00:31:02,960 more entropy. You could query for two keys, I guess, but they weren't smart 337 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. 338 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 339 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 340 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 341 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 342 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 343 00:31:32,987 --> 00:31:38,596 lots and lots of data. Help us collect those data and we'll make it public. 344 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 345 00:31:44,345 --> 00:31:49,405 main reason, and this is really what keeps us awake at night is this question of 346 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 347 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 348 00:32:02,679 --> 00:32:06,570 always criticize that at least many networks do not respond to those. So we 349 00:32:06,570 --> 00:32:11,860 have to stockpile ever growing stockpile of mobile security issues and nobody seems 350 00:32:11,860 --> 00:32:15,889 to be addressing. And all we do is wait for our networks to do something 351 00:32:15,889 --> 00:32:20,630 eventually. Now waiting's over for me, at least I'm impatient. I want to do 352 00:32:20,630 --> 00:32:25,789 something now and I want to address all these issues all at once. Those issues 353 00:32:25,789 --> 00:32:31,169 that we talked about for several years now, including the SIM card attacks from 354 00:32:31,169 --> 00:32:39,739 last year, silent SMS based tracking the SMS, the SS7 abuse discussed today, 355 00:32:39,739 --> 00:32:46,340 IMSI Catcher Vulnerabilities and insufficiently configured networks, 2G as 356 00:32:46,340 --> 00:32:53,250 well as 3G. All of these problems have one thing in common. Your phone technically 357 00:32:53,250 --> 00:32:58,269 knows that these attacks are happening and your phone technically knows that a 358 00:32:58,269 --> 00:33:03,999 network is configured insecurely. But unfortunately it's buried very deep inside 359 00:33:03,999 --> 00:33:07,869 the phone. It's buried inside the baseband. So as much as you can program 360 00:33:07,869 --> 00:33:12,259 Android, you don't get access to that information. At least so we saw it and 361 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 362 00:33:16,769 --> 00:33:21,019 information out from these phones. It's somewhere in there. There must be some way 363 00:33:21,019 --> 00:33:27,321 to hack it out of it. And we found debug possibilities for Qualcomm chipsets, just 364 00:33:27,321 --> 00:33:31,309 one vendor, but extremely popular. Right now. There seem to be in every LTE phone 365 00:33:31,309 --> 00:33:36,809 and in a bunch of other phones. And we found, we found ways of producing exactly 366 00:33:36,809 --> 00:33:42,539 all the data on the right hand side to make it accessible through an Android 367 00:33:42,539 --> 00:33:48,060 application. And we also wrote an application for you. So: Release today. 368 00:33:48,060 --> 00:33:57,695 *Applause* 369 00:33:57,695 --> 00:34:05,139 Thank you, released today, SnoopSnitch under GPL. A tool that collects all the 370 00:34:05,139 --> 00:34:09,860 baseband information mostly to keep it on the phone and run some analysis on it, 371 00:34:09,860 --> 00:34:15,320 warn you about, as I said, SIM card attacks, but also those SS7 attacks that 372 00:34:15,320 --> 00:34:19,750 Tobias and I talked about today. How do you take those those attacks? Well, by the 373 00:34:19,750 --> 00:34:24,820 pagings, I showed you in the video that every time we send certain queries to 374 00:34:24,820 --> 00:34:30,169 the phone, to, over SS7, that the phone actually also receives information useful 375 00:34:30,169 --> 00:34:35,120 for the attacker. Also useful for the defender. If those empty pagings, we call 376 00:34:35,120 --> 00:34:38,990 them, are received by the phone, strong evidence that somebody is messing with you 377 00:34:38,990 --> 00:34:46,890 over SS7. Right. So it collects all that information and it produces warnings. You 378 00:34:46,890 --> 00:34:52,624 can also upload information issues, so you choose. It's optional of course, it runs, 379 00:34:52,624 --> 00:34:57,310 as I said, on a bunch of Android phones that are currently popular. It requires a 380 00:34:57,310 --> 00:35:01,603 somewhat recent Android version we haven't tested was Android 5 yet, but I don't 381 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 382 00:35:05,170 --> 00:35:11,240 to be routed. So we have access to a certain interface that otherwise is not 383 00:35:11,240 --> 00:35:16,270 accessible. And it needs of course, a Qualcomm chipset, which, as you see by 384 00:35:16,270 --> 00:35:21,650 this list, is in most current flagship phones. It's on Google Play right now. So 385 00:35:21,650 --> 00:35:29,080 download it if you're interested. Now, how does this tool work? One example only, of 386 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 387 00:35:34,500 --> 00:35:38,750 instance, IMSI catcher detection. There have been a bunch of tools so far to do 388 00:35:38,750 --> 00:35:43,980 IMSI catcher detection. The one we released a couple of years ago was called CatcherCatcher, 389 00:35:43,980 --> 00:35:49,740 but it had two limitations. One practical, one more bound to experience. 390 00:35:49,740 --> 00:35:54,790 The practical limitation was that it ran on Osmocom phones and Osmocom phones can't 391 00:35:54,790 --> 00:35:59,120 do most phone functionality. So always your second phone? And it had to be 392 00:35:59,120 --> 00:36:03,350 connected to a computer. So very unlikely that you carried this around all the time. 393 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 394 00:36:07,411 --> 00:36:11,690 think we succeeded in that. The second limitation was that we really didn't know 395 00:36:11,690 --> 00:36:16,440 how IMSI catchers behaved or we also didn't know how real networks behaved. And 396 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 397 00:36:20,640 --> 00:36:24,880 all the weird corner cases, how real networks behave and created a much better 398 00:36:24,880 --> 00:36:32,890 ruleset for for an Android based catcher catcher tool now. And the rules go in two 399 00:36:32,890 --> 00:36:37,111 categories. One is the configuration of the of these different cells. For 400 00:36:37,111 --> 00:36:41,760 instance, the lack of encryption when, you know, from the gsmmap database that this 401 00:36:41,760 --> 00:36:46,473 network does usually support encryption, that's a big red flag. Also certain other 402 00:36:46,473 --> 00:36:51,180 configurations. So that's a configuration of the network, the adjusted behavior and 403 00:36:51,180 --> 00:36:53,800 the IMSI catcher wants to get information out from you at the very 404 00:36:53,800 --> 00:36:58,290 least, the IMSI, of course, it's in the name. Right. So that suspicious behavior 405 00:36:58,290 --> 00:37:04,955 now, none of these things taken by themselves did allow you to detect an 406 00:37:04,955 --> 00:37:09,860 IMSI catcher. So we compute score over these different events, doing stream 407 00:37:09,860 --> 00:37:14,830 analysis on everything that happens on your phone and eventually then come out 408 00:37:14,830 --> 00:37:20,820 with a warning. If the score crosses a certain threshold, there's a bunch more we 409 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 410 00:37:25,030 --> 00:37:29,960 not available. So this is still ongoing work as these chipsets progress and may give 411 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 412 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 413 00:37:41,044 --> 00:37:48,080 optional, right? You get you get the alerts shown in shown in your little tool 414 00:37:48,080 --> 00:37:52,730 and then you can choose to upload whichever ones you think should be shared 415 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 416 00:37:59,697 --> 00:38:03,419 abuse, of course, we'll try to make that transparent, perhaps even put little dots 417 00:38:03,419 --> 00:38:07,950 on the GSM website so people know where abuse could be happening around 418 00:38:07,950 --> 00:38:20,370 demonstrations, around embassies, wherever. *Applause* 419 00:38:20,370 --> 00:38:23,410 You can also actively choose to 420 00:38:23,410 --> 00:38:28,090 submit data by by running an active test now usually the phone looks at everything 421 00:38:28,090 --> 00:38:32,370 that you produce, your phone calls, your SMS that's always stored on the phone. 422 00:38:32,370 --> 00:38:37,880 There's no way to upload that. And you compute a score for how secure your 423 00:38:37,880 --> 00:38:42,410 network is using the exact same metrics that we use on gsmmap. So that's all 424 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, 425 00:38:47,410 --> 00:38:51,860 click this button. It runs some benign tests, has nothing to do with your transactions. I 426 00:38:51,860 --> 00:38:55,640 guess your location where you're currently connected would be included in the data 427 00:38:55,640 --> 00:39:02,030 and it uploads it to gsmmap. So that becomes better and better. And we can spot 428 00:39:02,030 --> 00:39:09,780 more networks that, for instance, like any encryption at all. Yeah, so what's what 429 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 430 00:39:15,370 --> 00:39:20,076 yourself from mobile abuse, of course you could keep waiting for your mobile 431 00:39:20,076 --> 00:39:24,900 networks to fix all these issues, which I must say more recently, more networks have 432 00:39:24,900 --> 00:39:30,150 moved to fix issues, but still not the majority. And no network has even started 433 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 434 00:39:35,550 --> 00:39:41,770 rather have you do is start defending yourself. Check out gsmmap, see if you 435 00:39:41,770 --> 00:39:45,800 are on a network that generally protects things like encryption. You saw the 436 00:39:45,800 --> 00:39:51,750 networks that lack encryption. Don't use those. And if you really choose to self 437 00:39:51,750 --> 00:39:58,241 defense, download, SnoopSnitch, this new tool and actively look out for abuse, for 438 00:39:58,241 --> 00:40:03,080 Silent SMS, binary SMS that you receive, for empty pagings, for IMSI catcher 439 00:40:03,080 --> 00:40:10,490 evidence and help us grow this database of abuse. Right. Also help us grow the 440 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 441 00:40:15,720 --> 00:40:20,710 make the data accessible. But now it is accessible, right? Just take it as a 442 00:40:20,710 --> 00:40:26,920 library and go wild with it. Do whatever you always wanted to do with raw baseband 443 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 444 00:40:34,300 --> 00:40:37,720 all that's left for me to say is thank you very much. 445 00:40:37,720 --> 00:40:47,570 *applause* 446 00:40:47,570 --> 00:40:57,240 Herald: Thank you, Karsten, then we will beginning with the Q&A, please, for 447 00:40:57,240 --> 00:41:03,590 everybody that will be asking questions, please line up on the microphones in the 448 00:41:03,590 --> 00:41:13,660 room and for people that exit the room, please do it with no noise and quickly. 449 00:41:13,660 --> 00:41:17,390 Karsten: Now, before getting into the question, let me give you one reason to 450 00:41:17,390 --> 00:41:22,520 actually do leave now. There's a workshop happening right now or in a few minutes 451 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 452 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 453 00:41:31,240 --> 00:41:36,210 IMSI catcher. It's happening in room C, which is when you exit here one floor 454 00:41:36,210 --> 00:41:41,750 down and to this end. Herald: And additional information, the 455 00:41:41,750 --> 00:41:51,407 workshop that's Karsten says start at nineteen forty five. 456 00:41:51,407 --> 00:42:00,050 K: And now to your questions. * distant noise * 457 00:42:00,050 --> 00:42:04,800 K: Sure. Herald: OK, microphone number two and 458 00:42:04,800 --> 00:42:10,460 please, before before we before you can start number two, please do it with no 459 00:42:10,460 --> 00:42:19,270 noise that we hear the question from the audience. OK, number two, please. 460 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 461 00:42:23,260 --> 00:42:27,610 custom ROMs? Because we could just install it into cyanogen phones and apparently 462 00:42:27,610 --> 00:42:34,750 installed and it seems to work. K: Oh, OK. So the way I understood custom 463 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 464 00:42:38,920 --> 00:42:44,025 of stuff on it. Part of what we need are these proprietary Qualcomm libraries and 465 00:42:44,025 --> 00:42:47,050 at least on the phones where we tried cyanogen mod and what they are being 466 00:42:47,050 --> 00:42:51,730 removed. So if cyanogen mod could stop doing that, it would work beautifully. 467 00:42:51,730 --> 00:42:56,430 It's not that we need anything additional. We just need less to be deleted. 468 00:42:56,430 --> 00:43:04,290 Mic 2: OK, thank you. Herald: OK. Microphone number …, will you 469 00:43:04,290 --> 00:43:09,760 ask. OK, are there some questions from the IRC? 470 00:43:09,760 --> 00:43:16,090 K: I think we have a bunch of questions. Signal Angel: Actually, there is five 471 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 472 00:43:24,030 --> 00:43:30,690 these shown attacks that you proved on your speech be mitigated by… by higher 473 00:43:30,690 --> 00:43:37,300 protocols levels, like encrypted VoIP or TextSecure, things like that? And what 474 00:43:37,300 --> 00:43:41,910 will be the residual risks? K: Mm, yeah. A good question. So how much 475 00:43:41,910 --> 00:43:46,740 can you protect yourself by using the mobile network less on using it as a dumb 476 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, 477 00:43:52,710 --> 00:43:59,090 obviously your calls and texts won't be intercepted anymore if they are encrypted 478 00:43:59,090 --> 00:44:04,560 one more time in a way that's not breakable. However, this does not solve 479 00:44:04,560 --> 00:44:09,100 the location tracking. It does not solve the fraud. It does not solve the denial of 480 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 481 00:44:13,790 --> 00:44:18,140 has a lot of control over you, your location and your phone bill. None of that 482 00:44:18,140 --> 00:44:25,590 is going to go away. Herald: Another question from the IRC, one. 483 00:44:25,590 --> 00:44:33,380 Signal Angel: Yeah, um, the second one is: Wouldn't it be easier to design from 484 00:44:33,380 --> 00:44:39,902 scratch a new mobile mobile network than trying to find all flaws from actual 485 00:44:39,902 --> 00:44:45,080 networks, which is an endless task? K: Or I don't know where you would even 486 00:44:45,080 --> 00:44:49,770 start designing everything from scratch completely? The closest that I can think 487 00:44:49,770 --> 00:44:54,280 of designing the mobile network from scratch is LTE in the name of long term 488 00:44:54,280 --> 00:44:58,500 evolution. It really wants to change everything, but gives it a couple of years 489 00:44:58,500 --> 00:45:02,690 but as Tobias pointed out, those issues we pointed out today, they are 490 00:45:02,690 --> 00:45:08,220 again included in LTE. Diameter is the interconnect protocol. So we already 491 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 492 00:45:13,410 --> 00:45:18,950 it through firewalls and monitoring like we never got to update the Internet. 493 00:45:18,950 --> 00:45:22,540 Herald: OK, microphone number four, please. 494 00:45:22,540 --> 00:45:27,620 Mic 4: Yet just a short thing. Could you just provide a list of those libraries 495 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 496 00:45:35,630 --> 00:45:38,484 cyanogen mod images. K: Ok 497 00:45:38,484 --> 00:45:40,516 Mic 4: OK, and if the app is open source, 498 00:45:40,516 --> 00:45:45,900 maybe you can put it on fdroid? K: Oh absolutely. Yes. Thank you. 499 00:45:45,900 --> 00:45:50,970 *applause* Herald: The microphone number two, please. 500 00:45:50,970 --> 00:45:57,560 Mic 2: Got two questions, if I understood correctly, you need to be inside the 501 00:45:57,560 --> 00:46:02,350 operator network to actually perform those SS7 queries, right? 502 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 503 00:46:08,030 --> 00:46:12,020 anybody in the world connected to SS7 can send his queries. 504 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 505 00:46:17,960 --> 00:46:20,890 test? K: I think I'll quote Tobias here by 506 00:46:20,890 --> 00:46:23,420 saying I would rather not say anything about that. 507 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 508 00:46:29,800 --> 00:46:37,840 mistaken, is the session key. Right? It's and it should involve that nonce value, right? 509 00:46:37,840 --> 00:46:42,850 K: Yeah. Mic 2: So if it is, it already has the nonce 510 00:46:42,850 --> 00:46:48,130 value. So in order the attack to work, we also need to intercept the initial 511 00:46:48,130 --> 00:46:54,930 messages, the nonce exchange between the target and the basis station. Is that 512 00:46:54,930 --> 00:46:59,460 correct? K: No, the nonce is… as as they are. So 513 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 514 00:47:05,660 --> 00:47:09,780 right encryption key. We are not the phone. We don't have the SIM card. *Right.* 515 00:47:09,780 --> 00:47:12,600 If you just give us the encryption key, we don't need the nonce. 516 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 517 00:47:18,700 --> 00:47:25,910 actually sends you not only the encryption key, but also the nonce that is required.. 518 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 519 00:47:30,030 --> 00:47:32,430 offline now, explain how everything works. Thank you. 520 00:47:32,430 --> 00:47:35,780 Herald: To microphone number three, please. 521 00:47:35,780 --> 00:47:40,680 Mic 3: First of all, thank you for a very good presentation and very impressive work 522 00:47:40,680 --> 00:47:45,330 you've done here. *applause* 523 00:47:45,330 --> 00:47:50,050 K: Thank you. Mic 3: The question I have might be a 524 00:47:50,050 --> 00:47:55,090 little naive, but have you also, besides taking a look at this closing this whole 525 00:47:55,090 --> 00:48:00,630 issue technically wise, also been taking a look into how what measures can be taken 526 00:48:00,630 --> 00:48:04,900 legally, at least in Germany and some countries in Europe now that we have 527 00:48:04,900 --> 00:48:11,431 disclosed that basically certain rules / laws have not been fulfilled, that we can 528 00:48:11,431 --> 00:48:15,950 enforce the operators to implement this stuff on legal ways? 529 00:48:15,950 --> 00:48:21,420 K: We have not looked into it. Of course, we consider the possibility as soon as 530 00:48:21,420 --> 00:48:25,470 somebody has an overview of where these attacks happen. And that seems to be the 531 00:48:25,470 --> 00:48:31,140 issue right now. There's zero attack transparency. Nobody is looking for these 532 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 533 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, 534 00:48:43,190 --> 00:48:49,660 two German networks, mitigated them within two weeks. And these issues had been open 535 00:48:49,660 --> 00:48:54,510 for 20 years. Had they ever looked into their own data, that would have seen this 536 00:48:54,510 --> 00:49:00,060 going on. So I'm not very confident that anybody in Germany at least has an 537 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 538 00:49:04,650 --> 00:49:10,310 there's much point in litigating. Let's just stop the possibility of abuse. Right, 539 00:49:10,310 --> 00:49:14,990 instead of complaining about it happening. But I'm with you. If there's corner cases 540 00:49:14,990 --> 00:49:19,660 in which abuse just can't be stopped, let's fight it legally, of course. Right. 541 00:49:19,660 --> 00:49:24,850 And if all of you contribute information through SnoopSearch, does the empty 542 00:49:24,850 --> 00:49:29,560 pagings, if we can find patterns of abuse, of course, we'll aggregate them and 543 00:49:29,560 --> 00:49:36,680 try to move against them. Herald: OK, microphone number four, 544 00:49:36,680 --> 00:49:40,740 please. Mic 4: You said you can buy your way into 545 00:49:40,740 --> 00:49:46,790 the SS7 Network, but how easy is it actually to get your access? And what do 546 00:49:46,790 --> 00:49:50,690 you estimate: How many players are there in the network? Can you give any 547 00:49:50,690 --> 00:49:54,311 estimation? K: I have absolutely no idea. I know that 548 00:49:54,311 --> 00:50:01,760 there's some 800 companies who who are legally allowed to access SS7 and then 549 00:50:01,760 --> 00:50:06,860 those, of course, have subcontractors, legal and illegal, and some people who 550 00:50:06,860 --> 00:50:11,186 bribe them. Yet other people who hack their systems or the systems of the 551 00:50:11,186 --> 00:50:14,920 subcontractors, it's very hard to estimate. No idea. But definitely too many 552 00:50:14,920 --> 00:50:18,650 to trust all of them. Mic 4: And would it be possible for me to 553 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 554 00:50:25,710 --> 00:50:31,300 network, but I want to have access because I want to provide a service, some service? 555 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 556 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 557 00:50:40,910 --> 00:50:44,600 to tell you how. *laughter and applause* 558 00:50:44,600 --> 00:50:51,680 Herald: Yet another question from the IRC. Signal Angel: We're about nine questions, 559 00:50:51,680 --> 00:50:58,200 so no problem for me. First one, what about Windows phones, jail breaked 560 00:50:58,200 --> 00:51:04,890 iPhones, or something like this will the app in the end [be] on this phones? 561 00:51:04,890 --> 00:51:11,250 K: Our app doesn't run on anything other than Android, but the chipsets are, of 562 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 563 00:51:16,670 --> 00:51:22,070 instance, you could create a similar application. We just wanted to target the 564 00:51:22,070 --> 00:51:25,990 biggest population of phones, and that seems to be Android phones. 565 00:51:25,990 --> 00:51:33,160 Herald: Then number two, please. Mic 2: One further thought on self-defense 566 00:51:33,160 --> 00:51:41,110 as self-defense has don't has to be proportionate, I think, and identities are 567 00:51:41,110 --> 00:51:46,771 not secure in the digital sphere. How about developing some proactive, as we 568 00:51:46,771 --> 00:51:52,820 heard the word defense tools? K: Proactive as in hack the networks, 569 00:51:52,820 --> 00:51:59,010 until they have no chance but to fix? Mic 2: That's what you understood, but. 570 00:51:59,010 --> 00:52:03,010 But, I support that. * laughter * K: I'm not going to say that I dislike the 571 00:52:03,010 --> 00:52:07,620 idea. But you won't see me here next year explaining how I did it. 572 00:52:07,620 --> 00:52:11,690 Mic 2: Thank you. Herald: Microphone number three, please. 573 00:52:11,690 --> 00:52:17,070 OK. When did you check the other two German networks didn't fix the identifier 574 00:52:17,070 --> 00:52:21,800 and the issue. K. Which network do you work for? 575 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. 576 00:52:27,780 --> 00:52:30,930 We didn't, we didn't check. Mic 2: We fixed it within 24 hour, 24 577 00:52:30,930 --> 00:52:34,590 hours after our call. K: Wow. OK. 578 00:52:34,590 --> 00:52:38,300 Mic 2: On both networks. *applause* 579 00:52:38,300 --> 00:52:44,430 Thank you. Better late than never. Thank you. 580 00:52:44,430 --> 00:52:47,320 Mic 2: That's right. K: OK, so that's three out of four now, 581 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 582 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 583 00:52:59,610 --> 00:53:06,920 problems also. It's all four. I work for Telefonica, which is O2 and eplus. 584 00:53:06,920 --> 00:53:11,291 K: Oh yeah. Well, congratulations. Sorry. Sorry for spoiling your Christmas. 585 00:53:11,291 --> 00:53:13,440 * laughter * 586 00:53:13,440 --> 00:53:19,400 Herald: Microphone number two, please. Mic 2: I'd like to know why these empty 587 00:53:19,400 --> 00:53:24,180 pagings occur in the context of the location tracking, I thought, as soon as 588 00:53:24,180 --> 00:53:30,620 the phone registers in the network, the base station, which is this connected to, 589 00:53:30,620 --> 00:53:32,630 is known in the network anyway. Is that the case? 590 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 591 00:53:37,490 --> 00:53:45,590 explain that, one second, so that the empty pagings do not occure when you send 592 00:53:45,590 --> 00:53:50,380 these creepy AnytimeInterrogation messages. They are just there for spying 593 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 594 00:53:55,280 --> 00:53:59,070 into great level of detail explaining this, you need a couple of other messages 595 00:53:59,070 --> 00:54:03,320 to now track some of this location and these messages when meant for location 596 00:54:03,320 --> 00:54:09,530 tracking them and ment for other purposes. For instance, as I provide subscriber info 597 00:54:09,530 --> 00:54:14,950 that however you reach it is always the last message you need. This does do a 598 00:54:14,950 --> 00:54:19,020 paging and then to provide subscriber info really makes no sense unless you send 599 00:54:19,020 --> 00:54:23,890 something afterwards also, deliver an SMS connect to call or whatever. So the paging 600 00:54:23,890 --> 00:54:29,690 is already sent in anticipation that an SMS will come or that the call will come. 601 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 602 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 603 00:54:38,410 --> 00:54:43,610 where something follows the paging, isn't it a type of double checking whether it's 604 00:54:43,610 --> 00:54:50,230 really there or I mean, the location info itself should already be present and the 605 00:54:50,230 --> 00:54:53,510 network, isn't it? K: Yeah, yeah. It just reconfirms that the 606 00:54:53,510 --> 00:54:57,640 subscriber is really there. So it's basically saying: Somebody you just 607 00:54:57,640 --> 00:55:01,370 interrogated your location because they want to send you something. Let's check 608 00:55:01,370 --> 00:55:05,350 that you're really still there because otherwise we'll tell them something wrong. 609 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 610 00:55:10,420 --> 00:55:15,930 not anticipation or something that's coming after. It's to get the current cell 611 00:55:15,930 --> 00:55:20,970 that you are located at, because when you are moving around in your location area 612 00:55:20,970 --> 00:55:24,850 and the area that is covered by the switching center that you're currently 613 00:55:24,850 --> 00:55:31,120 being served by, your phone doesn't necessarily contact the base station. So 614 00:55:31,120 --> 00:55:37,790 it could be that that the networks last position of you is somewhere you received 615 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 616 00:55:43,950 --> 00:55:49,130 phone didn't have network contact in the meantime, the network would still only 617 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 618 00:55:55,610 --> 00:56:01,310 that the that the network knows the base station that's actually currently closest 619 00:56:01,310 --> 00:56:06,780 to you. That's also why the law enforcement uses a lot of Silent SMS so 620 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 621 00:56:12,530 --> 00:56:17,240 you send provide subscriber information, you can just send it and get back the last 622 00:56:17,240 --> 00:56:23,720 known position without a paging or you can set the current location flag and provide 623 00:56:23,720 --> 00:56:29,860 subscriber information. And only then the subscriber gets paged and you will receive 624 00:56:29,860 --> 00:56:33,530 the current location. K: And that's that's one good example for 625 00:56:33,530 --> 00:56:37,880 how SS7, which is supposed to be so insecure we can never fix it, can 626 00:56:37,880 --> 00:56:42,750 easily be fixed. There's an option that says we're using this as normal feature 627 00:56:42,750 --> 00:56:46,480 that's absolutely needed. And we have this creepy extension to also ask for the 628 00:56:46,480 --> 00:56:51,140 location. And some networks choose to not answer that. The answer was zero zero zero 629 00:56:51,140 --> 00:56:57,540 zero and nothing broke. Right. So you can just ignore the insecure parts of SS7 and 630 00:56:57,540 --> 00:57:01,890 do whatever you think is right. And for the most part, it continues to work. But 631 00:57:01,890 --> 00:57:04,040 I think we're well beyond answering your question now right? 632 00:57:04,040 --> 00:57:11,230 Mic 2: No, but from your answers. Thank you very much. But another question 633 00:57:11,230 --> 00:57:16,710 arises, because if it's actually to locate your phone and to find out which cell 634 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 635 00:57:23,310 --> 00:57:29,190 the paging call, but a whole bunch of base stations. Do you know something about the 636 00:57:29,190 --> 00:57:35,260 algorithm? I mean, how many around the last known location are paging everybody 637 00:57:35,260 --> 00:57:39,560 nationwide or how does.. K: Everybody can implement this as they 638 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: 639 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 640 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 641 00:57:53,600 --> 00:57:58,100 some networks, you don't respond. They send it in the entire country. But that's 642 00:57:58,100 --> 00:58:01,589 rare. Right? Mic 2: Thank you very much. 643 00:58:01,589 --> 00:58:12,790 Herald: Okay. Questions from the IRC? Signal Angel: Did SnoopSnitch allow you to 644 00:58:12,790 --> 00:58:20,740 reveal any kind of attack in countries. Not special name in mind. 645 00:58:20,740 --> 00:58:26,920 K: Does it allow you to detect attacks in countries? *Yeah,* yeah, *some kind of* 646 00:58:26,920 --> 00:58:32,520 *Tapsell.* I think the answer is yes. Its whole purpose is to detect attacks. And it 647 00:58:32,520 --> 00:58:35,852 also works in countries… * laughter * 648 00:58:35,852 --> 00:58:39,840 Herald: Did you succeed in detecting attacks. K: Did we succeed in 649 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 650 00:58:46,590 --> 00:58:53,880 currently people are being attacked and currently they detect that. *Ok* 651 00:58:53,880 --> 00:58:59,280 Herald: OK microphone number five, please. Mic 5: Yes, thanks, it's going back to SS7 652 00:58:59,280 --> 00:59:05,670 basics. Can you quickly explain how SS7 is implemented? Is this a VPN on the public 653 00:59:05,670 --> 00:59:10,610 Internet through the providers? What's the technical reality of transport? 654 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 655 00:59:16,640 --> 00:59:21,890 have half of the information, too. I keep learning. But so it seems that it was 656 00:59:21,890 --> 00:59:27,430 implemented initially as a network between Western European telcos and their run 657 00:59:27,430 --> 00:59:33,961 cables, dedicated cables for SS7. SIGTRAN they called this and then a couple 658 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 659 00:59:38,250 --> 00:59:42,690 other telcos. But eventually they changed that and then introduced what I call 660 00:59:42,690 --> 00:59:46,741 routing providers. So telcos are not connected to each other usually, but 661 00:59:46,741 --> 00:59:52,240 through a routing provider like on the Internet and those routing providers, they 662 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 663 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 664 01:00:00,790 --> 01:00:04,790 dedicated lines between Germany and France, say, and there's some others 665 01:00:04,790 --> 01:00:08,510 connecting and these big clouds that are routing providers. And it's actually 666 01:00:08,510 --> 01:00:12,290 really difficult to get your address routed everywhere in the world. So even if 667 01:00:12,290 --> 01:00:16,886 you connect to SS7, all you're connected to is one routing provider and that 668 01:00:16,886 --> 01:00:21,690 routing provider knows that you own these addresses. Now it's up to you to convince 669 01:00:21,690 --> 01:00:25,850 every other of the big seven or nine, depending on how you count routing 670 01:00:25,850 --> 01:00:34,250 providers that you are that guy with those addresses. So the BGP equivalent of SS7 is 671 01:00:34,250 --> 01:00:40,410 to get nine roaming agreements signed with people on these other nine operators and 672 01:00:40,410 --> 01:00:44,810 then fax those roaming agreements to everybody else involved. So they type it 673 01:00:44,810 --> 01:00:49,530 into your computer, into their computers, very manual and very hard to grow the 674 01:00:49,530 --> 01:00:52,830 network. But for the most part, it doesn't change, of course- 675 01:00:52,830 --> 01:00:57,940 Mic 5: So that the low level transport is not really an attack surface from the 676 01:00:57,940 --> 01:01:00,840 public Internet. K: It can be the low level transport can 677 01:01:00,840 --> 01:01:07,090 be an attack surface if people just stupidly leave open their local networks. 678 01:01:07,090 --> 01:01:11,156 But it's rare. It's much more common, speaking about our talk next year, 679 01:01:11,156 --> 01:01:15,844 hopefully on the other interconnect networks, there's one interconnect network 680 01:01:15,844 --> 01:01:22,240 for data roaming. It's called GRX. And since everything is IP anyway on data 681 01:01:22,240 --> 01:01:26,610 roaming, people sometimes do leave it out on the Internet or just do it unencrypted 682 01:01:26,610 --> 01:01:31,010 over the Internet. And it does seem to become more popular also with the SS7 683 01:01:31,010 --> 01:01:37,440 replacement Diameter, which again is pure IP. So there's no dedicated thing that you 684 01:01:37,440 --> 01:01:41,660 first have to encapsulate in a VPN before you can route it over the Internet. You 685 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 686 01:01:47,060 --> 01:01:52,170 do it anyway. Herald: OK, the microphone number six, 687 01:01:52,170 --> 01:01:55,310 please. Mic 6: OK, my question is, if you could 688 01:01:55,310 --> 01:02:00,451 comment why these message were put in the protocol at the first place, it they are 689 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 690 01:02:07,270 --> 01:02:11,620 that you pointed out are as easy to fix for the network operators. 691 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 692 01:02:16,780 --> 01:02:22,470 message in the standard and then call it AnytimeInterrogation, gosh, like that 693 01:02:22,470 --> 01:02:25,610 invokes feelings for me, interrogation room and all. I mean, this 694 01:02:25,610 --> 01:02:30,440 is spy stuff, right? And there's no practical, purposeful but. Right. Who 695 01:02:30,440 --> 01:02:35,000 wrote SS7 standard? Western European governments being afraid of the Russians, 696 01:02:35,000 --> 01:02:39,060 of their own citizens, who knows? Right. I don't know why they put every single 697 01:02:39,060 --> 01:02:44,280 message in, though. So your second question was what again? 698 01:02:44,280 --> 01:02:49,060 Mic 6: If the other vulnerabilities are as easy as to fix? Or just blocking messages. 699 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 700 01:02:55,730 --> 01:03:02,270 AnytimeInterrogation can be fixed, as can, for instance, as does SendIdentification 701 01:03:02,270 --> 01:03:07,310 message, right. You just block that has no purpose, routing this internationally. But 702 01:03:07,310 --> 01:03:11,600 the other queries on this page, at least you need those internationally, at least 703 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 704 01:03:17,430 --> 01:03:21,010 from anybody who's not your roaming partner, right? Don't respond to those 705 01:03:21,010 --> 01:03:26,520 people and then do some plausibility checking, secondly, make sure that if a 706 01:03:26,520 --> 01:03:31,380 subscriber is actually in your own network, that you don't honor requests from another 707 01:03:31,380 --> 01:03:36,600 country. Right. And that should remove most of the issues because most abuse comes from 708 01:03:36,600 --> 01:03:40,340 other countries. It's just more likely if there's 800 parties connected to this 709 01:03:40,340 --> 01:03:46,901 network that the one doing the abuse is not yours. Good question. *Thanks.* 710 01:03:46,901 --> 01:03:59,000 Subtitles created by c3subtitles.de in the year 2021. Join, and help us!