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 non-profit.
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 Yamna. 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 safe mode, please buy her a virtual beer, or follow her on
Twitter. Her name is at RivalElf, 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 antivirus companies are doing a good job of what they do, they mostly
care about the types 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 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 in the communities that we work 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. It 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 eNodeB, or the base station, this is what the UE, or 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 EARFCN, or E-A-R-F-C-N, this is
the frequency that the UE and eNodeB are communicating on. The sector is a specific
antenna that is attached to the base station or eNodeB, and eNodeB 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 eNodeB and tells phones where to find the
SIB, or system information block, which contains more details about the eNodeB, such as the cell
ID, the MCC, MNC, and TAC, 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 that 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 eNodeB using the LTVU protocol. Through the uplink,
the eNodeBs can talk to each other through another protocol, and the eNodeBs exist in
the network called the EUTRAN. And then you have a network called the Enhanced Packet Core,
which is behind the eNodeBs, and this contains the MME, or Mobility Management Engine,
serving gateway, and the PDN gateway, which connect to the public data network,
which connect back to the phone network, and the EPC is also responsible for authenticating
user billing, etc. 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 instead going to focus specifically
on the communication between the user equipment and the eNodeB, and that is 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 Paget did a really great talk at DEF CON several years ago, where she demonstrated
building her own homemade Stingray, and it's pretty well understood the vulnerabilities.
But what we were noticing was that law enforcement was starting to upgrade
their cell-site 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-site simulator might work. The first, and most important, is that the
eNodeB and the UE in 4G mutually authenticate each other.
In 2G, the user equipment or the phone had to authenticate itself to the eNodeB 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. 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 cipher to use, and it could
even dictate that the user equipment use a null cipher. What's more, the ciphers 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 eNodeB and UE mutually agree on what
encryption to use, and the ciphers are much, much better. Also, in 2G, the phone would always just
connect to the strongest tower that it could see, and 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 anymore in 4G. The phone no
longer naively 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 site 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 simulators work.
And after several months of reading, over a year of reading really, Yamna wrote a really
amazing paper called Gotta Catch Em All, which summarizes all of our findings, everything that
we learned, about what vulnerabilities next gen CSSs 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, 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 go 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 ERF SIN, 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 SIN 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 the phone, allowing you to locate it,
and a bunch of other things. Attacks that allow you to downgrade it to TeamG,
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-site simulators 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 ICE and DHS's use of cell-site
simulators. And in it, they discovered that ICE, or U.S. Immigration and Customs Enforcement,
used cell-site simulators between 2017 and 2019 a total of 466 times, hundreds of times per year.
DHS, on the other hand, used their cell-site simulator 1,885 times between 2013 and 2017.
We also found out that Customs and Border Patrol, or CBP, owns 33 cell-site simulators,
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 simulator, which is a hailstorm, 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
simulator 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 simulator 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 FOIAed. 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 simulators 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 FOIA. 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 Aim60 or Android MCCatcher 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 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. Aim60 only gives
you, on an unrooted phone at least, only gives you the MCC, MNC, and the location and the location
area. And some information about the signal strength. Snoop Snitch and Darshark get more
info because they're able to read baseband messages on the phones that they support,
but 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-site simulators
are also just weird, these sorts of weird things that happen in the cell network quite often.
And because of that, you get a lot of false positives, and it's hard to tell
what is actually a cell-site simulator and what is maybe just the cell network being the 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 Seaglass from the University of Washington,
Sitch from Ashwilson, 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
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
AimSickD, 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 identify 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, whether they be legitimate or illegitimate. And all of our
detection methods were focused on detecting 2G towers. If a 2G cell had shown 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. SeaGlass 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's 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
mine and Yamna'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 a 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 DEF CON 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 eNodeB, 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 frontend, which it communicates with over a local socket, is written in Python 3.
The frontend 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,
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 site simulator. In fact, probably none of them are cell site 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
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 each MIB and SIB 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 a list of ERFsens, again, frequencies. We start by scanning a list of ERFsens
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 ERFsens 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,
physical ID and ERFsens, 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 SIB1. 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 a combination 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 with 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,
direction but not distance, and trilateration is good if you have distance but not direction.
For trilateration, you only need one omni-directional antenna. But for triangulation,
you either need three omni-directional 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 omni-directional antenna
and not a spinning antenna or 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 node BID is broadcasting
a different country code or a different network code 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-site simulator. We actually need to go verify it.
So 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 there's all sorts of things we could measure. We could see
how many paging messages it's 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
to transmit on the 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're thinking, hey, yeah, I think it's probably right
about here. When 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 Stading 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.
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 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 you.
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 ShmooCon in Washington, D.C.
So, I loaded up Crocodile Hunter on a Raspberry Pi running around ShmooCon with it in my
backpack for the entire time. And what we discovered at ShmooCon was two really interesting sets of two
different ENOBs that would occasionally broadcast, instead of the country code and 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 ERCIN as what we think is the legitimate tower, but would broadcast a different
MCC and MNC 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 U.S., 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 ERCIN as what we think is a legitimate ENOB,
this time broadcasting a country code of 308 for St. Pierre and Miquelon, 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 was broadcasting the same sector ID as the
legitimate tower and the same tracking area code as the legitimate tower. So these were 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 look at them. We do have ongoing tests, though. Our partners in Latin America with
the Fake Intended Detection Project have previously run around Mexico City and other places
with SeaGlass 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, D.C.
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 ABC catchers and cell site simulators 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. And the other thing we
need is we want to port it to cheaper hardware. Like I said, the Blade RF will ring you about
$500. We think that it can work on the Lime SDR, which is cheaper at $250. My dream is that it
would work on the RTL SDR, which would cost 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. And finally, what's with the name? Well, you may remember
that one of the brand names for a cell-site simulator is the StingRam. You may also
remember that the StingRam 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-site 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-site
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 disable 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's a pretty interesting proposal for covering 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'll 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
networks. It's also going to have to be implemented by carriers, manufacturers, and OEMs, and we need
more incentives for the standards, or as the carriers and the OEMs, to care about user privacy.
Right now, it often feels as though 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, from non-profits, and that needs to
change. None of these solutions are going to be tool-proof, of course, and our detection, and
Carcine Hunter is tool-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 site simulators might
exploit. And if you want to read more about those, I really highly suggest you read Yama's paper,
Gotta Catch Em All. None of the previous MCCatcher detector apps really do the job anymore.
CGLASS could certainly still detect older MCCatchers, but none of them are able to detect
newer MCCatchers. 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. Yamna, of course. I couldn't
have done this project without her, and she did so much amazing work. Thanks so much to Yamna,
and please buy her a virtual beer, or just challenge her to a game of Dance Dance Revolution
if you see her. And of course, thanks to the whole EFF 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... for giving me unfettered access to their API. Thanks to Roger
Piqueros-Jover, who is one of the smartest people in the world about cell networks. He really knows
his stuff, and he gave a lot of advice and a lot of encouragement. Thanks to my test crew, Neema
Fatemi with CanDo, and Surya, Matthew, and Simon from the Markup. Simon Fondry-Tiedler, thank you.
Carlos with the Fade Project, and everybody else involved in the Fade Project, thanks for
running Practical Hunter in South America. Carl Kosher and Peter Ney and others at the University
of Washington, who authored Seagloss, 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 Siege, and Eric Escobar, Defcon Justice Beaver, who also gave me a lot
of inspiration and advice. And last but not least, thanks to Kristen Padgett for doing all the
research on suicide simulators and really paving the way for hackers to start looking at these.
And also, thanks for the Geophones, Kristen. And finally, thank you for coming to the talk.