 My name is Cooper Quinton, and thank you for coming to my talk, Detecting 4G Base Stations in Real Time. First a little about me. I am a senior security researcher at the EFF Threat Lab. I have a toddler, so you'll have to forgive the dad jokes and possible baby noises in the background. I'm also a former teenage phone freak. I may have built some boxes to do some nefarious things back in the day, which might explain why I got into the work that I do now. If you're not familiar with EFF, we are a member-supported nonprofit. Over half of our annual funding comes from small donations from our members, individual donations, and we defend civil liberties online. So we think that when you get online, your rights come with you, and that when you're using technology, you still have rights, such as freedom of speech and the right to privacy. And we've been doing this work for 30 years this year. We started in 1990. So we have a lot of experience under our belt. We've been defending the internet and defending hackers for a long time. I work in the EFF Threat Lab, and I'll talk a little bit more about that in a second. But I want to first introduce my colleague Yamda. She can't be here with me on the DEF CON stage today, but none of this research would have been possible without her hard work. This is as much her project as it is mine, and she is an incredibly smart, incredibly talented person. So if you see her in the virtual halls of DEF CON Save Mode, please buy her a virtual beer or follow her on Twitter. Her name is at Rival Elf, and she is a giant sentient, very excitable radish. So don't be scared when you meet her. This is an actual photo of her. A bit about Threat Lab. We look at technology that targets at-risk people. So by at-risk, I mean people who are at risk of harm just for being who they are, having the beliefs that they do. And this includes activists, human rights defenders, journalists, domestic abuse victims, immigrants, sex workers, minority groups, political dissidents, and so on, basically anybody who is at risk. So this is the sort of technology that we research and try to get a handle on. And we do this work because even though cybersecurity teams and anti-virus companies are doing a good job of what they do, they mostly care about the type of malware that affect their customers, which are usually enterprise customers. And this is things like ransomware, banking trojans, things that steal sensitive corporate data, things that affect bigger businesses. And we get to care about the types of technology that infringe on civil liberties and human rights of at-risk people. Because these people don't necessarily have the budget to pay a security team, but we also, by virtue of working for a nonprofit, don't have to worry about meeting a bottom line at the end of the day. So we'd like to think of ourselves as the security team for people who need it most and yet can afford it the least. Our goals in this work are, of course, first and foremost to protect people. We want to make sure that the people are interacting in the communities that we're working with are safe and able to express themselves and able to exercise their human rights. We want to broaden the community's understanding of the sorts of threats they face, who the threat actors are, what their capabilities are, and what sorts of technologies they might be facing. And we want them to better understand their defenses as well, how they can protect themselves in what ways and what sort of measures they might need to take. We want to expose bad actors such as nation states or companies or cyber mercenaries that are going after people that are building technology to spy on civilians and violate human rights. And we want to make better laws because we're a legal nonprofit at the end of the day. We want to make better norms and better laws and better norms in civil society so that these sorts of things don't keep happening again and again. What I want to talk to you about today is cell-site simulators, also known as stingrays or MC catchers. I want to talk about how they work, some previous efforts to detect them, and why I think that those efforts aren't so great and a new method that we've come up with to detect them here at EFF. And also how to fix the problem of cell-site simulators once and for all. First, a little bit of terminology. The UE is the phone. It's just the phone stands for user equipment, but it's just the phone, the thing you're making the calls on. The MC is the International Mobile Subscriber ID. This is the ID that is burned into the SIM card and unique for each SIM card. The IMEI is the International Mobile Equipment ID and this is the unique ID for the hardware that's burned into the hardware and can't be changed. The E-node B or the base station, this is what the UE user equipment, again, the phone, this is what the UE is actually communicating with. This is the thing that's at the end of the antennas that you're talking to. The ERCIN or EARFCN is, this is the frequency that the UE and E-node B are communicating on. The sector is a specific antenna that is attached to the base station or E-node B. An E-node B can have multiple sectors and each sector basically is an antenna pointing in a specific direction. The MIM or Master Information Block is broadcast by the E-node B and tells phones where to find the SIM or System Information Block which contains more details about the E-node B such as the cell ID, the MCC, MNC and TEC which are the mobile country code, the mobile network code and the tracking area code respectively. So finally, I'm going to use the terms MCCATCHER, Stingray, Hailstorm, fake base station and cell site simulator, all kind of interchangeably. These don't mean exactly the same thing. A cell site simulator and a fake base station are fake cell towers. A Stingray and a Hailstorm are two brands of cell site simulator and MCCATCHER is sort of a common term for one of the things that cell site simulators do, although not all MCCATCHERs are cell sites. They fully emulate a cell site. Some MCCATCHERs can run passively and not actually transmit anything thus not emulating a cell site. But for our purposes, we're going to use them interchangeably and that's okay for the purposes of this talk. So here we have a diagram of the 4G network. This is a pretty high level diagram, but you can see here that the user equipment, the phone connects to the E-node B using the LCEU protocol. Through the uplink, the E-node Bs can talk to each other through another vertical. And the E-node Bs exist in a network called the EUTRAN. And then you have a network called the Enhanced Packet Core, which is behind the E-node Bs and this contains the MME or Mobility Management Engine, Serving Gateway and PDN Gateway which connect to the public data network which connect to the back to the phone network. And the EPC is also responsible for authenticating user billing, et cetera. We're not going to focus on the EPC today. There are issues there that we could talk about, but it's out of scope for this talk. We're specifically going to focus specifically on the communication between the user equipment and the E-node B and sort of the area inside of this red circle. So we started this project because we already knew a lot about the Stingray. Some law enforcement agencies had had the Stingray. The Stingray had been around for a while and it was pretty well understood how it worked. Kristen Padgett did a really great talk at DEF CON several years ago where she demonstrated building her own homemade Stingray and has pretty well understood the vulnerabilities. But what we were noticing was that law enforcement was starting to upgrade their cell-side simulator devices to newer devices such as the HailStorm, which purported to be able to operate natively in 4G. And we started wondering, well, we have a pretty good idea of how the Stingray works, but we have no idea of how the HailStorm and these newer devices operating in 4G, how they might work. So let's dig into this and let's start by figuring out how they could possibly work. And the first thing we want to look at is what changed between 2G and 4G? And there are three significant changes that affect the way that a cell-side simulator might work. The first and most important is that the E-NodeB and the UE in 4G mutually authenticate each other. In 2G, the user equipment or the phone had to authenticate itself to the E-NodeB or the base station. But the base station never had to prove that it was a real base station. And this was the source of a lot of fake base station attacks such as the ones that the Stingray used in 2G. And with 4G, this is no longer a problem. Also, in 2G, you had terrible encryption. The base station would dictate to the user equipment what cypher to use and it can even dictate that the user equipment use a mill cypher. What's more, the cyphers that were used by 2G were actually quite weak and could be broken in real time or near real time by anybody recording the packets between the base station and the phone without even having to transmit anything. This is no longer the case in 4G. Now that E-NodeB and UE mutually agree on what encryption to use and the cyphers are much, much better. Also in 2G, the phone would always just connect to the strongest tower that it could see. And 2G could even, in 2G, you could even dictate how strong your signal was telling the phone to ignore the actual signal strength and just trust what you were saying the signal strength was. Neither of these are the case in order to 4G. The phone no longer negatively connects to the strongest tower. Instead, there are a set of cell selection criteria that it follows. So great, we've solved all the problems, right? Well, clearly not because there are still cell-side simulators that are operating natively in 4G. So me and Yamna set to work reading all of the academic literature that we could about vulnerabilities in 4G and what could possibly be making cell-sites and next-generation cell-sites and whether it's work. And after several months of reading, over a year of reading really, Yamna wrote a really amazing paper called Gotta Catch Him All which summarizes all of our findings, everything that we learned about what vulnerabilities next-gen CSS's might be taking advantage of. And we really figured out that there's one specific area where 4G is extremely vulnerable. So 4G has a bit of a glass jaw. Even though the UE authenticates with the tower, or authenticates the tower now, there are still several messages that get sent and received and trusted before that authentication ever happens or without authentication ever happening in the first place. And this is the weak spot in which the vast majority of 4G attacks happen. I'm not going to get into those attacks here today because Yamna has already done a really excellent job of summarizing those in that paper and I highly suggest that you've got read it. It's an excellent paper. But to give a high-level summary, this is the handshake protocol between the user equipment, the phone again, and the base station. And it starts with the user equipment looking on each ERCIN or frequency for a frame synchronization signal from a base station. Once it finds synchronization signals, it is able to find the MIB, master information block, and decode that, which lets it find the SID and decode that, which gives it enough information about the mobile country code, the mobile network code to decide whether it wants to connect and then send an RRC radio resource control, RRC connection request. It does that handshake and then it begins the attach request. And here in step 7 is where the authentication finally starts. All of the messages before that are never authenticated and some of the messages that get sent in that area can contain things like the IMSI of the phone, allowing you to uniquely identify it. It can contain even the GPS coordinates of allowing you to locate it and a bunch of other things, attacks that allow you to downgrade it to 2G or allow you to kick it off the mobile network entirely. So this is where the heart of all of the vulnerabilities lie at 4G and this is the part that we find really interesting. So now that we had a pretty good handle on how 4G cell sensors are probably being used. We wanted to get an idea of how often they're being used. And if we want to learn how often they're being used by U.S. law enforcement the best way to do this is to file FOIA requests. ACLU filed a really excellent FOIA request which came back which just got published this year in 2020 about an ICE and DHS's use of cell-site signalers and in it they discovered that ICE or U.S. Immigration and Customs Enforcement used cell-site signalers between 2017 and 2019 a total of 466 times hundreds of times per year. DHS on the other hand used their cell-site signaler 1,885 times between 2013 and 2017. We also found out that Customs and Border Patrol or CVP owns 33 cell-site signalers which is a ton and we don't know how often they're being used but we can assume that it's probably on par with ICE and DHS. Oakland on the other hand the Oakland PD, Oakland's local police department in California they used their cell-site signaler which is a hail storm three times in 2017. In 2018 it was used four times and in 2019 it was used only once. But on the other hand Santa Barbara PD the local police department for Santa Barbara, California used their cell-site signaler 231 times in 2017 roughly matching up with the numbers from ICE and DHS. So what makes Oakland so much different in this case? Well, we think that it's because Oakland has stronger privacy laws. Oakland has pretty strong regulations about when and where the cell-site signaler can be used how it can be used and what sort of reporting, public reporting needs to happen afterwards and we think that that has really kept Oakland PD on a leash as far as their use of cell-site simulators is concerned. So we encourage other communities to come up with similar rules and regulations about how these can be used. But of course not everybody using a cell-site simulator is going to follow rules and regulations nor can they be foiled. We have pretty good evidence that foreign spies are using cell-site simulators. The Department of Homeland Security put out a report last year where they demonstrated that they found several cell-site signalers around the White House and around Washington, D.C. which almost certainly belong to foreign spies trying to spy on the political class in Washington, D.C. We also have reason to believe that cyber mercenaries such as NSO Group have access to cell-site simulators. A report from Amnesty International that was put out this year in 2020 detailed a campaign against a Moroccan journalist to spy on a Moroccan journalist by NSO Group where they also use cell-site simulators to intercept his calls. And finally, we think that just straight up criminals have access to these. There's rumors that drug cartels have access to a cell-site simulator and it makes sense. Cell-site simulators are pretty easy and pretty cheap to build at this point. And if you don't want to build one, you can acquire them from companies in Israel, companies in Saudi Arabia. They're really pretty ubiquitous and pretty easy to acquire. And of course, these people can't be foiled. We can't ask them how often they're being used. So we have no idea how often these groups are using these. So that being the case, our next step is we start to think about, okay, how can we detect cell-site simulators? And there are two schools of thought for how to detect cell-site simulators. One is app-based and this is applications like AIM-60 or Android MCCapture Detector, Snoop Snitch or Darshark. The strengths of these are that they're cheap. It's an app. You install it on your Android phone and they're easy to use. You start the app, you let it run. It lets you know what, if it finds something that's suspicious. All you need is an Android phone and it might need to be rooted. It might need to be a specific type of phone, but you don't really, as long as you have that phone already, you don't have to spend any further money. The weaknesses of these are that you're going to get very limited data. AIM-60 only gives you, if on an unrooted phone at least, only gives you the MCC, MNC, and the location area good. And some information about the signal strength. Snoop Snitch and Darshark get more info because they're able to rebase band messages on the phones that they support, but it's still you're only getting the info about cells that your phone is connected to. And you're getting a lot of information about weird things happening, but a lot of those end up being false positives because many of the things that could be indicators of cell-side simulators are also just weird, these sorts of weird things that happen in the cell network quite often. And because of that, it's you get a lot of false positives and it's hard to tell what is actually a cell-side simulator and what is maybe just the cell network being a cell network. The other school of thought is radio-based and this is basically things where you have a software-defined radio or a cellular modem and you're getting information about all of the towers around you and you're putting that in a database and running some heuristics to determine what's suspicious. Projects that are examples of this are Sea Glass from the University of Washington, Sitch from Ash Wilson, and Overwatch, which is a commercial product. The strengths of these are that you can get better data. You can get data from all of the towers in an area, not just the ones that you're connecting to. You can also get lower-level information. You can get as low-level information as you want based on what you can program with your radio, right? The weaknesses of these are that they're harder to set up. They can be harder to use and interpret because you maybe have to run Linux and set up a server and you have to put together some hardware and maybe even have to know a little bit of programming. Also, the weaknesses that you have to buy that hardware and hardware can be expensive. You might have to spend a couple of hundred dollars to get running, whereas the app is free. So there are strengths and weaknesses to both of these, but armed with this knowledge, we started hearing rumors about cell-site simulators being used at the Standing Rock protest or at the Dakota Access Pipeline protest in Standing Rock, North Dakota. And given that we had some ideas about how maybe one could detect cell-site simulators and we wanted to know if they were being used at protests, we decided to go down to Standing Rock and see what we could find. So I armed my phone with Snoop Snitch and AIM-60 and I brought along a couple of RTL-SDRs which I figured I could do some spectrum analysis with and made my way down to Standing Rock. And what I figured out was that I had no idea what I was doing. And by the way, this dog is... I don't know, our patronus is canceled now. If not, this dog is my patronus. I very much identified with this dog. But we had no idea what we were doing. When we got there, what we realized was there were no 2G towers anywhere to be found. And whether they be legitimate or illegitimate and all of our detection methods were focused on detecting 2G towers. If a 2G cell had shimmed up all of a sudden that would have been a pretty strong indicator but we weren't able to find any evidence of 2G cells while we were at Standing Rock. And the conclusion that we came to is that if cell-site simulators were being used at Standing Rock they must be next-generation cell-site simulators that were operating natively on 4G. Which leaves us with the question how can we detect 4G-based cell-site simulators? And how can we improve on previous attempts to detect cell-site simulators? Well, first off, I think that the radio-based method is solid. C-Glass had already put up some pretty interesting results. And the idea of getting information about all of the cells in an area, everything that's broadcasting not just the ones that your phone is connecting to and comparing that data over time I think are really interesting. So let's add on top of that looking specifically at 4G transmissions having heuristics based on what we've learned from Yamda and mine and Yamda's research. And let's verify the results. When we find a suspicious tower, let's go track it down and see what it actually is. Is it on top of the cell tower? Yeah, great. It's probably fine. Is it on top of a building? Yeah, that's fine. It's probably a small cell. Is that building an embassy? Well, that's a lot more suspicious. And finally, is it in an unmarked van or in a van surrounded by police officers? Well, that's very suspicious. So without further ado, I introduce to you Crocodile Hunter. Crocodile Hunter is an open-source project that we've been working on at EFF for the last couple of years and are releasing here at Virtual Black Hat and DefCon this week. Crocodile Hunter is a hardware and software-based. It uses an SDR and the software. The backend is based on SRS-LTE, which is an open-source LTE software stack that's able to emulate both the Enhanced Packet Core, the E-Node B, and also the user equipment, which we use to measure the cell network in the area. It's written in C++ and we wrote a program in the SRS-LTE API to scan the cell network for us. The front end, which it communicates with a real local socket, is written in Python 3. The front end is responsible for getting data from the socket from SRS-LTE, adding it to the database, running heuristics, and displaying tower locations. And we also have an API so that if you want to gather data from multiple sensors or if you want to share data between multiple researchers, you can. Here's an example of what the user interface looks like. This is from a scan that me and my colleague Dave Moss did in downtown San Francisco during the Dreamforce Conference last year. Each of these points on this map is, we think, the probable location of a cell in downtown San Francisco on that day. The orange points are cells that we didn't find to be suspicious and the black skulls are cells that we did think were suspicious. And I should note here that certainly there's no way that each of these black skulls is a cell-side simulator. In fact, probably none of them are cell-side simulators, but we think they're suspicious and require further checking. And I'll go into more depth about that later. On the hardware side, the hardware stack is a laptop or a Raspberry Pi running Ubuntu. And you need a battery for the Pi if you want it to be mobile, a USB GPS dongle, and an SDR with some LTE antennas. For the SDRs, we've tested it with a BladeRF and an Edis B200. It should support all models of Edis and BladeRF. It also, theoretically, could support a LIME SDR, which is significantly cheaper. I think the BladeRF will run you about $500, whereas a LIME SDR will run you about $250. But we have not tested it with that. But that is on the roadmap because we would like for this hardware stack to be cheaper. Here's what the hardware looks like sitting on my kitchen counter. As you can see, it's actually pretty compact and you can easily put it into a backpack or load it into your car and go for a drive around your city. And it's pretty, and you can do it pretty discreetly. So the general workflow is we start by scanning all of the frequencies that we know about and decoding them, each may have been saved that we find. We record those into a database. We map the probable location of those cells. We look for any anomalies in the readings and then we locate suspicious cells and confirm the results. And I'll go into each one of those in more depth. So we start by scanning the list of ERSINs, again, frequencies. We start by scanning the list of ERSINs that we get from an open source database called Wiggle. Wiggle is an open source database of war-driving readings of Wi-Fi networks and also of cell networks. So we get all of the ERSINs for the given geographical region we are in. And then we scan each of those. And our theory behind this is that we think that a cell site simulator is going to have to operate on the same frequencies that real cells are so that phones will be more inclined to connect to them. So we scan each of these frequencies. And if we find a Mib, we decode the Mib and the Sib and we send it to the front end over our socket. The front end stores the information in a database and it stores in that database the mobile country code, the network code, the tracking area code, the cell ID, physical ID and ERSIN, the latitude and longitude of where the reading was made, the timestamp, the signal strength, the E-node BID, the sector ID and a few other IDs. And finally, the raw data from the Sib 1. And then the next step is that we try to map out the antennas in real time. And we map them out using a process called trilateration, which is a process where we have distance estimates that we're able to get from accommodation of the frequency of the transmission and the signal strength. We can estimate the distance and then with multiple readings figure out where the towers are. And then we can compare this to a ground truth, such as wiggle or open cell ID or the FCC database to see if other people have seen a cell with those identifiers in that area historically. A quick explanation of trilateration versus triangulation. So trilateration is where you have a measurement of the distance away from a transmitter that you are but not what direction the transmitter is in. So you draw a circle around the point where you're at and somewhere on the edge of that circle is where the transmitter is going to be. Once you've made three measurements, you can draw three circles and the place where those three circles intersect is the place where the transmitter is going to be located. Triangulation on the other hand is where you have a bearing that is to say a direction of the signal, but you don't know how far away the signal is. With triangulation, you get two readings with a bearing, with a direction. And then you can make a triangle with one line between the two readings and the other two sides being the direction of the readings. And where those two directions intersect is where the location of the tower will be. So triangulation is good if you have direction but not distance. And trilateration is good if you have distance but not direction. For trilateration, you only need one omnidirectional antenna. But for triangulation, you either need three omnidirectional antennas with all of their clocks synced so that you can actually measure the angle that the signal is coming from or you need a directional antenna that's constantly spinning so that you can figure out which direction it points has the strongest signal and thus figure out the bearing. Given that we figured most people running this would only have one omnidirectional antenna and not a spinning antenna with three clock synced antennas and thus three clock synced radios, we figured that trilateration was our best bet. So finally, we look for anomalies. And what are we looking for in terms of anomalies? We're, well, looking for things like cells that move over time, cells where the signal strength changes, cells that aren't where they should be. In other words, cells that are here and also across the city, cells that change parameters. Suddenly, this E-node BID is broadcasting a different country code or a different network code or a different, or suddenly it's broadcasting a different bandwidth or something like that. We're also looking for cells that are missing some of the more obscure parameters in the SID or higher SIDs. And we're looking for new cells that are showing up. And again, it's important to mention here that just because we find an anomaly doesn't mean we've found a cell-side simulator. We actually need to go verify it. If you know anything about 4G attacks and know how they work, you might be thinking at this point, but there's a lot of heuristics that you could have if you could actually connect to the tower. And that is true. There are a lot of really cool heuristics that we could get if we could connect to a cell. We could see if we got a reject message or we could see if it accepted us. Either one of those might be interesting. We could see if it was missing some of the higher level or more esoteric parts of the LTE stack. Or we could... There's all sorts of things we can measure. We could see how many paging messages sending out or how many other UEs are connected to the cell. But all of those would require connecting to the cell. And connecting to the cell requires transmitting. We thought it'd be a great idea until the EFF lawyers pointed out that that's illegal. Because we're using a software-defined radio, it's not actually licensed to communicate on the cell or to transmit on these cellular bandwidths. Whereas your cellular modem in your phone is licensed to transmit on those bands. So we can't transmit on those bandwidths without violating... On those bands, on those frequencies without violating the law. And we don't want to go to jail. So we decided not to transmit. But despite that, we still got some results. So what we've found so far... Our first test was at the Dreamforce conference, which I mentioned previously with my colleague Dave Moss. Me and Dave spent all day running around downtown San Francisco. And for those of you who aren't familiar with Dreamforce, lucky you. Dreamforce takes over all of downtown San Francisco. And there's sales people running around everywhere. We wandered around the main park where Dreamforce was happening. And we noticed this little cluster of suspicious cells here on the park near the... Where the event was taking place. So we started walking down Third Street and getting to the point where we thought the suspicious cells were. And we were thinking, hey, yeah, I think it's probably right about here. And we looked up and saw this giant black truck with a satellite dish on top of it. The satellite dish was pointing at a building about a block away that had a couple of cell antennas on top of it that we had noted previously. After looking at the truck, looking up the company that was listed on the side of the truck and talking to the guys in the truck, we determined that this is in fact a cell on wheels and not a cell side simulator. A cell on wheels is a portable cell tower that people bring out, companies bring out to expand the cellular capacity in a given area, usually for large events. In fact, there was even one at Staten Rock. We don't think that this was a cell side simulator. And in fact, cells on wheels are pretty common. But they have some interesting similarities to cell side simulators in... Namely, in that they are a portable cell that shows up that isn't usually there, is suddenly there and then leaves. And that they are... And that they are acting like legitimate cells. The main differences are that they're not actually trying to exploit any of the characteristics of the 4G network and the people operating them are probably not using them to spy on it. But we still think that this is a successful test. We were able to use our heuristics to find a new cell that had just showed up. And we were able to use our map to actually track that down and see what it was. If we had just been using an app, maybe that app would have called this out. Maybe it wouldn't have. And even if it had called it out, we wouldn't have known what to go look for or what it might have been. So we considered this a success. Earlier this year, we did a second test at Shmucon in Washington, D.C. So I loaded up Crocodile Hunter on a Raspberry Pi running around Shmucon with it in my backpack for the entire time. And what we discovered at Shmucon was two really interesting sets of two different EnoBs that would occasionally broadcast instead of the country code of a network code of 310410, which maps to USA and AT&T, would broadcast a completely different country code and a completely different network code. Looking into it further, the first one was broadcasting on the same ERC as what we think is the legitimate tower, but would broadcast a different MCC and an ANC of 350 and 490. 350 is the country code for Bermuda. And the MNC 490 is not used by any network in Bermuda. In the US, it's used by Sprint and T-Mobile. But again, this is an AT&T network. It was also broadcasting the same physical ID but a different sector ID and a different tracking area code. So we find this really interesting. In another instance, there was another EnoB broadcasting on the same ERC as what we think is a legitimate EnoB. This time broadcasting a country code of 308 for St. Pierre and Michelvin, which if you need a point of reference, these are a couple of small islands off the coast of Nova Scotia. I was also not aware of them until I looked them up for this talk. And the network code 451 is not used by any network for anything ever, anywhere in the world. This network was also broadcasting the same physical ID and in this case would broadcasting the same sector ID as a legitimate tower and the same tracking area code as the legitimate tower. So these weren't really interesting. Unfortunately, I, as I said, was running around with the crocodile hunter in my backpack and didn't notice these results until after the fact. So I didn't get a chance to go track them down. So hopefully in the future, we'll find something like this and actually get to go physically. We do have ongoing tests though. Our partners in Latin America with the fake antenna detection project have previously run around Mexico City and other places with sea glass and have gotten some really interesting results there and are planning next to run around there with crocodile hunter and see what they can find. And I'm really excited for what they will find. We also have partners running crocodile hunter in Washington DC and in New York City. And we hope now that the project is open source that you'll want to run this in your hometown as well. In the future, we hope to get better heuristics for crocodile hunter. Some of the heuristics I have right now aren't great and I think that there are other ones that we could do. We have a lot of ideas. We also can improve these once we get a better sense of how in sea catchers and cell sites and others are operating in the wild. Speaking of heuristics, once we get a lot of readings, we think that we can start to do some machine learning to build a classifier for what towers are behaving normally and giving normal characteristics and what towers are suspicious. Maybe in ways that a human wouldn't notice. I also want to get better location finding. Right now, my location finding can sometimes be about 50 meters off and that's not great. It's still pretty close and I'm okay with it. I think it's good enough. But I would like to get it much better and that means we need better distance estimates which is beyond my math and physics knowledge, unfortunately. The other thing we need is we want to port it to cheaper hardware. Like I said, the Blade RF will ring about 500 bucks. We think that it can work on the LIME SDR which is cheaper at 250. I would love, my dream is that it would work on the RTL SDR which costs like $20 but I'm not convinced that the RTL SDR and Raspberry Pi are actually powerful enough or have the bandwidth to do what we need them to do. So that's still up in the air. Finally, what's with the name? Well, you may remember that one of the brand names for a cell-side simulator is the Stingray. You may also remember that the Stingray is the animal that finally killed Steve Irwin, the crocodile hunter. So we named it crocodile hunter to press F for Steve. Finally, what can we do to stop cell-side simulators? Well, we can start by having a toggle on iOS and Android to turn off 2G support. One of the main attacks for native 4G cell-side simulators is to use that pre-authentication area to downgrade your connection to 2G and once your phone is downgraded to a 2G connection, they can do things like inspect content or do passive attacks to decrypt the messages between you and the cell tower or they can emulate a 2G base station. So your phone still supports 2G and the reason for that, there's a good reason for that. It's because many people in the world still use 2G cells as their primary form of communication and lots of 2G networks are still up. So iOS and Android can't just decycle 2G by default but what they could do is build in a toggle for users who are concerned about this to be able to turn off their 2G radios if they wish and we've written a blog post that encourages them to do so. The main thing we need to fix though is these pre-authentication messages. All of the messages that happen after your phone connects to the tower but before the authentication starts and that's a problem not in 4G but not just in 4G but in 5G as well. There is a pretty interesting proposal for covering the all of the messages or authenticating all of the messages between the tower and the user equipment with TLS. There's a pretty good paper about this and it will be linked here in the notes for this presentation that proposes a way and it's still in its infancy and it's going to take some more work but we really think that long term that's the solution but that's going to have to be implemented by a standards body such as the 3GPP and the 3GPP is the standards body that makes all of the standards for cell members. It's also going to have to be implemented by carriers, manufacturers and OEMs and we need more incentives for the standards or the carriers and the OEMs to care about user privacy. Right now it often feels as the user privacy is an afterthought and connectivity is really the most important the primary goal of these organizations and we need to change that. The 3GPP costs several tens of thousands of dollars to get a seat on and as such there are no representations from civil society, from privacy organizations or non-profits and that needs to change. None of these solutions are going to be foolproof of course and our detection and I'm correct my 100% proof but we're not even doing the bare minimum yet and I think that we should be doing at least that. So what do I want you to take away from this? Well, we have a pretty good understanding of the vulnerabilities in 4G which commercial cell-side simulators might exploit and if you want to read more about those I really highly suggest you read Yama's paper got to catch them all. None of the previous MC catcher detector apps really do the job anymore. Stylas could certainly still detect older MC catchers but none of them are able to detect newer MC catchers but we've come up with a method similar to established methods but targeting 4G natively and we think that the worst problems of CSS abuse can be solved with a little bit of elbow grease and a lot of politics. Finally, thanks to the following people. Yamda of course I couldn't have done this project without her and she did so much amazing work. Thanks so much, Niyama. And please buy her a virtual beer or just challenge her to a Game of Dance Dance Revolution if you see her. Of course, thanks to the Holy FF crew and especially Threat Lab who have been a huge support through all of this. Huge thanks to Andy and Bob at Wiggle for a lot of programming help and a lot of forgiving me unfettered access to their API. Thanks to Roger Picchieros-Hover who is one of the smartest people in the world about cell network so he really knows the stuff and he gave a lot of advice and a lot of encouragement. Thanks to my test crew, Nima Fatemi with Candid and Surya Mathew and Simon from the Markup. Simon Faundry-Tiedler, thank you. Carlos with the Fade Project and everybody else involved in the Fade Project. Thanks for running Procter Hunter in South America. Carl Kosher and Peter Ney and others at the University of Washington who authored Sea Gloss as well as giving me tons of advice, tons of support coming out to Standing Rock with me, really fantastic people. And of course, thanks to Ash Wilson, the author of Sidge and Eric Escobar, Defconn Justice Beaver who also gave me a lot of inspiration and advice. And last but not least, thanks to Chris and Padgett for doing all the original research on cell-sized simulators and really paving the way for hackers to start looking at these. And also, thanks for the Nokia phones, Kristen. And finally, thank you for coming to the top.