Thanks for coming out. I'm Ash Mastaflash, and today we're going to cover inexpensive coordinated GSM anomaly detection.
More specifically what that means by inexpensive, the whole goal of the project was to come up with something that was going to be far less expensive than the production of a malicious device.
Coordinated, meaning centrally configured, you don't want to have to pull SD cards on a whole bunch of remote sensors and then reconfigure them, reburn them, and get them back out into the field.
So central configuration and software management was really important.
And by anomaly detection, specifically what we mean is picking up rogue BTSs and IMSI catchers.
So let's jump in.
A little about me. I started with actually getting paid for technology work around 2000.
And I hopped disciplines every few years, kind of changed focus, and now I'm working in R&D for a cloud workload security company.
And I'm working in R&D for a cloud workload security company.
And I don't like talking about me, so that's where we want to end that.
Let's talk about you.
The audience I was writing this for has a background in systems and network engineering, some interest in GSM threat detection, but probably not a huge depth.
I mean, if you've got it, then great, but it's not required.
I'll give you the crib notes so we can make it through.
And tinfoil hat's certainly not required, but it's not unwelcome.
So go ahead and put it on now, and let's party.
So I said that I'm working R&D now.
I really love my job.
And as such, this has nothing to do with my day job.
So if you don't like this, if you do something with this and get in trouble, I completely disavow whatever it is that you do with this.
So, yeah, and don't go talking to my boss about this.
Just come talk to me if you don't like it.
So here's what we're going to cover.
First off, why you should care.
The current threat and detection landscape.
The original project goals.
Two iterations of the sensor and the service architecture, because it's kind of a split architecture.
Set up future plans for the project, and that's where I kind of beg you for your help and full requests.
Nod and a hat tip to prior art and Q&A.
Why should you care?
Because invasions of privacy are bad even when they're unnoticed.
Yeah, that's true, and this all is kind of vague.
So specifically, what are we looking at?
What's the worst that could happen with a compromised cell phone conversation in your CFO's office?
It could have a financial impact on your company.
In the right CFO's office, you could even be looking at something like insider trading or market manipulation with the right phone conversation.
So these devices are so small and so easy to hide and so inexpensive, you know, can you really trust your ficus?
Adjust your tinfoil hat.
And the second side of this is it's with an IMSI.
You can also determine whether or not a specific person is within a domicile.
So if with one of these devices, someone could walk up outside of your house and they could get a listing of all IMSI numbers.
Now, IMSI numbers are the ones that are burned into your SIM in your phone that's attached to your account.
So that identifies you as an individual.
If you can take a listing of those from everybody inside of a house process of deductive reasoning, you can determine who is home.
So it's a little bit spooky.
And and it's.
It's not that expensive to carry off the terminology baseline for the talk software to find radio.
I had one of those in my pocket, but I gave it away.
The it's using software to perform your signal analysis and using a typically a USB dongle that has a software controlled tuner.
And in the case of this, we're using the RTL SDR devices, the super, super cheapo, like 20, 40 dollar units.
ARFCN, absolute radio frequency channel number.
I may just refer to that as channel number from here on out, given that this isn't a GSM in-depth talk, just because it's easier to kind of wrap your head around.
Think of this almost like a television channel.
CGI cell global ID is a globally unique identifier for the BTS that's comprised of a mobile country code, a mobile network code, a location area code and a cell ID.
All that comes from the BTS.
Like I said earlier, the IMSI is what's burned into your SIM, and that's what identifies you as an individual.
Here's a visual aid to kind of wrap your head around GSM addressing in regards to the global cell ID.
Every mobile country code has a number of subordinate mobile network codes.
Within that you have multiple location area codes, and within that you have multiple cell IDs.
So let's talk about threat and detection.
So we'll go over.
First a drink of water.
Malicious devices, how you know that these malicious devices are in play.
And what's currently on the market to detect them.
So a hacked Femtocell is a trusted part of the provider's network.
We saw some really good talks in DEF CON 21 about hacking Femtocells for the purpose of honest IDS.
And also for some nefarious purposes.
purposes. With a hacked Femtocell, you can gather IMSIs and you can also record phone
calls and SMS traffic that are going across it. Your phone has no idea if it's good or
evil. Your phone is just going to attempt to attach to it. And EvilBTS, EvilSocket had
a great blog post on how to build one for very, very cheap. And HamHands4Scale, this
is the size of the SDR that's necessary to build a, you can kind of see how this could
fit in your ficus, right? So, and that's the largest device in the system. So that, coupled
with a Raspberry Pi 3, you can build an EvilBTS and record phone and SMS traffic. Again, this
is the same case with the Femtocell. Your phone doesn't know if it's good or evil, it's
just going to try and talk to it. That's a GSM thing.
So, indicators of attack. How do you know when something weird is going on? ARFCN, remember,
think of it like a TV channel. All of a sudden if a channel goes loud over threshold, this
is something you determine by a short period of observation. So you can set a threshold
alert when it gets over that. ARFs and outside of forecast, you can use, spoiler alert,
we're using Graphite as part of this. Graphite has, has whole Winters algorithm built in,
so that you can have a confidence band over time and so if something that's typically low
but all of a sudden gets a little bit louder it may not be a threat to you but it may be
something nearby a channel all of a sudden getting louder may indicate that someone's trying to
broadcast on the same channel unrecognized cell global id
there are databases you can download with the gps coordinates and all the all the metadata
data for these cell global ids and it's useful for determining your location if you don't have
a gps chip you can kind of make that determination based on where the tower is um gratuitous bts
reassociation this is something that you would determine by observing the behavior of a cell
radio and if all of a sudden you have a stationary radio that starts associating to another bts or
another a bunch of other bts's typically for us for a standard or a stationary radio you're not
going to see a lot of that behavior
if you're walking around it's supposed to happen like that with your cell phone but if it's sitting
in one place you really shouldn't be hopping towers a whole heck of a lot and if you have
the gps location of a tower by the cell global id and the bts is broadcasting a cell global id
of something that should be in say orlando if that cell shows up in vegas either someone's
absolutely awful at their job of configuring bts's or it may be something malicious
so
current detection methods both pony express and bastille networks have an offering of which this
is a subset open source options fake bts is a really cool project it served as the original
inspiration for this it's a it's a collection of shell scripts that use wireshark and airprobe
and calibrate to make a determination as to whether or not you have malicious nearby cells
the android imsi catcher detector is software that you install on your phone itself and it
interacts with your cell phone's radio to determine if there's any sort of anomalous behavior
and femto catcher is very close in function to i to the android imsi catcher detector but it's
specifically for catching femto cells and it's really only effective for phones on verizon
wireless network the original project goals um it's vegas i think it's okay to ask what you can
get for a hundred dollars so
um so that was the goal is see if i can get the target price under a hundred dollars for
the first iteration uh i wanted a low footprint for the raw materials i wanted it to be at least
as small as this and uh functional targets i wanted to be able to um pretty much use the
indicators of attack as a metric on whether or not i would be successful detecting rogue bts's
and centrally managed software and configuration that was really important to me
because i have really big hands and it is such a pain to actually get those micro sd cards
into the right slot in a raspberry pi and i've lost so many and gotten so frustrated having to
crack the case back open to get my yeah i didn't want to screw around with that i wanted to be able
to drop this thing under a desk up behind a ceiling tile pretty much wherever you might
find a malicious device i wanted to drop this thing so that you could get good local coverage
inexpensively and not have to touch it again
there's the person uh in the video in the background
um in the process of this i collected a lot of hardware
i had a raspberry pi 2 a logarithmic antenna a couple of o droids a c1 plus and xu4
a galaxy of red and blue and green and orange leds an intel nuc and intel edison a gsm modem a handful of rtl-sdr devices
i didn't really need all this stuff
stuff. But when you get locked into a serious hardware collection, the tendency is to push
it as far as you possibly can.
So that brings us to SICH, situational information from telemetry and correlated heuristics.
And I definitely started with the acronym side of that before I came up with the words
to match. So this is the first iteration of the sensor. I had an RTL-SDR device. I wrote
a wrapper in Python to get that into structured data using calibrate. And all of that feeds
into the main process. Also running GPSD to pull accurate GPS readings from a GPS dongle.
Using logs-4 to forward scan logs. Since we have it in structured format, it's pretty
easy to drop the file.
And logs-4 picks that up, shoots it off to logs-4, elastic search, all that good stuff
in the cloud. And I was using a tool, a Python tool called graphite send to send all this
stuff over an open VPN channel up to a graphite instance for tracking time series measurements.
Which was, it was effective enough. I talked Verizon into sending me a femtocell to set
up in my apartment. And when you start it up, I mean, they never really consistently
start at the same speed. Sometimes you'll be waiting for 40 minutes for it to get a
GPS fix. But when it does go live, it's pretty plain to see. Honestly, this graph is a little
bit smoothed out. It's normally spikier than this. I went back in history and graphite
and graphite had already kind of smoothed things out for me. But it's very clear, very
apparent when this stuff goes live. Because it gets very loud and your phone attaches
to it. And then, ta-da, you're on a part of Verizon's trusted network. So, remember
that slide earlier.
Here it is in table form. So, these are our functional targets. Arpsen over threshold
is a big yes as well as arpsen outside of forecast. But the tool that we're using called
calibrate, what it does is it produces a list of channels, nearby channels, and gives
you a power rating. It's typically used for picking up, for determining your clock offset
because SDR devices are notorious for being drifty. And the RTL SDR devices are especially
notorious depending on temperature. So, those are the, you actually can't get away with
running those things with the lids closed. They get way, way too hot. And the price was
$100. Like, it was right at about $100. Not counting the case. I mean, the case was kind
of necessary for the trip out here. But just the raw components you can get for about $100.
And it's pretty effective. The problem is you're looking at about seven minutes' worth of
resolution. So, it takes seven minutes to scan 850 megahertz GSM. You're looking at about
using a Raspberry Pi 2. And you can actually have kind of a pretty important conversation
in less than, you know, in less than seven minutes. So, good first iteration. I was thinking,
ah, I got, this actually happened after I submitted my CFP. I was able to kind of prove
what I was thinking. And so, this is like late April. And I was thinking, ah, I could
kind of roll with this. Just write on this. And maybe it would be fine and cool. And I
started looking at the source code. And I was really, really not happy with it.
It was pretty horrific. And that's just not me being self-conscious. There were a few
problems with this. So, what's wrong with Mark 1? Main was single-threaded. And when
you're pulling data from two separate devices, you can end up with some interesting situations
if you've got to wait on your GPS to get a fix. And then you do your seven-minute scan of
850 megahertz GSM. Then it's this sort of additive problem. It's, you can really end up
with some kind of ridiculous problems.
Yeah, so this is something that didn't like. Uh, this is incredibly long scan times.
Especially if you're indoors trying to get a GPS fix. Another thing I didn't like is that there
were two secure channels for delivering the information. That's, it's inefficient. It's just
more crap to manage. And I really kind of wanted to reduce those to, to one encrypted
channel. So, now I'm going to start the demo. And I'm going to start it early in the
presentation because it takes a, um, this stuff is kind of bandwidth dependent. So, I'll explain a
little bit more about that. Check this out. So, uh, the, the first thing is to get the search
All right, so this has got an RTL-SDR device, GSM radio, it's a Raspberry Pi 2, and just
some stuff to support that, so.
And this thing's being provisioned from zero using the orchestration stuff I was talking
about.
So while we're waiting on this thing...
Ah.
What it's doing is there's a, the service that I'm using to orchestrate what I'll loosely
call firmware, although maybe we'll have a discussion on the actually, what firmware
is later.
I'm going to call it firmware, it's just a bunch of Python code, but the, what actually
sits on the device, there's a service called Resin, and Resin has built an image to put
on your Raspberry Pi that runs Docker.
I think, I can't remember the version of Linux that's based on, I'm not going to promise
something up here.
But what it does is it dials home to the service, and it pulls Docker images of whatever
you commit.
So basically what you do, this is what your deployment pipeline looks for using Sitch
and Resin.
So what you have, your actual user effort is you do a git commit of your code, you do
a git push to Resin's repository, everything below the orange bar is all managed by Resin.
If your build completes...
And I'd like to mention...
I'd like to mention that if you do not do unit testing, you are going to hate your life.
You will pull your eyeballs out of your head, because it takes a few minutes, and it's
almost like, hey, here's Python, but now I have to compile it, and wait, and wait.
So get good at unit testing, and then make that part of your commit.
The commit hook will run a Docker build on your code, and if your build is successful,
it'll accept the commit, and moves the image into Resin's registry.
And then your device will, it pulls like every minute.
To the Resin service, and when you have a new container image, it just pulls out a new
container image, and restarts.
And you don't have to touch the thing to do software updates, which is really nice if
you're sticking these things up in attics and all over the place.
So as far as service side software goes, we've talked a lot about what's actually running
on the sensor, and what's running on the service side.
Most people in here, if you're a sysadmin, you're probably familiar with Logstash, Elasticsearch,
and Kibana.
It's a great, fantastic open source tool, and it's super versatile.
It's a part of this, as well as using carbon and graphite for time series database, and
for statistical calculation.
And I'm using Tessera, because as much as I love graphite, graphite's graphs are really
not pretty.
You need something to go on top of it.
And GraphiteBeacon is probably the simplest tool I found for just measuring and looking
for things outside of bounds on graphite.
It was so nice that somebody didn't over-engineer something.
It's simple.
You can figure it, set it up, and fire it off.
So that's what I chose.
Vault is a really cool tool from HashiCorp, and what it does, it does secret management.
So you can load certs, you can load credentials in there, and you use, and we have the keys
for accessing those loaded up into environment variables in the device itself.
So you can do your credential rotation against Vault.
And then you just bounce your whole application, you know, through the resin user interface,
and everything comes back up, gets its credentials, and all those credentials are written on the
sensor to a RAM disk, so that if somebody does jerk the power, it's at least a little
more difficult.
I know, you know, with physical contact, all of your security should be considered
null, but at least it makes it a little bit more difficult to uncover your crypto material.
Resin is the service that I use to manage the software.
And Slack is where the notifications come in.
You know, because at least you can do it over IP, and you're not relying on SMS when
GSM may or may not be, you know, a friendly area.
So on the service architecture side, the first thing the information hits is the inbound
information processor.
What that is in this case is Logstash.
Document retention.
Everything is stored in structured data in Elasticsearch, and the web-based portal is
kind of a combination of Kibana and Tessera.
The time series database is Graphite, and analysis and alert generation right now are
shared by Graphite.
I'm sorry.
That other tool.
Graphite Beacon.
And some stuff that's coming directly out of the sensor.
The sensor is actually smart enough to do some alerting on its own, and that stuff is caught
by Logstash, and it kicks it out straight to Slack.
Like I said, external alerting service is Slack, and there's the user.
So the intelligence feed, if you're going to make a determination on, you know, on the
location of all of these GSM towers, you don't want to do your own site survey and then compile
your own database.
You really kind of want to look and see if somebody else has already done that.
The open cell ID database is out there.
And it's super useful.
The only thing I think it didn't contain that I really wanted was the carrier name, because
you can make that determination using the MCC and MNC parts of the cell global ID.
So thank God for Twilio and their free pricing API, because you can just pull all of that
stuff down.
API key is free.
And the way that this works is it's all because once you start using Docker for something,
you just want to use it for everything.
And so I have this Docker container that I can
run as a job, and it goes out, it pulls down the open cell ID database, it merges that
with the information of the Twilio pricing API, and it throws this stuff out into files
based on MCC.
The reason that's sliced up is because that database file is so huge that you want to
have this kind of broken up, and knowing the country that you're operating in, you should
be able to determine the mobile country codes that you need to be downloading for.
So it reduces the download size, but truth in advertising is as much as I want this live
demo to work, it is a lot of information, and maybe or
maybe it won't be able to download everything in time.
If it doesn't, I've got a video, and I'm sure this, probably, wouldn't be the first
time a live demo fell over at DEF CON.
So, oh, if you insist.
So let's talk about the MARC2 sensor.
And...
the improvements I wanted to make before I showed anybody this ugly baby of mine.
So there's a component, the SIM808 collector.
That interacts with a GSM modem to actually function in some, in a way that's somewhat
similar to the way the Android IMSI catcher detector works by interacting with your phone's
GSM components.
So everything that you see in green is its own thread off of the main process.
So that way you can concurrently run collections against your GSM modem as well as your RTL
SDR device so that you don't have to wait seven minutes and then do it, you know, it's
just decided to forego all of that.
Everything that you see in blue is a first in, first out buffer.
So all of this scan information goes into the enrichment buffer and the enricher thread
picks it up.
Enricher thread compares that.
Enricher thread compares that against the enrichment database that you pull down based
on the MCC file, yes, the MCC file that comes down that's, all that stuff gets shoved up
into AWS.
It doesn't have to work like that.
It'd be simple enough to tool around to work off of an HTTP server but AWS was just easier
so that's what I did.
And the emitter can emit straight to scan logs which are picked up by Logstash forwarder
or you could point it off to the Logstash server itself.
I felt a lot.
I felt a lot more comfortable having it work with Logstash forwarder because Logstash forwarder
can run its own buffer if you end up with loss of communication.
It just seemed like the smarter thing to do to not have everything just pipelined up in
memory on one of these small little devices.
And everything goes up to Logstash over that single channel, no longer using OpenVPN and
Logstash has some great output plug-ins that you can use to take that structured information
that's coming in and spit it right out to graphite.
So kind of coalescing those two paths was super, super.
That's what I wanted.
It just makes things seem simpler to me.
So this is kind of a block diagram of what goes on inside the sensor.
For a calibrate scan, everything goes, it goes into the enricher thread or enricher
thread picks it up from queue and it can fire alerts on its own based on a threshold that
you set in the environment variables in resin.
Resin is the service that manages it, pushes out environment variables for running your
program so you can set a device specific threshold depending on where in the building
it is because you don't want to set the same, I mean that's, that wouldn't work and it also
sends individual events or individual structures for ARFS and metadata and the original scan
document containing your time stamp, all that other good stuff.
It's a little more interesting when you start pulling from the SIM808 module which is your
GSM modem, the enricher thread gets it, does a comparison against the enrichment database,
which is kind of sizeable but it does do a little in memory caching for a little while
just so you don't have to keep hitting disk for everything that comes through and it can
set, it can do alerts on changes in the primary cell global ID, it can do alerts on the cell
global ID not being in database and it can also do alerts on the cell global ID not being
in range based on the geolocation that's coming down through the feed.
What I kind of want to draw your attention to is this calculation is actually happening
on the Raspberry Pi.
So the idea is that you should be able to stand this stuff up and have a fairly small
compute overhead compared to some other services because a lot of the compute is happening
on the device itself so doing stuff like geospatial calculations, stuff like that, you don't have
to do all of that stuff because the, something I failed to mention earlier, remember I said
that there's about a seven minute delay on getting results with an RTL SDR device.
When you throw one of those little GSM devices, you don't have to do that.
You can just query the GSM devices into engineering mode.
It's every few seconds you get a list of all of your nearby cells by preference according
to the GSM so the RTL SDR device is more of an objective observation.
I see these channels, here's the power.
But you're interrogating the GSM modem actually tells you what it prefers.
So the stuff that's a little more GSM heavy, why do I prefer this tower over another, takes
care of all of that and you can just query the GSM modem and ask it, what do you prefer
the most?
And you can tell when your primary changes and you cut the resolution from around seven
minutes down to just a few seconds.
Woo!
So this is what you see in Slack when, you know, after the thing gets started and gets
warmed up.
These alerts are for things, you know, like not being in the feed database, other stuff
like that.
And you also get alerts for graphite beacon when you have problems with anomalies being
detected when things fall outside of the forecasted expectation for your time series measurements.
So here's where we return to the demo and see if these things are actually going to
behave for us.
So I don't think I get a drum roll up here but it's, I hope you can, I hope the angle
of anxiety is palpable.
Woohoo!
Let me just truck this over there, sorry this is, somebody told me not to do it like
this.
I thought I had enough sense to listen.
What?
All right.
Just in case.
Yeah.
Thanks.
Where did you go?
All right.
Here in a minute you're going to have me some Jack Daniels and I'll know I just need
to walk off stage.
Let's try mirroring for the win.
All right.
Can you see that?
Yeah.
Woo!
Okay.
So it actually was able to download a lot of stuff.
Because of the
All right.
So this is what it looks like.
Umm, in resin and with resin you can um, actually, okay truth advertising..
One of these..
I plugged in, in the speaker's green room.
just because I was afraid it wouldn't have enough time to download all of the things. And the one
that I plugged up a few minutes ago, let's see how far along it is. This one's called Misty
Mountain, isn't that beautiful? Okay, so, yup, still downloading. Depending on bandwidth, I
mean, it can take a little while. The initial download, so you've got a couple of minutes at
the beginning. When you pop in the SD card, it reformats it to work right for, for
Resin's operating system, and then it dials home to Resin service, and it starts pulling your
Docker image down. This is actually a lot smaller. Originally, I tried doing this with GNU
Radio, and oh my god, that thing is a monster. So you start dealing with image sizes over
two gigs, and Raspberry Pi's struggle with it. It is my hope that someday that I can get
GNU Radio trimmed down enough, because I think that, and especially the GNU Radio GSM
project, people are going to want to use it.
Peter Krysic put that together. So if you're looking for something fun to play around with, I
highly recommend that. I was hoping to get that originally worked into this, but I think ARM's
going to have to get a little bit more powerful with the stuff that you can buy off the shelf
before we'll actually be able to get GNU Radio working at least the way that I need for, for
this project. But check out GRGSM if you have a minute. It's, it's some awesome stuff. Now let's
go back to the working sensor.
All right. So in the startup process, you see download the application, installing the
application, pulls everything down from the, from the feed, get your secrets from, from the
vault. Yeah, this one started up just fine. Oh man, that's great. Not, it's not that I thought
that it would really not work, but superstition. You know, the same reason you don't do a, do a
change window on a Friday afternoon.
So to Sarah, let's see what that looks like. Let's see if we have anything for DEF CON yet.
And we do have a little bit. So these are time series measurements, and it, honestly, it looks
a little ugly. This is probably due to my configuration of graphite. Let's find a resolution
that looks decent. There we go. That's a little bit better. And you can see the, the channels
that are being tracked by the, the, the, the, the, the, the, the, the, the, the, the, the, the, the, the,
by ARFSN. And this is kind of, the RX level, this is a measurement that's produced by the cell radio
itself. Ah, here's... Yeah, this is the whole an anomaly stuff. This doesn't get really
interesting until you actually have a measurement period by which you can start to look
at, ah... The whole, whole winner's is super cool, you could probably do this with standard
deviation, but I was, oh, winners is a bigger word, right? And it's free, it's already baked
in. There's another buzzword if anybody's playing bingo. Um, so whole winners is super cool,
and that it takes seasonality into it.
So if you, not that you would ever see this
in the real world, but if you have like,
if Monday afternoons are really hot,
you know, then it'll accommodate for that.
You just have to let it see a Monday afternoon
or else you get that.
So we're even tracking the affinity,
which looks like it may have made a change.
That's interesting, isn't it?
So the cell made an affinity change
shortly after coming online,
which is pretty cool, from Arfson 180
to something higher than that.
Oh, 238.
Yeah, that's cool.
Anyway, we're all kind of discovering this.
I was, honestly, I was pretty afraid
of turning this thing on a DEF CON
and blowing up the service
by throwing so much information into it,
but it's behaved surprisingly well.
So let's see.
And here is my Kibana server.
Oh, no results yet.
And that's because my time range is crap.
All right, there's that.
Let's trim that down a little bit to two hours.
And there you can see we started getting stuff coming through.
And scans of all type.
And this is all structured data,
so if you wanted to build something on top of it
just to interrogate Elasticsearch
and pull these results out, go nuts.
All this stuff is gonna be released open source
after the talk.
So I hope that somebody out there enjoys this thing
after how much time I spent doing it.
Cool.
And our new technique is a 먹ed out
So let's return to the demo
and see if I can figure out this mirroring thing again.
All right, so summary of
mark one and mark two functionality.
So like we discussed earlier,
arps and over threshold outside forecasts work great.
With the first one, it was just slowly to return results.
7 minutes, you've already told them your stock trading tips and somebody else has them too.
With the Mark 2, we hit all of our
objectives. ARFs over threshold and outside of forecast, of course because we were still using
Calibrate. Unrecognized cell global ID, we were able to pick that up.
Gratuitous BTS re-association, we were able to pick that up as well.
BTS detected outside of range, you can do that as well. And the price
was $150. So considering that
this, if you buy this at list
price, not the price, like they've got a great deal in the vendor booth, you should all go and buy one.
These are so expensive and they've got a great deal running in the vendor booth. They didn't pay me to say that.
But with one of these,
I think you're looking at maybe around $600,
$650 with this, a Raspberry Pi, a GSM radio, you can build
an evil BTS for about $150. You can
build a
sensor to detect when these things are around. So the original goal of
having something that was easy to deploy, you know something
I mean you just pop the SD card in, make sure everything's plugged up, you ship it out, plug it up
wherever and leave it alone, let it collect its stuff. To have
it less expensive than the evil devices,
I'd call it a win.
So there's that.
Going forward, this is what I kind of like to do with it. Automatic
device detection. Something I shielded you guys from was all the environment
variables you have to configure. Some of them you want to have to configure,
you know like what is the key to retrieve all of my information
from vault, right? You don't want your search just hanging out there.
So there's that. I'd like to do device and service heartbeats because right now that's something that you just
kind of have to infer because you'll start getting
graphite alarms.
But it's really something you just have to infer. I'd like to get more specific with that.
GNU radio, like I said earlier, I would love for GNU radio to be
the core of this if I could figure out a way to make it run quickly.
And honestly to run it all on a Raspberry Pi because
running that sample rate and doing GSM processing is pretty intense.
But if you do go pure SDR, then not only GR
GSM, but you can start playing around with ADSB broadcasts from aircraft,
looking up FPV drives,
drones, all sorts of fun stuff. And maybe even running connectors for
Ubertooth 1 and Yardstick 1 because those are, you know,
those are some kind of fun things to play around with and if you can just, if you never have to touch the thing except to
install new hardware, why not, right?
So here's a hat tip and thanks to our prior art.
DIY cellular IDS and traffic interception and remote mobile
cloning with a compromised femtocell. That served as the original
inspiration that kind of got me thinking in this direction because you can get
a femtocell for 250 bucks or you can social engineer
one out of Verizon for pretty, I've been with you guys for so long, if that argument has
never worked before, it worked for me. I've been your customer for so many years and I have
crap reception in my little apartment. So
250 bucks or 600 bucks, it's
pretty cheap to be able to do some positively evil things and
last year Duckahuna and Satan Claws put on a great intro to
SDR and the Wireless Village. It was a 101 track that I really enjoyed
and kind of set me down the road of trying to figure this problem out.
Fake BTS served as the original
functional inspiration for this, kind of the interaction between Rireshark and
AirProbe and unfortunately it's a little too intense to run on ARM so that's
why I kind of had to write my own little hacked together thing.
And how to build your own rogue GPS
and BTS for fun and profit. Simone Margaritelli, thank you.
If Evil Socket is here I want to buy you a beer, if you're not I owe you one.
It was a really well written blog post on how to simply set up
an Evil BTS using one of these and a Raspberry Pi 3
and a battery pack and a GSM radio and
that helped me to kind of quantify the price
and the footprint and ease of access for parts.
So thank you Evil Socket, that was a huge help
for this talk and gave me a really good solid target to shoot for.
Thanks, GNU Radio, as much as I wish it
could have made it in here, it actually worked pretty well on the Intel NUC but those things are kind of
pricey. You are not going to beat anybody on price using an Intel NUC.
But GNU Radio runs pretty well on that for this purpose and
Peter Krysic was really helpful helping me to get up to speed on the
on the GSM stuff and calibrate.
Calibrates the core of this and without calibrate it really probably wouldn't
work very well. So hat tip and thanks to all of the prior art.
And thanks to all these fools. John Minerick made a
not small investment in test hardware. He was one of my first beta testers. So John if you're out there
thanks a bunch. Maybe not. Gillis Jones,
super helpful. Great advice. Christian Wright
and Dave Doolin suffered through this thing.
And there were a lot of silent contributors that didn't
necessarily want to be associated with a DEF CON talk. I don't know why.
I have no problem with it. But I got a bunch of really useful
information on GSM networks from some really helpful people
in the background. Anyway, we can do Q&A now
or we can take it off stage.
Were you going to release the open source?
Yep. I'm going to release it as soon as I get to a
reasonably secure network.
On your DEF CON CD there's a white paper with the links in it.
Alternatively, my handle is ashmasterflash. Check me out on Twitter
and I'll post there and I may see if I can squeeze an email
through full disclosure as well.
Ashmasterflash.
Two As.
Alright. Thanks a whole bunch everybody.