SITCH: Inexpensive, coordinated GSM anomaly detection
ashmastaflash
It's recently become easier and less expensive to create malicious GSM Base Transceiver Station (BTS) devices, capable of intercepting and recording phone and sms traffic. Detection methods haven't evolved to be as fast and easy to implement. Wireless situational awareness has a number of challenges. Categorically, these challenges are usually classified under Time, Money, or a lot of both. Provisioning sensors takes time, and the fast stuff usually isn’t cheap. Iterative improvements compound the problem when you need to get software updates to multiple devices in the field. I’ll present a prototype platform for GSM anomaly detection (called SITCH) which uses cloud-delivered services to elegantly deploy, manage, and coordinate the information from many independent wireless telemetry sensors (IoT FTW). We’ll talk about options and trade-offs when selecting sensor hardware, securing your sensors, using cloud services for orchestrating firmware, and how to collect and make sense of the data you’ve amassed. Source code for the prototype will be released as well. The target audience for this lecture is the hacker/tinkerer type with strong systems and network experience. A very basic understanding of GSM networks is a plus, but not required. Bio: Ashmastaflash is a native of southeast Tennessee and a recent transplant to San Francisco. He entered the security domain through systems and network engineering, spent a number of years in network security tooling and integration, and currently works in R&D for CloudPassage.
 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, re-burn 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 BTS's and IMSI catchers. So let's jump in. A little about me. I started with actually getting paid for technology to 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 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 10-Foil hats 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 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. Not in a hat tip to prior art and Q and 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 cellphone 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. Can you really trust your ficus, adjust your tinfoil hat? And the second side of this is it's with an IMSI catcher you can also determine whether or not a specific person is within a domicile. So if with one of these devices someone can 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 a productive reasoning you can determine who is home. So it's a little bit spooky and it's not that expensive to carry off. The terminology baseline for the talk software defined radio. I had one of those in my pocket but I gave it away. It's using software to perform your signal analysis and using a typically USB dongle that has a software controlled tuner and in the case of this we're using the RTL SDR device as a super cheapo like twenty four eight dollar units. ARFCN absolute radio frequency channel number. I may just refer to that as channel number from here on out given that this is in the 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 and 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 hack them to sell is a trusted part of the provider's network. We saw some really good talks in DEF CON 21 about hacking femto cells for the purpose of honest IDS and also for some nefarious purposes. With a hacked femto cell 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 evil BTS, evil socket had a great blog post on how to build one for very, very cheap and ham hands for scale. 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 evil BTS and record phone and SMS traffic. Again, this is the same case with the femto cell. 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? ARFC and 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 the short period of observation. So you can set a threshold, alert when it gets over that. ARFC is an outside of forecast. You can use, here's spoiler alert, we're using graphite in part of this. Graphite has Holt Winter's 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 metadata for the 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. 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 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 serves as the original inspiration for this. It's a collection of shell scripts that use wire shark and air probe 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 FIMTO catcher is very close in function to the Android IMSI catcher detector but it's specifically for catching FIMTO cells and it's really only effective for phones on Verizon Wireless's network. The original project goals. It's Vegas. I think it's okay to ask for what you can get for $100. So that was the goal is see if I can get the target price under $100 for the first iteration. I wanted a low footprint for the raw materials. I wanted it to be at least as small as this. And functional targets. I wanted to be able to pretty much use the indicators of attack as a metric on whether or not I would be successful detecting VTSs. And centrally manage 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 even want to screw around with that. I wanted to be able to drop this thing under a desk, 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. In the process of this, I collected a lot of hardware. I had a Raspberry Pi 2, a logarithmic antenna, a couple of Odroid, a C1 plus and an XU4, a galaxy of red and blue and green and orange LEDs until NUC and until Edison, a GSM modem, a handful of RTL-SDR devices. I didn't really need all this 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 Sitch. Situational information from telemetry and correlated heuristics. And I definitely started with the acronym site 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 LogStash forward to forward scan logs. Since we have it in structured formats, it's pretty easy to drop the file and LogStash picks that up, shoots it off to LogStash, Elasticsearch, 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 FIMTO cell to set up in my apartment. And when you start it up, I mean they never really consistently started 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 in 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 today 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. ARFSEN over threshold as a big yes as well as ARFSEN 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 things that 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 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 right on this and maybe it'd 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, it's this sort of sort of additive problem. It's, you can really end up with some kind of ridiculously 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, this stuff is kind of bandwidth dependent. So I'll explain a little bit more about that. Check this out. Is this thing on? All right. So this has got a RTL-SDR device, GSM radio, it's a Raspberry Pi 2, and, 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, what it's doing is there's a, the service is 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 get commit of your code, you do a get 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 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 down your 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 Addix 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 I'm as much as I love Graphite. Graphite's graphs are really not pretty. You need something to go on top of it. And Graphite Beacon 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 Res and User Interface and everything comes back up, gets its credentials and all of 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, your crypto material. Resin is the service that I use to manage the software and Slack is where the notifications come out, 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 stored in structured data in Elasticsearch and the web-based portal is kind of a combination of Kibana and DeSera. 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, an external alerting service is Slack and there's a 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 if you insist. So let's talk about the Mark II sensor and kind of the improvements I wanted to make before I showed anybody this ugly baby of mine. So there's a component, the Sim 808 collector. That interacts with GSM modem to actually function in a way that's somewhat similar to the way the Android IMS iCatcher 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 currently 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 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 4der or you could point it off to the Logstash server itself. I felt a lot more comfortable having it work with Logstash 4der because Logstash 4der 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 open VPN and Logstash has some great output plugins 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 it just make 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 enriched thread or enriched thread picks it up from Q 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 on 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 timestamp, all that other good stuff. It's a little more interesting when you start pulling from the SEM808 module which is your GSM modem. The enriched thread gets it, does a comparison against the enrichment database which is kind of sizable 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, it's coming down through the feet. 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 calculation and 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 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 on CPS 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 after the thing gets started and gets warmed up, these alerts are for things 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 the anxiety is palpable. Woohoo! Let me just truck this over there, sorry this is, somebody told me not to do it like this and if I'd have had enough sense to listen. What? Alright. Yeah, thanks. Where did you go? Alright. So 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. Alright, can you see that? Okay. So it actually was able to download all of the feed database and everything. I'm going to take a drink. Live demo, y'all. No, no, we don't want that. Alright, so this is what it looks like in Resin and with Resin you can actually, okay, truth in advertising. One of these I plugged in in the speaker's green room just because I was afraid that 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, yep, 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 Resin's operating system and then it dials home to Resin's 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 then I can get GNU Radio trimmed down enough because I think that and especially the GNU Radio GSM project, Peter Kreisich 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 this project. But check out GRGSM if you have a minute. It's some awesome stuff. Now let's go back to the working sensor. All right, so in the start-up process you see download the application, installing application, pulls everything down from the feed, gets your secrets from the vault. Yeah, this one started up just fine. Oh man, that's great. It's not that I thought that it would really not work but superstition. You know, the same reason you don't 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 DEFCON yet. And we do have a little bit. So these are time series measurements and 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 channels that are being tracked by ARSEN. And this is kind of the RX level. This is a measurement that's produced by the cell radio itself. Here's, yeah, this is the Holt Winner's anomaly stuff. This doesn't get really interesting until you actually have a measurement period by which you can start to look at, because Holt Winner's is super cool. You could probably do this with standard deviation but I was, oh, Holt Winner's, it's a bigger word, right? And it's free. It's already baked in. There's another buzzword if anybody's playing bingo. So Holt Winner's is super cool in 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 ARFs in 180 to something higher than that. 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 behave 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 elastic search and pull these results out, go nuts, all this stuff is going to 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. 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 and outside of forecast worked great with the first one. It was just really slow to return results. Seven minutes you've already told them your stock trading tips and somebody else has them too. With the mark two we hit all of our objectives. ARPS and over threshold and outside of forecast of course because we were still using calibrate. Unrecognized cell global ID, able to pick that up gratuitous BTS re-association, able to pick that up as well. BTS detected outside of range. You can do that as well. And the price was 150 bucks. 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, yeah, 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 bucks. 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 and 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 at FPV drones, all sorts of fun stuff. And maybe if we're 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 FIMTO cell. That served as the original inspiration that kind of got me thinking in this direction because you can get a FIMTO cell for $250 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 or $600. It's pretty cheap to be able to do some positively evil things. And last year, Ducca Huna and Satan Claus put on a great intro to SDR on the wireless village. It was a one-on-one 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 Ryershark and Air Probe and unfortunately it's a little too intense to run on arms so that's why I kind of had to write my own little hack together thing. And how to build your own rogue GSM BTS for fun and profit. Simone Margheritelli, 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. Good new radio. You know, 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, uh, but GNU radio runs pretty well on that for this purpose and Peter Kreisig was really helpful helping me to get up to speed on the, on the GSM stuff and calibrate, uh, 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 bunch. Maybe not. Uh, Gillis Jones, super helpful. Great advice. Uh, Christian Wright and Dave Duhlin suffered through this thing. And, uh, and there were a lot of silent contributors. They didn't necessarily want to be associated with a DEF CON talk. I don't know why. I have no problem with it. But, um, but I got a really, bunch of really useful information on, uh, on GSM networks from some, uh, some really helpful people in the background. Anyway, um, we can do Q and A now or we can take it off stage. Yep, I'm going to release it as soon as I get to a reasonably secure network. And the, uh, uh, check on your DEF CON CD. There's a white paper with the links in it. Alternatively, my handle is Ash Mastaflash. Check me out on Twitter and, um, and I'll post there and I may see if I can get, squeeze an email through full disclosure as well. Ash Mastaflash. Two A's. All right. Thanks a whole bunch, everybody. Thank you.
 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,  re-burn 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 BTS's and IMSI catchers. So let's jump in. A little about me. I started with  actually getting paid for technology to 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 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 10-Foil hats 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 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.  Not in a hat tip to prior art and Q and 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  cellphone 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. Can you really trust your ficus, adjust your tinfoil  hat? And the second side of this is it's with an IMSI catcher you can also determine whether  or not a specific person is within a domicile. So if with one of these devices someone can  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 a productive reasoning you can determine who  is home. So it's a little bit spooky and it's not that expensive to carry off. The terminology  baseline for the talk software defined radio. I had one of those in my pocket but I gave  it away. It's using software to perform your signal analysis and using a typically USB dongle  that has a software controlled tuner and in the case of this we're using the RTL SDR  device as a super cheapo like twenty four eight dollar units. ARFCN absolute radio frequency  channel number. I may just refer to that as channel number from here on out given that  this is in the 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 and 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  hack them to sell is a trusted part of the provider's network. We saw some really good  talks in DEF CON 21 about hacking femto cells for the purpose of honest IDS and also for  some nefarious purposes. With a hacked femto cell 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 evil BTS, evil  socket had a great blog post on how to build one for very, very cheap and ham hands for  scale. 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 evil BTS and record phone and  SMS traffic. Again, this is the same case with the femto cell. 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? ARFC and 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 the short period of observation. So you can set a threshold,  alert when it gets over that. ARFC is an outside of forecast. You can use, here's spoiler alert,  we're using graphite in part of this. Graphite has Holt Winter's 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 metadata for the 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. 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 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 serves as the original inspiration for this. It's a collection of shell scripts  that use wire shark and air probe 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 FIMTO catcher is very close in function  to the Android IMSI catcher detector but it's specifically for catching FIMTO cells and  it's really only effective for phones on Verizon Wireless's network.  The original project goals. It's Vegas. I think it's okay to ask for what you can get  for $100. So that was the goal is see if I can get the target price under $100 for the  first iteration. I wanted a low footprint for the raw materials. I wanted it to be at least  as small as this. And functional targets. I wanted to be able to pretty much use the  indicators of attack as a metric on whether or not I would be successful detecting VTSs.  And centrally manage 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 even want to screw around with that.  I wanted to be able to drop this thing under a desk, 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. In the process  of this, I collected a lot of hardware. I had a Raspberry Pi 2, a logarithmic antenna,  a couple of Odroid, a C1 plus and an XU4, a galaxy of red and blue and green and orange  LEDs until NUC and until Edison, a GSM modem, a handful of RTL-SDR devices. I didn't really  need all this 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 Sitch. Situational information  from telemetry and correlated heuristics. And I definitely started with the acronym  site 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 LogStash forward to forward scan logs.  Since we have it in structured formats, it's pretty easy to drop the file and LogStash picks  that up, shoots it off to LogStash, Elasticsearch, 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 FIMTO cell to set up in my apartment.  And when you start it up, I mean they never really consistently started 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 in 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 today 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. ARFSEN over threshold as a big yes as well  as ARFSEN 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 things that 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 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 right on this and maybe  it'd 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, it's this sort of sort of additive problem. It's,  you can really end up with some kind of ridiculously 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, this stuff is kind of bandwidth dependent. So I'll explain a little bit more about that.  Check this out. Is this thing on? All right. So this has got a RTL-SDR device, GSM radio,  it's a Raspberry Pi 2, and, 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, what it's doing is there's a, the service is  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 get commit of your code, you do a get 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 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 down  your 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 Addix 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 I'm as much as I love Graphite. Graphite's graphs are  really not pretty. You need something to go on top of it. And Graphite Beacon 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 Res and User Interface and everything comes back up, gets its credentials and all  of 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, your crypto material. Resin is the service that I use to manage  the software and Slack is where the notifications come out, 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 stored in structured data in Elasticsearch and the web-based portal is kind of a combination  of Kibana and DeSera. 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, an external alerting service is Slack and there's a 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 if you insist. So let's talk about  the Mark II sensor and kind of the improvements I wanted to make before I showed anybody this  ugly baby of mine. So there's a component, the Sim 808 collector. That interacts with  GSM modem to actually function in a way that's somewhat similar to the way the Android IMS  iCatcher 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 currently  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 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 4der or you could point it off  to the Logstash server itself. I felt a lot more comfortable having it work with Logstash  4der because Logstash 4der 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 open VPN and Logstash has some great output plugins 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 it just make 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 enriched thread or enriched thread  picks it up from Q 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 on 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 timestamp, all that other good stuff.  It's a little more interesting when you start pulling from the SEM808 module which is your  GSM modem. The enriched thread gets it, does a comparison against the enrichment database  which is kind of sizable 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, it's coming down through the feet. 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 calculation and 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 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 on CPS 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 after the thing gets  started and gets warmed up, these alerts are for things 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 the anxiety is palpable. Woohoo! Let me just truck this over there,  sorry this is, somebody told me not to do it like this and if I'd have had enough sense  to listen. What? Alright. Yeah, thanks. Where did you go? Alright. So 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. Alright, can you see that? Okay. So it actually was  able to download all of the feed database and everything. I'm going to take a drink.  Live demo, y'all. No, no, we don't want that. Alright, so this is what it looks like in  Resin and with Resin you can actually, okay, truth in advertising. One of these I plugged  in in the speaker's green room just because I was afraid that 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, yep, 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 Resin's operating system and then it dials home to  Resin's 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 then I can get GNU Radio trimmed down enough because  I think that and especially the GNU Radio GSM project, Peter Kreisich 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 this project.  But check out GRGSM if you have a minute. It's some awesome stuff. Now let's go back  to the working sensor. All right, so in the start-up process you see download the application,  installing application, pulls everything down from the feed, gets your secrets from  the vault. Yeah, this one started up just fine. Oh man, that's great. It's not that  I thought that it would really not work but superstition. You know, the same reason you  don't 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 DEFCON yet. And we do have a little bit. So these are  time series measurements and 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 channels that are being tracked by ARSEN. And this  is kind of the RX level. This is a measurement that's produced by the cell radio itself.  Here's, yeah, this is the Holt Winner's anomaly stuff. This doesn't get really interesting  until you actually have a measurement period by which you can start to look at, because  Holt Winner's is super cool. You could probably do this with standard deviation but I was,  oh, Holt Winner's, it's a bigger word, right? And it's free. It's already baked in. There's  another buzzword if anybody's playing bingo. So Holt Winner's is super cool in 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 ARFs in 180 to something higher than that. 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 behave 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 elastic search and pull these results out,  go nuts, all this stuff is going to 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. 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  and outside of forecast worked great with the first one. It was just really slow to return  results. Seven minutes you've already told them your stock trading tips and somebody else  has them too. With the mark two we hit all of our objectives. ARPS and over threshold  and outside of forecast of course because we were still using calibrate. Unrecognized  cell global ID, able to pick that up gratuitous BTS re-association, able to pick that up as  well. BTS detected outside of range. You can do that as well. And the price was 150 bucks.  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, yeah, 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 bucks. 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 and 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 at FPV drones, all sorts of fun stuff. And  maybe if we're 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 FIMTO cell. That served as the original inspiration that kind  of got me thinking in this direction because you can get a FIMTO cell for $250 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 or $600. It's pretty cheap  to be able to do some positively evil things. And last year, Ducca Huna and Satan Claus  put on a great intro to SDR on the wireless village. It was a one-on-one 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 Ryershark and Air Probe and unfortunately it's a little too intense to run on arms so  that's why I kind of had to write my own little hack together thing. And how to build your  own rogue GSM BTS for fun and profit. Simone Margheritelli, 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. Good new radio. You  know, 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, uh, but GNU radio runs pretty well on that for this  purpose and Peter Kreisig was really helpful helping me to get up to speed on the, on the  GSM stuff and calibrate, uh, 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 bunch. Maybe not.  Uh, Gillis Jones, super helpful. Great advice. Uh, Christian Wright and Dave Duhlin suffered  through this thing. And, uh, and there were a lot of silent contributors. They didn't  necessarily want to be associated with a DEF CON talk. I don't know why. I have no problem  with it. But, um, but I got a really, bunch of really useful information on, uh, on GSM  networks from some, uh, some really helpful people in the background. Anyway, um, we can  do Q and A now or we can take it off stage. Yep, I'm going to release it as soon as I  get to a reasonably secure network. And the, uh, uh, check on your DEF CON CD. There's  a white paper with the links in it. Alternatively, my handle is Ash Mastaflash. Check me out  on Twitter and, um, and I'll post there and I may see if I can get, squeeze an email through  full disclosure as well. Ash Mastaflash. Two A's. All right. Thanks a whole bunch, everybody.  Thank you.
DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_0_7211.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_7212_15131.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_15132_16175.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_16176_21191.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_21192_21431.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_21432_22763.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_22764_23051.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_23052_23099.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_23100_23159.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_23160_23231.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_23232_23339.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_23340_23459.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_23460_23927.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_23928_23975.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_23976_24023.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_24024_24071.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_24072_25751.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_25752_25811.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_25812_29615.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_29616_30323.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_30324_30383.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_30384_30731.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_30732_31103.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_31104_33431.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_33432_33599.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_33600_41003.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_41004_41639.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_41640_42995.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_42996_43283.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_43284_44195.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_44196_46019.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_46020_46103.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_46104_47027.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_47028_47135.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_47136_47351.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_47352_48743.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_48744_49967.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_49968_50051.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_50052_50615.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_50616_51551.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_51552_55967.png DEF_CON_24_-_ashmastaflash_-_SITCH_Inexpensive_Coordinated_GSM_Anomaly_Detection_YDALL62Nz0k_55968_61475.png
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, re-burn 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 BTS's and IMSI catchers. So let's jump in. A little about me. I started with actually getting paid for technology to 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 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 10-Foil hats 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 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. Not in a hat tip to prior art and Q and 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 cellphone 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. Can you really trust your ficus, adjust your tinfoil hat? And the second side of this is it's with an IMSI catcher you can also determine whether or not a specific person is within a domicile. So if with one of these devices someone can 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 a productive reasoning you can determine who is home. So it's a little bit spooky and it's not that expensive to carry off. The terminology baseline for the talk software defined radio. I had one of those in my pocket but I gave it away. It's using software to perform your signal analysis and using a typically USB dongle that has a software controlled tuner and in the case of this we're using the RTL SDR device as a super cheapo like twenty four eight dollar units. ARFCN absolute radio frequency channel number. I may just refer to that as channel number from here on out given that this is in the 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 and 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 hack them to sell is a trusted part of the provider's network. We saw some really good talks in DEF CON 21 about hacking femto cells for the purpose of honest IDS and also for some nefarious purposes. With a hacked femto cell 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 evil BTS, evil socket had a great blog post on how to build one for very, very cheap and ham hands for scale. 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 evil BTS and record phone and SMS traffic. Again, this is the same case with the femto cell. 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? ARFC and 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 the short period of observation. So you can set a threshold, alert when it gets over that. ARFC is an outside of forecast. You can use, here's spoiler alert, we're using graphite in part of this. Graphite has Holt Winter's 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 metadata for the 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. 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 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 serves as the original inspiration for this. It's a collection of shell scripts that use wire shark and air probe 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 FIMTO catcher is very close in function to the Android IMSI catcher detector but it's specifically for catching FIMTO cells and it's really only effective for phones on Verizon Wireless's network. The original project goals. It's Vegas. I think it's okay to ask for what you can get for $100. So that was the goal is see if I can get the target price under $100 for the first iteration. I wanted a low footprint for the raw materials. I wanted it to be at least as small as this. And functional targets. I wanted to be able to pretty much use the indicators of attack as a metric on whether or not I would be successful detecting VTSs. And centrally manage 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 even want to screw around with that. I wanted to be able to drop this thing under a desk, 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. In the process of this, I collected a lot of hardware. I had a Raspberry Pi 2, a logarithmic antenna, a couple of Odroid, a C1 plus and an XU4, a galaxy of red and blue and green and orange LEDs until NUC and until Edison, a GSM modem, a handful of RTL-SDR devices. I didn't really need all this 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 Sitch. Situational information from telemetry and correlated heuristics. And I definitely started with the acronym site 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 LogStash forward to forward scan logs. Since we have it in structured formats, it's pretty easy to drop the file and LogStash picks that up, shoots it off to LogStash, Elasticsearch, 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 FIMTO cell to set up in my apartment. And when you start it up, I mean they never really consistently started 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 in 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 today 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. ARFSEN over threshold as a big yes as well as ARFSEN 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 things that 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 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 right on this and maybe it'd 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, it's this sort of sort of additive problem. It's, you can really end up with some kind of ridiculously 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, this stuff is kind of bandwidth dependent. So I'll explain a little bit more about that. Check this out. Is this thing on? All right. So this has got a RTL-SDR device, GSM radio, it's a Raspberry Pi 2, and, 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, what it's doing is there's a, the service is 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 get commit of your code, you do a get 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 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 down your 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 Addix 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 I'm as much as I love Graphite. Graphite's graphs are really not pretty. You need something to go on top of it. And Graphite Beacon 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 Res and User Interface and everything comes back up, gets its credentials and all of 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, your crypto material. Resin is the service that I use to manage the software and Slack is where the notifications come out, 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 stored in structured data in Elasticsearch and the web-based portal is kind of a combination of Kibana and DeSera. 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, an external alerting service is Slack and there's a 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 if you insist. So let's talk about the Mark II sensor and kind of the improvements I wanted to make before I showed anybody this ugly baby of mine. So there's a component, the Sim 808 collector. That interacts with GSM modem to actually function in a way that's somewhat similar to the way the Android IMS iCatcher 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 currently 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 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 4der or you could point it off to the Logstash server itself. I felt a lot more comfortable having it work with Logstash 4der because Logstash 4der 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 open VPN and Logstash has some great output plugins 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 it just make 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 enriched thread or enriched thread picks it up from Q 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 on 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 timestamp, all that other good stuff. It's a little more interesting when you start pulling from the SEM808 module which is your GSM modem. The enriched thread gets it, does a comparison against the enrichment database which is kind of sizable 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, it's coming down through the feet. 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 calculation and 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 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 on CPS 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 after the thing gets started and gets warmed up, these alerts are for things 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 the anxiety is palpable. Woohoo! Let me just truck this over there, sorry this is, somebody told me not to do it like this and if I'd have had enough sense to listen. What? Alright. Yeah, thanks. Where did you go? Alright. So 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. Alright, can you see that? Okay. So it actually was able to download all of the feed database and everything. I'm going to take a drink. Live demo, y'all. No, no, we don't want that. Alright, so this is what it looks like in Resin and with Resin you can actually, okay, truth in advertising. One of these I plugged in in the speaker's green room just because I was afraid that 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, yep, 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 Resin's operating system and then it dials home to Resin's 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 then I can get GNU Radio trimmed down enough because I think that and especially the GNU Radio GSM project, Peter Kreisich 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 this project. But check out GRGSM if you have a minute. It's some awesome stuff. Now let's go back to the working sensor. All right, so in the start-up process you see download the application, installing application, pulls everything down from the feed, gets your secrets from the vault. Yeah, this one started up just fine. Oh man, that's great. It's not that I thought that it would really not work but superstition. You know, the same reason you don't 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 DEFCON yet. And we do have a little bit. So these are time series measurements and 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 channels that are being tracked by ARSEN. And this is kind of the RX level. This is a measurement that's produced by the cell radio itself. Here's, yeah, this is the Holt Winner's anomaly stuff. This doesn't get really interesting until you actually have a measurement period by which you can start to look at, because Holt Winner's is super cool. You could probably do this with standard deviation but I was, oh, Holt Winner's, it's a bigger word, right? And it's free. It's already baked in. There's another buzzword if anybody's playing bingo. So Holt Winner's is super cool in 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 ARFs in 180 to something higher than that. 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 behave 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 elastic search and pull these results out, go nuts, all this stuff is going to 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. 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 and outside of forecast worked great with the first one. It was just really slow to return results. Seven minutes you've already told them your stock trading tips and somebody else has them too. With the mark two we hit all of our objectives. ARPS and over threshold and outside of forecast of course because we were still using calibrate. Unrecognized cell global ID, able to pick that up gratuitous BTS re-association, able to pick that up as well. BTS detected outside of range. You can do that as well. And the price was 150 bucks. 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, yeah, 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 bucks. 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 and 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 at FPV drones, all sorts of fun stuff. And maybe if we're 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 FIMTO cell. That served as the original inspiration that kind of got me thinking in this direction because you can get a FIMTO cell for $250 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 or $600. It's pretty cheap to be able to do some positively evil things. And last year, Ducca Huna and Satan Claus put on a great intro to SDR on the wireless village. It was a one-on-one 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 Ryershark and Air Probe and unfortunately it's a little too intense to run on arms so that's why I kind of had to write my own little hack together thing. And how to build your own rogue GSM BTS for fun and profit. Simone Margheritelli, 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. Good new radio. You know, 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, uh, but GNU radio runs pretty well on that for this purpose and Peter Kreisig was really helpful helping me to get up to speed on the, on the GSM stuff and calibrate, uh, 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 bunch. Maybe not. Uh, Gillis Jones, super helpful. Great advice. Uh, Christian Wright and Dave Duhlin suffered through this thing. And, uh, and there were a lot of silent contributors. They didn't necessarily want to be associated with a DEF CON talk. I don't know why. I have no problem with it. But, um, but I got a really, bunch of really useful information on, uh, on GSM networks from some, uh, some really helpful people in the background. Anyway, um, we can do Q and A now or we can take it off stage. Yep, I'm going to release it as soon as I get to a reasonably secure network. And the, uh, uh, check on your DEF CON CD. There's a white paper with the links in it. Alternatively, my handle is Ash Mastaflash. Check me out on Twitter and, um, and I'll post there and I may see if I can get, squeeze an email through full disclosure as well. Ash Mastaflash. Two A's. All right. Thanks a whole bunch, everybody. Thank you.
coordinated GSM anomaly detection. More something that was going to be far less expensive field. So central configuration and software changed focus and now I'm working in R&D for a cloud workload security company. And I don't like 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 if you've got it then great but it's not It's using software to perform your signal cell ID. Every mobile country code has a number know that these malicious devices are in play and one for very, very cheap and ham hands for scale. record phone and SMS traffic. Again, this is the malicious. So current detection methods, both under $100 for the first iteration. I wanted a information from telemetry and correlated updates which is really nice if you're sticking structured data in Elasticsearch and the merges that with the information of the Twilio that you need to be downloading for. So it to work, it is a lot of information and maybe or of the improvements I wanted to make before I services because a lot of the compute is beginning when you pop in the SD card it all type. And this is all structured data. So if be released open source after the talk. So I hope how much time I spent doing it. So let's return having something that was easy to deploy, you on how to simply set up an Evil BTS using one of to get up to speed on the, on the GSM stuff and hardware. He was one of my first beta testers. So useful information on, uh, on GSM networks from squeeze an email through full disclosure as well.