Chasing Your Tail With a Raspberry Pi

It's Thursday afternoon. I thought there'd be like 30 of you, but they mic'd me up because if I had to stand there for half an hour straight I would explode. I've given a lot of different conference talks and I've never started off with the whole 'hey, here's my motivation for doing it, why I made this talk.' I'm always like, who cares, right? Here's the talk, here's what I want to talk about. So indulge me for one second while I actually do that this time. And the reason is because this time it actually matters. What happened is a buddy of mine reached out last year, late last year, and he said he needed to get together and talk with me about a Wi-Fi question. He works with a government agency that I won't name. I had a good idea of what he wanted to ask, and it turns out I was horribly wrong, as usual. What he wanted to talk about was this: he had a confidential informant, and this confidential informant had ties to a nation-state terrorist group. I won't name the group, but a very, very serious group. My friend, he wasn't worried for his own physical safety or anything—figures he can take care of himself. He was worried about the safety of his informant. What he was worried about was, if I'm meeting with this individual and someone follows me as I'm driving away, and they keep following me and they figure out where I work, they're going to go back and harm this individual. It won't be good for them. So they weren't concerned with their own physical safety, they were concerned with the physical safety of this person who was providing the information. So I'm like, wow. What it was, was a couple years earlier they had heard me talk about the possibility of maybe using wireless to tell if you were being followed, in a methodology that I'll talk about in just a second. So they said that they went to their tech people, they didn't have anything. So he came to me, and I kind of didn't want to reinvent the wheel. I told him, yeah, you know what, let me take a look, and if not, maybe I can make you something. I started doing research, trying to find out if there was anything like this, and I just really couldn't find anything. And that really kind of was depressing to me, because there's so much technology out there to stalk on people and invade their privacy, and there's so little to try to help people that are in that situation. It's really kind of depressing. Someone very close to me has dealt with the stalking issue, and it's just devastating. You just never get that mental piece. It's a very, very difficult situation. So I kind of thought about it for a little bit and thought, well, I don't really see a way this can be abused. It's really only designed to try to tell if you're being followed, not to help follow someone else. So let's give it a go. That's kind of the background for this.

This is a room full of technical people. If I say SDR, most of us kind of think software-defined radio, hack RF, something like that. But the original SDR: surveillance detection route. Things that a lot of them are fairly common sense: changing lanes, seeing who changes lanes behind you, getting off the freeway, getting right back on, seeing who exited off, who's getting right back on behind you, certain things like that. Anyone who's ever played in that space and lived in Washington DC—the reason I chose this map, it's really obvious that the Beltway is designed to be one giant surveillance detection route. That's kind of one of the reasons I think it's laid out the way that it is. He was using this tradecraft, he just wanted a little technical assistance with it. The methodology he'd heard me speak about years earlier was: listen, I understand that tradecraft as well, but if you really want to tell if you're being followed, maybe also think of something like this: go to Starbucks to grab a drink, then go somewhere else, and then go somewhere else, and now sit there and see: did I see any devices at all three locations? Because think about it: even a nation-state quality surveillance team with very, very good tradecraft, very, very good equipment, who knows what they're doing—isn't there still a really good chance that they have a phone in their pocket, or one in the car? Maybe the AirPods, a Bluetooth headset, something synced up to the car. If you're connected to a network, great, I can see the MAC address. And if you're not connected to the network, even better, because the odds are most people don't shut off their Wi-Fi unless you're coming to a hacking conference, in which case it should absolutely be shut off. You're coming to Black Hat, Defcon, yet shut off, it stays off pretty much the entire week. But when most people are just kind of living their daily lives, that's on. And what are our phones doing? They're sitting there looking for wireless networks where we've connected to historically. That in and of itself can become a signature. Am I seeing something right now that I also saw five to ten minutes ago, ten to fifteen minutes ago, all the way down the line? That's the methodology we were going for here.

To do this, we wanted to keep it completely passive. We're just passively trying to detect Wi-Fi and Bluetooth devices that we observe around us. It really doesn't matter if they're part of an active connection or not, it'll work either way. There's a little bit of a difference in the methodology, we'll talk about that. For hardware, I didn't want to go buy anything. I ended up buying a little bit, but this is very, very cheap. It's things like—seriously, how many of us have multiple Raspberry Pis sitting in the closet doing absolutely nothing? I used a Raspberry Pi B for this, not a 3B. Not that there was any reason to, I just have like three of them in my closet for some weird reason. A lot of these are things that a lot of us probably have laying around or can get very, very cheap. First off, Raspberry Pi: there are multiple versions of these I could have used. Normally these are about $35, but right now there's a really, really lame shortage, they're going for like $120. Quite a bit more, but like I said, I think a lot of us have this or something very, very similar laying around. For a wireless card, I had a bunch of Alpha cards, but I went to the Kismet Discord and asked the community there what the general consensus was, the current best wireless card that a lot of people were using. This was the Alpha card that a lot of people recommended. The slides will be available online, they might be today already, so they'll be out there on the Black Hat site. For a battery pack, once again I had several of them just kind of laying around in my closet that had been giveaways from other places or Ankers that I had gotten very, very cheap on Amazon over the years. Needed a display, because in a few slides you're going to see literally the worst user interface you have ever seen. I mean, you're like, 'Ah, it's not that bad.' Oh yeah, wait for it. It's probably the highlight of the talk, if I'm being honest. But if you think about it, you have this little device, you're going to be driving down the road in this situation. You need some type of feedback, so a little screen on a Raspberry Pi that was I think like $25 on Amazon. I didn't have one of those laying around, so that was the one thing that I actually had to buy.

For software, for the base for actually handling the wireless signals, the Bluetooth signals and whatever else we want to expand it on into the future, we actually use Kismet. If you've never played with Kismet, Kismet is amazing. It is a free tool, it basically just sniffs all the wireless that you can find. The reason why you want to use an external wireless card is so you can put it into monitor mode. You can basically just tell it, 'Listen, don't try to connect to anything. You've been working really, really hard lately. Just take a few minutes, relax, sit back, and just kind of see what's floating through the air.' You basically turn your wireless card into a pothead. Kismet is very, very good at putting the Wi-Fi card into that mode. It supports Wi-Fi, Bluetooth, a lot of different types of signals. Like I said, there's a lot of capability to expand this in the future, no doubt. One really, really nice thing is it writes all that data to a SQLite database. That's what we're going to actually use and try to pull the live real-time data from. It's got separate options like generating a pcap, other formats, but there's really no need to because you can generate those from the database. So you don't want to generate those live because all you're doing is wasting computational effort for no reason. Everything else is shoddy Python code. It's a couple of tiny batch scripts and just very, very ugly Python code. If you ever want to feel better about your coding capability, just go to my GitHub. I promise, like two of my projects somehow made it into the Arctic Code Vault, so it's nice to know that thousands of years after I'm dead, my shoddy code will live on somewhere. But seriously, when you're going to start to release a project like this and you start to think about putting it up at Black Hat, imposter syndrome is real. It absolutely is, it is very, very real. So you just kind of tell yourself and remind yourself that you know, don't let perfect be the enemy of good. Just because something isn't perfect, just because something has faults, doesn't mean that it's not worth doing. I think that's really one of the core things to remember with pretty much anything in security, or pretty much anything in life if I'm being perfectly honest. That gentleman, Robert Watson-Watt, he was one of the people who made a lot of advancements in radar. He was just kind of tasked with defending London during World War II from the German air raids. And you know, 'Give them the third best to go with, the second best comes too late, and the best never comes.' So yeah, if anything, if you take anything from this talk, don't be self-conscious. I push my shoddy Python code out there on a regular basis, and I would never insult a real programmer by calling myself a programmer, but I can write ugly functional code that helps me and helps my teammates, and I'm cool with that.

By default, I have Kismet set up to start when the Raspberry Pi powers up. I just give it like a little 30-second delay to let everything else get into place. But then by default, once you start Kismet up, it automatically starts sniffing and seeing everything that you've set it up to keep an eye out for and putting it into a SQLite database. It names the database a file with a .kismet extension, but it's SQLite. So what you can do is you can just have the date, the current date and time, be the file name of that file, and you just have it constantly go to the same directory. Then the Python code, once the Python code runs, all it does is go look in that directory and grab the newest file. So that way you're always getting the live data. You just pull the power out, doesn't matter, goes away. You plug it in, power it up, it's automatically within a minute up and sniffing and monitoring and doing its thing. I did need to slightly change my methodology. The original way, when he had heard me speak about it years ago but not actually implement it, was thinking about well, we go to location one, then we go to location two, then we go to location three. That doesn't really work very well when you're driving for long periods of time. You're going to be driving down the highway for half an hour or an hour or more. That methodology really doesn't type of fit. So what we ended up doing was just going with a temporal based, just going off time. Do I see any devices right now that I also saw five, ten minutes ago, ten to fifteen minutes ago, or fifteen to twenty minutes ago? If so, let me know the device type: was it Bluetooth, is it a Wi-Fi client, Wi-Fi access point? Let me know the MAC address and let me know what time frame that I previously saw it in. If you're thinking, 'Well, this is easy, that's just a SQL query. What did I see in the past minute that I also saw during these previous times?' It's actually—the first snag, and there was a solution, but the snag is this: in that Kismet database, all the data you could want is contained, but most of it is in these JSON blobs. You can't parse them, but that starts to get very, very heavy on a very low-powered device. You're already pulling data from a SQLite database that's actively having data being written to it. It works, I've never had any issues, but I realized that is also a recipe for hijinks, and you want to kind of be as gentle on that database as possible. In the database itself, in the fields that are parsed and normalized, it has the first time that it has seen a device and it has the last time that it's seen a device, but it doesn't have any times in between those. So trying to figure out what do we see five to ten minutes ago, ten to fifteen, etc., doesn't really fit with what we have in the database. The solution—and I'm not saying there's not other ways to do this—but what I did is I create lists. When this starts up automatically, it makes a list of devices that it saw five to ten minutes ago, ten to fifteen, fifteen to twenty. Then it starts constantly looking at devices that it's seeing. Every minute, it'll take a list of devices that it's seen in the past minute, check to see if they're getting onto the list, fire an alert if there are. And every five minutes, it'll start to rotate the lists: what was the five to ten becomes the ten to fifteen, all the way down the line. Everything that it's seeing for the past five minutes, it's storing in a list which then becomes the new five to ten, and it just kind of rotates down the line. I'm not saying it's the only way to solve the problem, it was just the solution that I thought of and implemented, and it works.

Another thing, a tiny bit of tradecraft here: we don't want to alert on ourselves. I don't want to fire this up, go for a drive, and then be like, 'Ah, there's an iPhone following me.' Yeah, it's the one in my pocket. So how you actually do this when you're doing signals intelligence style of work is—I've done some of this work in a previous life—you get together in a room, you sit down, you see a list of all the devices that we're seeing. So I would fire something up right now, I would let it run for a few minutes, seeing all of our phones, everyone that doesn't have their wireless or Bluetooth turned off. Then you basically create an ignore list. Now we can see if someone else new enters the room, because that device is not on our ignore list, and so now we get the alert. That's the functionality that we need. Anytime we can create an ignore list of every MAC address that it's seen in the latest Kismet database. So what I would do is turn it on, let it run for a few minutes, soak in everything that it sees, and then boom, just tap the button—which you'll see how ugly the buttons are in a second—tap the button to create an ignore list. Now I have a list of everything it's seen that I don't want it to alert on, and it'll ignore those for the rest of the session. I can delete or recreate the ignore list. Yeah, don't laugh. No seriously, laugh. This is reminiscent of some old Microsoft Access databases I made back in the day. Seriously though, if you're thinking about this, it's not that I just put five minutes on this and just gave up. Look at me, I'm not a small dude, I'm six foot four. I do not have delicate little fingers. So if you're driving down the road and these gorilla hands need to mash a button, you don't want like this nice interface designed by Apple. You want an interface designed by Fisher Price. This is a GUI by Fisher Price. That is what I needed. I needed the Speak & Say. So yeah, that's why we have these big, horribly ugly buttons. Yes, I probably could have made them look slightly prettier, but why? I was busy doing other stuff.

So now that I had it, it was time to do a little bit of field testing. Kind of drive off into the middle of nowhere, which is one really, really big perk of living in the desert. When you live in Arizona, you can go in the middle of nowhere. It's really, really easy to go where there's no other signals around you. I started doing some testing and things were working good. It was like, okay, it's working. Let me go do a field test. Let me drive out in the middle of nowhere, turn on two phones that I previously had off, and I saw absolutely nothing interesting. So I took it back, dumped the data that I did see into a pcap, fired up Wireshark, and now here's where you realize the fun. Because there's something that I knew was taking place, I just didn't realize how often it was taking place, and that's MAC address randomization. In the name of privacy and security, we have devices now that they're constantly looking for networks they've connected to in the past, but they're spoofing a MAC address to try to keep your privacy and security. I knew that that was a thing, I knew MAC address spoofing existed, I just didn't realize that it was basically constant. This was a very, very narrow field of time, and if you look at the very far right—I know it's very small—but this is all two devices looking for one network. These are all just looking for one Wi-Fi network. If you look at the first part of the redacted most of the Wi-Fi name, but you can see the first part of it starts with a 'DF' there. You only see the same MAC address twice. So basically every time these devices are probing, they're spoofing a new MAC address. MAC address randomization was a thing, I just personally honestly didn't realize that it was basically every request, it was just constantly going on. So it's like, all right, the MAC address methodology that we had before still needs to be in place, because it still needs to detect things that are part of an active connection, it still needs to detect things that don't randomize. But for things that randomize, is this a deal breaker? It's not, because now what we're looking for is—we're going to look for what it's looking for: the probe request, the actual name of the Wi-Fi network. So my buddy Singe in the front row right here, down in South Africa, his Wi-Fi network is named 'Singe's Wi-Fi' and his Wi-Fi is on right now. His device should be looking for, 'Hey, Singe's Wi-Fi, are you there? Singe's Wi-Fi, are you there?' He can spoof his MAC all he wants, that can be spoofing every request. I still see a MAC address is looking for a name that's fairly unique. Fairly unique—this is where people get tripped up. We'll end the slides here in a little bit talking about this. People want to name their Wi-Fi something funny, something unique, something clever to impress their friends and impress their neighbors. But what's the key part of that sentence? Unique. Unique. This is what can start to give us away and maybe help us a little bit of attribution on who we're detecting as well. So what we do is now we actually, to get the probe requests, we have to dive down into those JSON blobs. There's just a little snippet of the Python code for kind of parsing down. So now all of the methodology that we talked about previously for MAC addresses, we have the same methodology for probe requests. We're actually looking for wireless networks that things have looked for, and we don't really care what the MAC address is, we're going off the name of the network at this point. We have the same—they're included in ignore lists and everything else.

The user display, much prettier than the GUI? No, no, it's the same. Fire it up there and you start to see what it does. It instantly starts to identify things. It has—we added 308 MAC addresses and 27 wireless network names that were being probed for into the ignore list, and now it just fires up. As it continues on, you see what happened. This was at home when I actually did this, that's why some of the MAC addresses are kind of censored out. But I left this running for a little bit, and then all of a sudden, maybe one of my neighbors turned on a device that was previously off, maybe they had like someone come visit them. But all of a sudden now there was a phone somewhere near my house, or a device, a device that was looking for a network name 'Samsung Smart'. I started seeing these probe requests that I had also seen five to ten minutes ago and ten to fifteen minutes ago, and ten to fifteen minutes ago all the way down the line. So once again, I was trying to design this because the original person who needed it was going to be driving down the road. It's really, really tough to kind of drive and pay attention to something else or really be too terribly interactive with it. So like I said, I made basically kind of Fisher Price user interfaces on purpose. I personally think for a very, very good reason. The MVP version of my testing—I mean MVP here not as Most Valuable Player for any other sports fans out there, the Minimum Viable Product. Before I bother drilling holes in my Pelican case, because those things ain't cheap, let me make sure that this thing actually works. From going around and testing, yeah, the thing actually worked. So okay, so then we have these slightly better-ish version. It's still nothing that I would actually want to sell or anything like that, but at least looking a little bit easier. Some foam cut in the case, the battery pack there. It gets pretty good life. Even a very, very cheap Anker that was less than $20 on Amazon will power this thing for over eight hours. I got a little bit more robust battery pack, that one right there, and it'll power for over 24 hours. So it actually gets pretty good life. You can always go to a cigarette lighter or something too, I just wanted to keep this one as portable as possible, but it uses very, very little power.

We said earlier that Kismet keeps great logs. This was—I was speaking, it was kind of cool. I haven't even tweeted it out yet, but this morning Wired actually published an article on me and this talk, and that was kind of neat. As I was talking to the reporter about two weeks ago, he asked me, 'Well, could you maybe tell information about the people that were following you?' And I'm like, 'Yeah, yeah, we can.' We kind of started to go down that gap and explain it. Potentially we could, because of what I said just a couple of minutes ago: people have a very, very bad habit of naming their Wi-Fi something unique and clever and funny to impress people. It's not just individuals, organizations do it too. Public, private, we all kind of do it. I'm getting ready to show an example here in just a second, and it's not trying to like shame anyone or shame any agency, because everybody does it. People don't think about that: hey, now your device, potentially depending on what kind of device it is, settings are, and some other factors, everywhere you go it's looking for this. So we fired up the old wigle.net, and I did the government agency the courtesy of blocking out the first part of that Wi-Fi name. It was saying the name of a government agency and 'the strike force', and this was outside of a building that is not publicly known to be government, but absolutely has government in there. Once again, I'm not doing this to kind of name and shame or 'haha, how can they be so stupid?' Everyone does it. Public sector, private sector, people. But people have a horrible habit, especially if you work in a big organization. But not you. You and 80 of your friends, you work in this really, really cool little group, this little subcomponent. Heck yeah, you're gonna name the little Wi-Fi at the office the name of that subcomponent and something else. This is giving away. I've been in rooms where I was basically the only one there who wasn't like kind of an SF operator, and you just start looking down like, 'Okay, which one of you is stationed at 10th Mountain? Okay, which one of you is stationed here?' Once again, I'm not naming and shaming, everyone does it. It's just something to think about. Potentially, even if it's not like a government organization or anything following you, if it's just an individual, still things tend to be unique. Even like Verizon Wi-Fi's and certain things like that. If you start to see these probe requests and they're unique probe requests that start to follow you, you may now be able to provide a little bit of attribution on the devices that you're seeing.

The path forward: more Wi-Fi adapters potentially. I think the biggest one is more wireless protocols. I think the most logical step for expansion is probably a TPMS, like the low pressure sensors in tires, because those get a little more range than a lot of people realize. Adding in a GPS to start to go back after the fact and kind of generate a map of if you saw something following you, where did you first see it and all the way down the line. You have the logs there, the logs are there, just a matter of writing scripts to kind of generate some of this data. Special thanks to a few people: Mike Kershaw, the Kismet Discord. I had a few questions about doing some of the things that I was doing, and I was asking him. This man right there, Dominic White, Singe, he's one of the best Wi-Fi researchers that I know. I think two times when I was working on this, I would kind of reach out and it's like, 'Hey, listen, this is what I'm seeing, this is what I think it is, am I correct?' And he'd be like, 'Yeah, I know,' or 'Here it is,' and down the line. So thank you very much, my friend, I appreciate it. And Josh Wright for kind of some of the same things, bouncing some of these ideas off them. So that said, I've about used up all my time. The code is all out there, it's all on my GitHub. If you shoot me an email or hit me up on Twitter or whatever, I'll throw the link to it right there. But the code is all out there, the parts list is all out there. I'm probably going to do up a blog post on digital forensics tips in the next couple days as well. But if you have any questions, I think they're going to take me to a little speaker room after the fact. Other than that, you had a lot of choices for your Thursday afternoon. Thank you very much for spending it with me, I appreciate it. Thank you.