 These guys have made awesome stuff and have really done really cool research and opening up for all of us all these hidden protocols that are behind our mobile phones where no TCP IP is where SS7 and all these other space protocols are spoken. So a big round of applause for those guys. It's nice to be back and especially nice to be able to pick up exactly where we left at the Chem 2011 where we talked about GPRS attacks. Some of you may remember we showed how to intercept GPRS and it was somewhat complex. Cryptanalysis breaks some of the weaker ciphers. We want to take those a few steps forward today. This talk will be somewhat different from our other talks. We get a lot of questions over the years. How do you do mobile security? How do you guys approach problems? How can I get into mobile security? So we want to focus on answering that. I hope that's okay with you. So we want to talk about what worked but also what failed and how one goes about solving these types of problems that you face when looking at proprietary weird systems. We'll also have some cool results so that shouldn't come too short but focus is on how to do mobile research today and in the future. Of course you spend a lot of time just writing out ideas and we want to go through such ideas in two technology areas. There's Imzi captures picking up from results that you all submitted to us through some application that has been available for a couple months. And then we want to look at GRX which is a GPRS related technology so related to the Chem 2011 definitely but also related to the last Congress talk where we discussed SS7. GRX is very related to SS7. We'll discuss in detail how and what abuse scenarios come out from there. And finally we want to talk about what you can possibly do to further this research. So let's start with Imzi catching. And before that let's start with a big round of applause for everybody who contributed data through Snoop search to GSM. This has become a great research repository that has helped people all around the world understand which networks are secure and which networks are not and you all made this possible. So thank you very much. As you see and note that this is a logarithmic scale. Every month we're collecting 10 times as many samples now since releasing this application Snoop Snitch than we ever did before. So this is some 100,000 people running this application and once in a while pushing data onto the servers. And we were able to double the number of countries covered on GSM map pretty much within that time period. So again great information source. One subset of this data deals with Imzi catchers. The application notices when Imzi catchers could be in your vicinity and then offers an option. This is not automatic to push this data onto our servers. And we want to walk you through what we do with this data today and predominantly how complicated it is to deal with such data and how long it takes to gain really deep insights into complex data sets. So what does Snoop Snitch look for to detect an Imzi catcher? Imzi catchers you all know right? It's fake base stations that pretend to be your home network but really it isn't and it lost your phone to connect to it at least disclose its information, the Imzi to the cell. So in order to do that the Imzi catchers have to behave slightly different from normal networks to get all the information they need. Also they are somewhat more restricted than normal networks. For instance they don't have access to encryption keys at least so we saw it so far. So they're limited to somewhat weaker encryption that they can actually crack on the flight. And Snoop Snitch looks for these heuristically. It looks for weird configurations that normal networks wouldn't have or that differ from what Snoop Snitch has seen your normal network use usually. It looks at behavior for instance asking for the IMEI of a user is somewhat uncommon at least to do it repeatedly when a network had already gone through full cycle of registration. And then of course we look for encryption. As I said these Imzi catchers don't necessarily have access to the key material needed to do really good crypto. And then lots of you submitted catcher events in fact in the thousands by now. And we always knew that there was a chance of false positives that your phone could actually show you an Imzi catcher when it wasn't there. But through this research now we learned that the number of reasons for there being false positives grows tremendously as you understand the data better. And in fact our threshold for when we are really certain that there is an Imzi catcher kept growing and growing and growing because there were always new reasons why something could be something other than an Imzi catcher. So you see that only a few percent of the data we collected we would really say this is guaranteed an Imzi catcher. Everything else could be eyes away. We really don't know prior to further research and just better heuristics. And I want to walk you through a couple of reasons why Imzi catchers are really difficult to detect. In those three categories obviously configuration behavior and encryption. And you see that the events that we do see in the submissions they cover all areas with some clear favorites. And those clear favorites will also come out in the false positive reasons. So there's reasons to believe that a lot of what we saw as submissions is actually false positive. And we took this as research feedback and we'll talk in the end what's happening with Snoop Snitch next. But let's go through three of these areas and see why it's not so simple to detect an Imzi catcher rather distinguish it from other possible explanations. Configuration. So we saw that if a cell is configured in such a way to have no neighbors to be in a location area that had never really been seen before by this phone or be in a location area that doesn't really match where you physically are, match your GPS coordinates that that's a clear giveaway for an Imzi catcher. Turns out though networks do show this behavior through weird network setups. For instance if you enter the subway in Berlin you are in a different country almost. Well okay the country code stays the same but you're in a different city altogether. The subway mobile network is it's entirely different mobile network. They have different location areas, they have different cells, different configuration cells. Some of them may not even offer 3G service so it's very suspicious. 3G is hard to crack so Imzi catchers don't do that very much. So that's a large source of false positives. Another source is just the limitation of the data we're working with. You may remember we get the data from the Qualcomm chip sets and it's very expressive data but the Qualcomm chip set itself doesn't even know what radio channel it's talking on or at least not the part that we get data from. So we need to infer that from other information and it works in let's say 99.9% of cases. But as you keep measuring the network once in a while it will fail and then this is the first little heuristic that if several other false positive causes add up will trigger an Imzi catcher warning. So really difficult to work with this mobile network and once you have 100,000 users every single 0.1% possibility becomes a daily occurrence. Let's talk about behavior. So we saw that if a network asks for your Imzi and your IMEI even though it had seen both before, that's very suspicious. Why would the real network ask that? That's likely an Imzi catcher. And then more suspicious, what if that very cell rejects you right away even though other cells from the same network accepted you happily before and after? So clear giveaway for an Imzi catcher? Unfortunately not. Femto cells do exactly that. Femto cells are these little kind of home router shaped GSM or 3G cells that offer service for just yourself. The phones you register, that's why it needs the IMEI and the SIM card you were saying, that's why it needs the Imzi. And if you're not that person but let's say the neighbor the Femto cell works exactly like an inventory creating Imzi catcher and there's very little way to distinguish it except for maybe cryptography. So that Femto cell can do really good cryptography because it talks with the real network and an Imzi catcher wouldn't. Well it turns out that the heuristic that says if your network can do let's say A53, anything less than A53 suspicious that doesn't work either. There's networks like in Germany E+. They keep going back and forth between different encryption ciphers for unknown reasons. I'm sure there's a technical explanation somewhere overload or whatever but the network itself looks extremely suspicious. It forgets that it did good encryption in the past and now goes back to weak encryption exactly like an Imzi catcher would. So and also the inverse could be possible that in fact Imzi catchers would use A53 and we'll talk about that in a few minutes. So that was the first example and kind of us trying to well both give back to you in terms of result but also let you know that we still keep working on Snoop's net and it still isn't perfect so let's wait another talk or two until we can really have the perfect heuristic and everybody fingers crossed is then safe from Imzi catchers. Until then please do click that little upload button if you do see an Imzi catcher. It helps us tremendously in understanding these things better and keep improving the metric. Was that mini update on what we have been up to around Snoop's net? Let's switch gears now and come back to GPRS and in particular the GRX, the GPRS roaming exchange. Now it's not just used for GPRS, it was invented for GPRS but it's also what's still used in 3G. So almost all data connections today use GRX and they use it as kind of a back end technology. The phone will connect to a tower. The tower is then connected to an RNC. The RNC talks to an SGSN. In the country where you currently are. So this could be a roaming scenario. This doesn't have to be your home country. And then there's a GGSN somewhere in the world that you define through the APN. You type in an APN into your phone or you got an SMS telling you which one you should use. And that GGSN is always the same no matter where you are in the world. So every SGSN in the world needs to be able to reach these GGSNs and that's what the GRX network is used for. It connects these different types of nodes that are on your path to the internet. So whenever you receive an internet packet on a mobile phone it has gone through a GGSN from the internet then through the GRX network even if it's within one operator and then touches the SGSN and is finally forwarded to your phone. Now the terminology will keep it simple here. The most important one you need is a PDP context. It's a collection of all the identifiers. You need to establish this connection and it's shared basically between all the nodes and the chains. Even the phone knows it all the way to the GGSN. And the most important identifiers here are the tunnel IDs, the TE IDs. There's two, one in each direction. Think of them as like IP addresses. It's what makes the different tunnels that are happening concurrently be distinguishable from another. So first, this is GRX. So let's briefly touch on the research question that we found interesting around GRX. And that is, can somebody who is also connected to GRX do something to an existing customer or even to an existing connection? Now this question is partly already answered. Philippe Langlois, he gave a nice talk at Hack in the Box where he enumerated all kinds of denial of service possibilities. So we know that somebody who's also on GRX can cut you off from the internet. We know of a bunch of fraud possibilities. So to, well, let's not get into that. That's really for the networks. And then we're interested in all this stuff that would actually affect you as the user. Any privacy intrusions possible through GRX? And nobody had really looked at that yet. So men in the middle attacks possible. Is local intercept possible? That is recording traffic passively or maybe it was an IMSI catcher even and then deciphering it. And our connection hijacks possible, right? So that's what we want to spend the next couple of minutes on trying to figure out are these possible. And we'll assume that the attacker has GRX connectivity. At least for now. We may release this assumption a little bit later in the talk. We'll assume that the attacker knows the IP address. Now within GRX is kind of a close network, but it's still IP-based. The IP address of the SGSN. It's kind of easy to find this either through SS7 or GRX itself. And we'll assume that you have the IMSI of your victim. Now this may be a little bit harder to get now that at least the HLR queries were mostly cut off. But there's still plenty of ways to get people's IMSI address. And as long as that's the case, those attacks that we are now talking about at least have their prerequisites met. So let's get into this. And when we got into this early in the year after Congress, we thought wouldn't it be nice to have kind of a man-in-the-middle attack where you spoof both an SGSN and a GGSN. And it so happens that somebody had already had this idea a little bit earlier. PT Security, awesome research team out of Moscow. On their block they proposed an attack where they said you can spoof both a GGSN and an SGSN over GRX and then you become a man in the middle. And look out, perhaps you can explain us how this attack was supposed to work. Yeah, sure. So the idea is pretty easy. So between the SGSN and GGSN there is a tunnel. And the idea is that you pretend to be an SGSN towards the GGSN and GGSN towards the SGSN. This is done sending an update PDP. PDP is the user context. And faking towards the two parties that you are a new one. So a new SGSN and a new GGSN. To do this, you actually need two little numbers. The tunnel IDs that you see there. And there is a problem in the attack that the Russians presented. So they assume to have these numbers. Those numbers can be derived from the Create PDP. It is the very, very first message that is sent between SGSN and GGSN. And it's clear that if you can access that message, you are already in the middle. So we said, okay, that's interesting. But we want to do something more close to reality. So what can we do? Well, let's look into the standard. Let's find some other message that is exchanged between the two or between other elements. So the most interesting one was the SGSN context request. That is used between a SGSN and another SGSN for handovers. So they talk to each other and they exchange the key material, the IP address of the user, and so on. And also some of the numbers we need, so the TID, the GGSN IP, is included in that context. So we said, okay, let's send this message. We get back a nice lot of information. We can start sending the update PDP towards the GGSN. And we know the TID there. And then we want to start sending the other update PDP on the other side. But there is a little problem. So the TID that you need is actually different from what you get from the SGSN. It's not that different in some implementations. So we found some relation between the TID that you get from the SGSN in your response and the one that needs to be used towards the SGSN, SGSN spoofing the GGSN. So we said, okay, we can guess that. It's okay. So these are by the standard two random numbers. And you can see how random they are, right? At least in relationship to one another. One is easily guessable from the other. And one is known to the attacker. So this is where the randomness breaks down. Okay, so what is the next problem? Well, there is not really a message that can be sent to the SGSN and saying this is the new GGSN. There is only two possibilities. One is that you are an SGSN and you talk to the GGSN. Okay. And then the GGSN can send the message to the SGSN just to update the quality of service, but not to replace the GGSN. So unfortunately, this scenario doesn't work as well. But okay, let's try something else. Among all the messages that will be found, we thought, okay, let's try to see how the handover works. This is target initiated. It means that you are moving towards a new cell and the SGSN that is serving the new cell is different from the one that was serving you before. In this case, the new SGSN will ask the old one for your keys, for your IP and everything. And that's what we do. And after that, we say to the old SGSN, okay, everything was fine. Now the user is here. And if you find any packet that is on the flight, let's forward it to us. We will take care of that. And then it should pass towards us. But there is a little problem there too, unfortunately. So between the RNC and the GGSN, the original one, there is a direct tunnel. There is a solution used to improve the performance of the network so that the RNC, instead of talking to the SGSN and then to the GGSN, talks directly to the GGSN. And when we send our contacts back, this is not properly propagated to the RNC and we don't get the data. Another attack that could have worked, but not yet. And it kind of makes sense that the RNC doesn't forward the data here because this is one of two possible handover scenarios. The phone can either stay on the existing cell and tell the existing cell, hey, create a new channel on the new SGSN and until you can do this, I will busily send data. So this is when the phone is busy. This case, however, is used when the phone is idle. When the phone doesn't have an existing data connection. So it says, I'm free to move to the new SGSN. There's nothing urgent to send. I'm connecting to the new SGSN. And then the new SGSN tells the old RNC forward the data and it's kind of logically clear. That makes no sense. The phone has no data. It was in this idle state. So whoever implemented this, either they foresaw this or they just never noticed that it's not a problem not implementing it. So somehow this dropped out from their solution. But you can see how as a researcher you really have to try a lot of different things. We started with the idea that seemed to obvious one, the one that the Russians had inspired us to do. We then kind of added a little bit of handover. Here's another way to try to abuse handovers. He has yet another way to try to abuse handovers. And this is now the other scenario. The one where I said the phone is so busy, it can't itself go to the new SGSN and knock on the door. It needs a guaranteed seamless handover. So in this case, the old RNC tells the new RNC knock knock, please reserve a channel for somebody who's coming and please then forward me all the information. So we sort of, we did this to an SGSN and RNC that already has a user that may forward us to traffic anyway. Turns out they don't because you specify in that knock knock the radio message from the phone which basically says, hey, I'm waiting on this channel for you, please contact me. And then supposedly the RNC goes to that channel, checks his phone and it fails. There is no phone there. So it's really hard to find out a combination of messages that actually does allow for any type of realistic attack. But we're getting closer, just two more. So the next idea was another message in the standard that is probably not very used or very known, that is the internet connection that is started from the network side. So it's not you that decided you want the internet, it's the network that says let's activate the internet for you. And this works if you previously had a connection then you disconnect and the GGSN still knows about your IP. And suddenly it receives some packet for you and says, okay, I have to deliver this packet. Let's re-establish the connection to the mobile. So it sends this pd notification request to the GGSN that forwards it to the mobile and the mobile can accept the new connection and then there is a new IP address that you specify. Unfortunately, still in our tests we found out that most mobiles, modern mobiles are constantly connected so they never disconnect from the network. And even if they do for some sudden reason they connect immediately and we don't have the time to run our attack. So, well, okay, let's see what else do we have? Yeah, one last attack that we tried and this is the closest we got to men in the middle. And this is now putting together a lot of different ideas. SS7 and SS7 related technology called Camel and all this GRX stuff. So SS7 you guys remember, right? It's a routing protocol like GRX but it's a roaming that is, it's used to basically exchange SMS and stuff like that. Also an extension to SS7 is called Camel. Camel allows the home network to influence a roaming subscriber. For instance, if you mistyle a number, mistyle as in you leave out a country code, Camel is nice enough to add in the country code, right? So what we can do over SS7, even if the person isn't roaming, so this works anyway, is we register ourselves as a Camel server, okay? So every time the phone does something now, we are being asked whether this is correct or whether it should actually be doing something else. Yeah, nice technology, right? So as an immediate effect of that, if we set certain parameters, the phone gets disconnected. And as we saw as the problem in the last attempt, phones today immediately try to reconnect. Within milliseconds, the SGSN then contacts us, the Camel server, saying, this phone wants to connect to the internet using this APN. Is this the correct APN? And we can change the APN, right? So the SGSN would then use the APN, look up the GGSN IP address over DNS, connect to our GGSN as the internet access point. So that would make for really nice men in the middle. Again, it comes with some restrictions. First of all, the APN that we provide over Camel has by the standard a very low priority. So if somebody configured a default SGSN, in the default APN in the SGSN, then this has higher priority. So the default trumps the one that we provide. However, we can also change OIs. I think it stands for operator identity. You see the middle part of this DNS query. We can also change that using basically the same method. And this one has the highest priority. So somehow the standard is confused here. It says, if somebody from the outside tells you something and you already have a default, ignore the thing from the outside. But if that same person from the outside tells you something slightly different, ignore your default and override it anyway, right? Not sure if this is intentional. I can't think of a reason why. So this first complication we got around. There's a second complication, though, for some networks and only for the home subscribers. They just don't allow you to connect to other APNs. Probably for fraud reasons rather than security reasons, but they just don't allow arbitrary APNs in foreign networks. In roaming scenarios, this looks differently. So this is an attack that works against roamers rather than home users. And also, last complication, the network needs to implement the latest version of Camel, which most networks don't do. So after all of this research, after putting together the SS7 attacks with extensions and GRX and whatnot, we now have an attack that works against some people in the future when this Camel version 3 is finally rolled out. Pretty disappointing, right? For six months of research. But that's how it goes sometimes. And that's what we wanted to relate to you as, you know, if you want to get into mobile research, this is what you're going to face. You try a bunch of stuff. You learn a lot, but you don't necessarily have stuff to present at a conference up until now, and now we're getting into the real attacks. Not men in the middle though. So this is the closest to men in the middle that we have gotten, something that sometimes works and more so in the future, unless networks get back together. So, real attacks. Let's just demo something. The cable there. Let's plug this in here. Oh, you want to show the slide first? No, let's show the slide later. Okay. Let's build a little bit of suspense. So the idea here now is to tie together what we just learned about GRX with what we in the first chapter learned about IMSI catchers. All right? Okay. It should work. So what we do now is we have a mobile that is currently served by one of the four German networks. And we discovered the SGSN IP by some means, and we will query the current key and all the context information that is related to this user. Or GRX. We will not use the current key. We will use the key that we will use in the future. So let's start with the query. Okay. It means we need maybe a couple of seconds. Is the VPN connected? Yeah, yeah. Yeah. I need to see if there is something there. Maybe. Okay. We got the response. This is the response to the context request. I had here a t-shark running. You can already see the keys that are exposed. And I have a nice script that strips off the traces, all the future keys. Oops. I didn't receive any. This happens because the SGSN... This happens every fifth time. So what happens here is you ask the SGSN for the keys that are used by this mobile. And it will tell you the current key and other keys that it has in the cache. And usually it has five keys total. So every time you ask it, you have one fewer. And sometimes it only tells you the current one. So if we do this again, we should now get... Let's try again. Five. I just did airplane mode and back. And let's try again. Okay. You got the tuple. So let's do this. Nope. Again. I'm a bit suspicious that something is wrong here. Okay. Still not... But you do have the current key, right? Yeah. Now the current key will be useful in the next demo that we do. But here we want a future key. So what's going to happen next? If you figure out this key, we will load this key into an IMSI catcher. And this IMSI catcher can then authenticate to the phone. So what was supposed to be an unbreachable security feature 3G, which this isn't, we can get around. But also we can do state-of-the-art encryption. There's no need to crack any keys anymore if you do get it through SS7. This looks better. This looks better. So much longer response. That's more promising. Let's see. Yeah. So here you see these are the future keys, these four. Yeah. Open one of them. Yeah. They include the authentication challenge and response that we will use in our IMSI catcher. So I run this. This will insert all the necessary information in our database that I use with a fake cell. This fake cell is set up like a real IMSI catcher, but we try not to interfere with the real networks. We will use a frequency that is allocated at the camp only and also a different cell identifier so not to catch you. We could configure this now to telecom Vodafone E plus or two, but if we did, probably a hundred of you would also connect to it. I mean, they are already trying to connect. We set this up to our own ID, but that's beside the point. The point is that this can now use a key that's coming out of the SIM card of this phone as if it were the real network. And that's really what hadn't been possible so far. So we have that. So I'm registering there. Let's see. A lot of things are happening. And this is the connection that we wanted. So this is a data channel, gprs. And like a normal network, we ask for the identity just because we are an IMSI catcher. And then we say, let's start the authentication and start ciphering. And you know what? We use the latest cipher that is available for ciphering gprs. And this is actually even better than what the real network provides. So we were going to say at this point this makes for an IMSI catcher that's completely distinguishable from this network. Then we noticed that the real network can't do this crypto. So it's still distinguishable by us being more secure, apparently. But of course you can adjust to whatever level now. There's no upper limit anymore that was there before. Which makes, of course, IMSI catchers a much more scary proposition in the future if even the encryption heuristics that I said are maybe the last ones that can help us distinguish them from, let's say, IMSI catcher, from FEMTA cells, if even those are not working anymore. So IMSI catching was full authentication. If it were 3G and full encryption. That's the first thing that GRX enables. Let's talk about a few more even scarier propositions around GRX. So far everything we've shown assumed that a person, an attacker, is connected to GRX to be able to talk to these SGNs and GGSNs. And the protocol they used to talk is called GTP. The GPRS tunneling protocols. It's a whole separate family of protocols that they're using. And this would really only be used within private networks or among groups of friends. Turns out though that hundreds of thousands of GTP nodes are exposed on the internet. We get the impression that some of these are kind of net routers, so they respond to a bunch of IP addresses. For instance, the one in Japan, the soft bank, the cobb one that grows by some 50,000 IP addresses every week. So ISA Summit is very quickly building a network, or they just keep adding IP addresses that Chodan can find. This got us curious, what is behind these IP addresses? And we also did a full sweep of the internet scanning for GTP, but not just testing that GTP is there. We also wanted to see what protocol messages are supported by GTP. So it turns out that many, some 300,000, are not accepting any control messages. They just open the data part. So those maybe, I don't know, Cisco routers, or at most if it's mobile networks, some E-node, B-nodes, so very peripheral nodes that don't expose control onto the internet. Then another 300,000 or so nodes of the ones we found, they didn't respond to any control messages that we know of, so people seem to be using GTP for many other purposes too, even though it has GPRS in its name. It's apparently just a useful tunneling protocol. But then still, a significant number of things that should never be found on the internet was either responding to some queries, or even, these are the 580 listed here, to queries that are specifically honored by SGSN or the modern variant MME. This is for LTE networks, right? And you see that there's somewhat of a geographic skew, so some networks have more than 100 of these, well, one has more than 100. But overall, we find 25 network operators, or rather, 25 countries and over 30 network operators to expose SGSNs on the internet. Now, what does that mean? Combined as what we just saw in this demo, you query an SGSN with the SGSN context request, and among other things, it gives you the current encryption key, right? So for all these networks, and probably a bunch more, if you query from the subscriber network, which is from the internet, but if you're the subscriber to, let's say, Vodafone or Telecom network, you can probably reach the SGSNs more likely than from the internet. Now, it's still no guarantee, but it will be many thousand more. You can query them for current encryption keys. And what does that enable? Well, first of all, of course, passive intercept. If you can record a transaction using an OsmoCom phone, which is still an awesome research tool, or a programmable radio, for instance, the ones you have hanging around your necks, for 3G, yes, there's one, you record this information, you query for the key over GRX, or over the internet, if it's one of those 580, and you can fully decrypt everything that is happening. All data, SMS2, in many cases, and if this is an MME, even 4G traffic, right? We're not going to demo this now. We didn't expect too good network coverage here in our 3G recording equipment. It's really flimsy when it comes to network quality, but we did show something like this back in December. So what we then showed for just 3G voice calls, now is also possible coming over GRX and over the internet. That's really the scary bit here. We did want to show one more thing, though, what you can do with these, with the sometimes internet-connected SGSNs. So, yeah, so continuing on the previous trace, we were doing some SGSN context requests. What you can do next is update the context so that we fake to be the new SGSN and the GGSN will forward the data to us and we can impersonate this user. So we still need the IP of this guy. We will be able to continue the established connections and establish other ones, new ones. So let's do this. I start the mobile data. So, okay, the connection is not very good here, but now I will send the same message again and hopefully this time we will also update the connection. Yes. So what you see here is that we just updated the connection in a way that we get the packets that you are seeing. These are actually packets that should reach the mobile. So you see some TCP traffic and we can also show that we've got now the IP of this user. So this is the IP and this is the network. Right. So this is full connection hijacking. You can now use somebody else's IP address who was supposed to be on the mobile network and maybe not more scarily because hijacking allows for a lot of fraud, especially if those IP addresses are allowed let's say corporate APN so you can now reach internal IPs and whatnot. So this is really scary, but maybe more funnily, the network keeps sending stuff out. Just it never receives a response anymore. We stole that tunnel. So we, for instance, see all the DNS responses and for a long time you keep seeing what kind of DNS connection somebody is trying to initiate. This is, I don't know if you can read this. This is what an iPhone keeps doing. Really every second keeps trying to reach all kinds of weather and bullshit apps, but then if you had something more interesting on it you can really build a profile of a person's app repository here. But more interesting, as I said, you can see somebody's IP address and then have access to whatever this IP address had access to and in mobile networks this is often corporate APNs, so private IP segments. And that's everything we wanted to show in terms of attacks today. So again, lots of research, some interesting results, but certainly more questions than answers here, right? Lots of possibility for either you to extend the attacks or the networks to close these vectors sooner than you can get to them. And this must start by more filtering on GRX. It's absolutely unacceptable that SGSN, this core component, on the pass of everybody to the internet, is exposed on the internet to really all attackers and accepts control messages from any IP address in the world. That must stop, right? Fortunately it's just 30 or 40 operators who are so widely exposed, so that should be manageable. But the much larger problem is GRX, the GRX network itself. You should never as an operator talk to somebody who isn't your roaming partner. We noticed that most everybody talks to most everybody else. It just isn't much in the form of filtering. And much less even, is there any plausibility checking? So rarely any network checks things like, if somebody from the other end of the world ask about information from my customer, pretending that this customer started using their services. Has this customer been seen in my home country right now, a few minutes ago? If so, don't answer that request from the other end of the world. We have not seen this deployed anywhere, but there are boxes that do that and hopefully they do get deployed quite quickly to bring this up to kind of internet age filtering, right? So that's what we had done so far. This is now when we start talking about you and what you can or should be doing. Well, first of all, we want to give you a better tool. An even better tool. Snoop Search is officially released as its 1.0 version today or has been a few hours ago on Android, hopefully now, but definitely Google Play. So after lots of bug fixing, we also improved the ImziCatcher metric once again based on all these results. It should have a lower battery impact. Some of you complained that it drains the battery quickly. That was the case. That should be passed now. We added two little options that allow you to run this as a mobile IDS, basically leave a phone at home and have continuous measurements over what is happening in your vicinity. Now, by default, this sends it to our server, but this is open source, right? Just change the server address. Throw in a new SMIME key so you get encrypted dumps from your phone. Or you download it from the phone directly. Everything is stored on the phone locally. And if you're even more curious and want to look at stuff live, you'll love this next feature. It's definitely my favorite. Implemented a live wire shark export of all the 2G, 3G, and 4G data that this Qualcomm chipset sees. So finally, research tool, you just plug it into a computer and it shows you everything that's happening with your phone and the mobile network. Not sure what you'll be doing with it, but I'm sure I'll be impressed and so will be many others. So go crazy on this. Thanks. Now, with this, you can do a bunch of stuff. I wanted to give you one more concrete thing that we may want to work on together over the next couple of days. We're running this little challenge where we take this very IMSI catcher to this black-nosed caravan and we run it with ID CrashMe and it wants to be crashed exactly as it says. Let's find ways to fight back IMSI catchers. If you really know we are on an IMSI catcher, let's find some vectors to at least exhaust their resources or maybe even make them crash. We have a few ones already, but we want to have this as a challenge. You guys crash this, come talk to us, let's investigate how to do this and let's create a repository of ways where we know there are IMSI catchers to fight back over radio. They're intruding our radio waves. Why not do it the way around? We will discuss some results. Gosh. In a workshop on day three, that's two days from now in the BER village, so come join us for that too. Let me just very quickly plug two more things that my team is doing, a fuzzing workshop and a biometrics workshop. If those fancy you, come see those too or come meet us at this caravan. We brought a bunch of hardware that we know is hackable and we'll explain you how to do that. We add into hardware hacking, on top of mobile hacking, that's where you should come. Luke and I just left with thanking a bunch of people, Jakob and Dexter, and Linus and Alex, as one that I'm forgetting, there were five Lukas obviously and everybody else who contributed to this. It may not look like a lot of results, but it's a lot of work and it's just this increment every single time. It's just so exciting and really labor-intensive and I couldn't do this without this awesome team. So thanks a lot to them. Thanks for you for attending here and a proactive thank you for using all these tools and presenting these talks in the future. I'm much looking forward to it. Thanks a lot. Thank you. God's day. Happy birthday to you. Thanks a lot. But now on to your questions. Who has questions? If there are any questions, please align at the microphones in the aisles. No questions? If there aren't, then thank you and a big round of applause.