 Good afternoon everyone. Thank you very much for coming to our talk. My name is Vivek Ramachandran and today I'm going to talk about how to create your own Wi-Fi IDS firewall on a Windows endpoint. So this has been a team effort. Myself and Dennis were the primary programmers and architects and Ashish was responsible for most of the testing. A little bit about me. I started as a programmer then as an architect, worked for Cisco 802.1 export security. I found a bunch of wireless attacks, the Cafe Latte attack, broke web cloaking. After that transition full time to become a researcher and a trainer, I run security tube.net and pentester academy. Written a bunch of books on wireless security. And we also have our very first self-published book at the Defcon vendor area that interests you. This is how to build your own Wi-Fi pineapple from scratch. Okay. So let's begin with the talk. What was the motivation for working on this? Now as someone working with wireless security probably for the last 14 years, I've always been doing attacks. I found my own attacks, talked about them, demonstrate that to my customers. And that is fun. I mean we all love attacks. But what about defense? So every single time let's say I create a honey pot and the clients connect to it, looks great. The very first question I get asked is can this be stopped? Could you make a Windows or any operating system based endpoint smart enough that it can figure out that this is not the authorized access point it should be connecting to? Now seemed like an important problem to solve, but was the solution even viable? Now I started looking at what was out there. Most of the defenses today for wireless intrusion detection system are entirely enterprise focused. Most of the stuff would involve sensors. This could be an overlay network. Some infrastructure vendors are trying to get stuff which can do in line as well. But it's entirely enterprise focused. As far as roaming clients are concerned, at this point generally it is policy based. Right? You can switch off your Bluetooth, your Wi-Fi once you're out of the enterprise premise. Unfortunately, nothing is intelligent enough to detect things like actual Wi-Fi attacks. Why is this so complicated to solve? Well you have heterogeneous devices. With BYOD, now you have tablets, phones, IoT devices. So coming up with a solution which will work across all platforms is actually quite difficult. So I decided to go ahead and look at this and choose Windows to begin with. Why? Windows is of course the most restrictive platform at this point. If I look at end points, if there is a Linux based operating system, you can always sniff packets, correlate things and figure it out. Right? Without your own custom intermediate or call out drivers, on Windows pretty much you can't do anything. So when I started off I decided let's look at the attack surface so that we can narrow the problem down. Now most Wi-Fi clients are worried about things like honey pots, evil twins, mis-association attacks, hosted network based back doors. Now most people may actually think honey pots are restricted only to open networks but they can extend to WPA, PSK enterprise and all of that as well. So how does a typical attack work? You have clients which send out probe request packets. These probe request packets are searching for different SSIDs which the client has in its preferred network list. At that point the attacker creates different honey pots and the client may be lured to connect to one or more of those honey pots. When that happens the attacker can give an IP address, ton of different possibilities exist. This is how typically your Wi-Fi pineapple, AirBaseNG, host APD, pretty much every device or tool out there works in having clients connect to it. Is the captioning working okay? I'm sure a lot of the stuff must be going to fun to read. I don't know if it can pick up everything I say with my accent. It should be fun. At least you'll have fun either way. Either it's my tool or the captions. So what are the different ways by which clients can be attacked? So as I said AP less cracking is really what happens in the wild. When there is no encryption that's of course easy. Then you have Web, PSK, PEEP, TTLS and all of that and there are different techniques for AP less cracking which include the cafe latte which I discovered 8 years back and a bunch of others. Now you could be attacked pretty much anywhere and once someone goes ahead and hijacks your Wi-Fi he basically owns your layer 2 which means traffic monitoring, DNS hijacking, SSL or most protocols can be MITM'd including applications at higher layers. So when we began researching on this I decided to define the scope first to create something which would work across all operating systems from day 1 is always difficult to solve. So we said windows and points. In version 1 the biggest stipulation which I added was there cannot be a requirement for any custom hardware or drivers. This should work on any windows endpoint, windows 7 and above which is probably having a Wi-Fi card which is windows compliant. So unlike when you create fake access points with Airbase NG, host APD which requires specific cards like the real tech chipset, Atheros chipset this will work out of the box on every windows endpoint including the Surface Pro. I've done a little test but it would work. Now I wanted that we should be able to detect honeypot creation tools automatically out of the box and actually have the world's first Wi-Fi only firewall with allow and deny rulesets which we can create, change and modify. So for version 1 this was our goal first to develop a better wireless scanner, something which can look at what is happening over the air, find very detailed information elements for the individual APs and correlate all of that together at the very same time something which can learn your good wireless networks. So let's say you connect to your home AP, could we learn how your home AP looks like so that when you're at the airport sending out a probe request for the same home AP and an attacker brings up a honeypot the tool actually tells you hey this isn't your home AP. Could we do the same for enterprise where you have a bunch of access points serving the same network. Now this is the overall architecture of the tool. Let's start from the absolute bottom. Now when we say we cannot use any custom device drivers we are dependent on the Wi-Fi subsystem on the endpoint. So we looked at all the different wireless APIs provided by windows and started enumerating state machine data. This is am I connected, am I authenticating, am I associated. The scan data roughly every minute windows automatically scans and looks at all the APs around. We picked that data up as well. Network profiles, preferred network lists consist of all the networks you've connected to previously and finally card control. The APIs are actually a bit involved. I spent around two to three weeks actually researching and looking at what the individual APIs give me. So let me actually run a quick demo of the tool to show you what kind of data sources are available. So I'm running on low resolution. Some of the things maybe kind of chopped off from the bottom. Jellum starts, the obligatory ninja comes in four different colors. So every time you started it will select a new color. There's actually a loading bar at the bottom but because we are in low resolution you can't see that. So as soon as Jellum starts it gives you an interface where you can start looking at all the networks around. Now Jellum runs in the background and waits for windows to tell it, hey, I've just finished a scan. Here are the results. So we have a call back from the wireless subsystem. We do not go ahead and do any form of aggressive scanning. Now moment we get that you see a ton of trace backs. Let me go ahead and suppress the alerts for a quick bit. Now if you notice at the top left we've already discovered 128 networks, right? And if I were to sort it, this will actually even give you hidden SSID ones. The ones which are probably showing up as the two bricks, that's basically me not dealing with certain character sets. That could be fixed. As an example if you look at alpha you can actually see all the different BSSIDs which are giving that out. Something which your wireless configurator doesn't tell you anything about, right? Just a list of SSIDs. Now it doesn't end here. You already see Jellum has found 171 networks and we can see a ton of details about these networks including the BSS type, the signal strength, rates, authentication, encryption and a couple of other interesting metrics, right? So this gives you an immediate snapshot of what is in the air. Now here is the other interesting thing which we do is using all the APIs I reconstruct how the beacon frame looks like. So I'm not sniffing the air but I can always query all of these dozens of wireless APIs and pick up different attributes about the network and reconstruct how the beacon frame looks like. So once I do that I can actually see different information elements and all of that stuff which previously wasn't possible. Now Jellum integrates closely with the Wi-Fi sub system and we monitor roughly 60 different events. So now when you get disconnected from an access point, someone deots you, Jellum actually tells you that you've been momentarily disconnected. Your windows operating system won't do that immediately. It'll try to aggressively reconnect. If the connection succeeds, it's completely happy, it doesn't worry about it. Jellum will show you all of these smaller transitions as well. So now let's go back. Jellum runs entirely in the background. You can even switch off your Wi-Fi network if you desire and it'll just run in the background here, right? We've tried our best to have a very small memory footprint at this time but of course this is very early software which we built. So I assume there would be bugs. Now once we've collected all of that incredible data which I just showed you, we push that into SQLite databases. So this may even allow you later to do simple SQL queries and look at what was around. So to begin with Jellum can actually be a very good Wi-Fi auditing tool just by walking around with it. It collects all the data, you can run the SQL queries. So I'll show you the SQLite in just a bit. Then we have the analysis and rule matching engine. This can look at different rulesets which we create and do interesting things with it. So let me give you an example. So here is my attacker machine. Going to switch on my wireless and let's go ahead and restart Jellum. Just going to start from a clean slate so that you see how the detection works. So what we've done is we have black lists as well as white lists in Jellum. Black list includes fingerprinting existing tools. Now I've been in wireless security, as I said, maybe over the last decade. Unfortunately tool authors haven't really gone ahead and worked much on their tools. Why? Because nothing like Jellum exists. How many of you create fake access points without even changing the MAC address? Like, right? How many of you even bother to look at what is in the beacon frame of maybe the network you're trying to emulate? No one does, right? Is this air base hyphen hyphen ESSID? And of course the Wi-Fi pineapple might actually automate all of that in the background. So Jellum is hopefully going to make all of you guys a little bit more alert. So what Jellum does is it can run in the background and let's say I start a monitor mode interface. So I'm going to create an air base fake AP. Now I'm just going to put in something completely random so that you know I'm not faking it. Now when this fake AP runs, every minute when Windows scans, Jellum actually looks at all of the data and looks into its black lists which actually you can write yourself. It's extensible. And then says, hey, this looks like a typical beacon from an attack tool, right? So give it a couple of seconds and you'll actually see Jellum figure it out unless people are aggressively de-aughting me right now. And there you go. If you notice, Jellum just detected air base NG out of the box. Don't I deserve a clap for that? And you could actually write your own signatures or create your own rules for the Wi-Fi pineapple for pretty much any attack tool which probably uses hard coded values. Now that's a black list. Unfortunately beyond the point, black lists aren't very useful, right? There's going to be a race between us and the tool authors. Okay, let's change this, let's change that. And this is where what we decided was to go ahead and also include white lists. Now keep in mind, even though we have killed the fake AP, you might see a couple of more pop-ups. The reason for that is Windows caches the scan results and gives it to the APIs. So if you call an API you are not necessarily running a life scan. So now if you go back, let's look at white listing. So we can go to Jellum, I can look at the list of networks which are around and I can find one which let's say is my home AP as an example. One of the things I forgot to mention is Jellum will actually show in red the fake access point like air base NG so that you know where it is or the other details about it. Okay, so here is an AP which I have set up. Now how do we fingerprint our access point using beacon frames? We made it very simple, just right click say create rule. Now you're taken to an interface which goes ahead and creates a pre-populated rule which you can use. So I can actually go in here and say my home AP, enable the rule by default and say this is my home AP. It's a white list, when do I test the rule? Two possibilities, when we are scanning the network at regular intervals, the second is when I'm actually connecting to a network, right? So I'm going to enable for both. Now we can choose from a ton of parameters which we've already figured out about our home AP. The first is the BSS ID. At the extreme right I have an option which says hey, can this value change? So if we tell Jellum that this value can change, it's going to ignore it. So I'm going to say no, the BSS ID is going to be constant for my home AP, it's never going to change. It's an infrastructure AP, the hardware type isn't changing and if it's on a fixed channel, that doesn't change as well. And at the bottom here we actually have a ton of other parameters, capability information, IE elements and all of that. You can decide how rigid or how flexible you want your rule to be, right? The power is in your hands. Now one of the other things we've actually added is neighboring networks. So how does that work? Now what we figured out, that if you're running an access point at your home, there are a couple of neighboring APs which are always around. So we tell you hey, would you want us to check that at least one or more of those APs are around, then next time you actually see your home network. An attacker can never know this at an airport. I mean he can't know a ton of other stuff as well, but this is something almost impossible to know. Unless he's actually walking back to your home, where I think you have bigger problems than wireless security. So Chelum allows you, if we go back, Chelum allows you to actually select from all of these neighboring networks. Now at this point, given the volatility of all the networks here, I'm not going to select that. And new elements, can new IEs be there? Typically once you set up an AP, that generally doesn't change. If you change the config, you could, you change the rule set then. Just like any other network IDS. So we say cannot be present, we go up here and then we create this rule. Rule created. Now Chelum is protecting you from connecting to any other open sesame, which has parameters different from what is in the rule set. So we can allow Chelum to run in the background. I can go back to my attacker machine. I won't use air base because you already have the detection for that built in. I'm going to use host APD, right? Kernel mode access point. And I already have the open config for that open sesame as an example. This could be a WPA, WPA2 PSK network as well. I mean the process is really just the same. The IEs would change. You would actually have vendor specific IEs which talk about a ton of RSN information and all that. So I'm just going to run host APD, open.conf. Now when we create a new access point open sesame, at this point this could be a regular hardware AP or a software AP, right? Chelum doesn't have the black list in it, but Chelum says hey, if I see an open sesame, I have to see at least these parameters in it. If I don't see that, this definitely isn't the one you're used to connecting to. And there you go, right? Chelum picked it up. It actually gets even better. As a security researcher, I wanted to actually see where the rule sets differ. So you can go to alerts. This part is buggy. I apologize if it crashes. And then you can click on view. Okay, worked. I wish I could take that statement back, right? The moment I say buggy. I would have looked way more cooler if it just worked. So on the right hand side, we can actually see that the network BS society did not match. Couple of things did. The center frequency didn't. Many of these which we haven't gone ahead and applied in the rule set are completely okay. We said it's okay if the neighboring networks change, right? So it's completely fine with it. If we scroll down, you'll actually see that a ton of things did not match in the capability information and in the IE's, right? So Chelum actually tells you that, hey, this access point opens his aim, looks completely different in so many ways from what you're used to connecting. Now, if we go back, just going to kill opens his aim, go back to the slides. We can actually extrapolate this even beyond 802.11. At the very top there, we have the entire 802.11 set. Let me actually close Chelum. So we are looking at a bunch of things in there, the IE's, the neighboring AP's, the AP details. Keep in mind we could learn all of these things recursively as well. So I could actually take some of my neighboring AP's and say, hey, typically this AP has a couple of these IE's, right? Which actually makes the solution even more robust. However, while I was working on it, I thought, okay, what about post-connect parameters? Which is, let's say, after you connect to a network, what you see on the network, for example, the DHCP IP address which you give, which you get, right? That also can be sometimes unique to your network. The gateway. Hey, you can actually go overboard and actually scan and do an OS and Nmap fingerprinting on the gateway and say every single time these are the ports which I see are open. Now, the lower part, the post-connect IP and above, isn't implemented in the tool yet. This is just a research thought which I had. So once you have a white list for your home network or your office network, Chelm also allows you to just right-click on an SSID and if it has multiple BSSIDs, it can put all of them together. However, keep in mind that that's only a good idea if all of your AP's are probably using the same controller so their characteristics are roughly the same. If not, you could, as an admin, create SSID, BSSID combination rule sets. Create a rules.db, and push it out to all the end clients. Now, how complex are Chelm's tables to allow us to do all of this? So when I started on this project and looked at the APIs, I underestimated how much time it would take to get a reliable solution. We actually use 43 different tables to track all of the data. Many of these tables can contain a ton of data in there. Let me see if I can. So every single thing that Chelm actually sees is something which goes in there. For example, all the scan results. In just the last 5 or 10 minutes that we ran the tool, because I started with a fresh copy of it, we already have 3,500 scan results taken at different times. So we collected all of this data, correlated them through different SQL queries, picked up what is interesting, and then the analysis and rule engine works on all of that. Can you tell me how much time I have left? 25 minutes? Okay. I'm going faster than I should. Tag demo. Why is this interesting or important, at least in my humble view? Till date, most wireless attack tools do not try to understand or try to mimic the authorized network. Once you use Chelm, the tools will find it extremely difficult to go ahead and create honey pots for any network you're sending out a probe request to if you have a white list on Chelm for it. Now, what happens if someone goes ahead and, as I said, he stalks you, manages to clone everything exactly, exceptionally difficult, right? But if he manages to clone everything exactly, is there something which can be done? How much time do I have? 15. Okay. Is it possible? So when I looked at it, what typically ends up happening is if the attacker clones every single thing in the beacon frame, including the MAC address, there are interesting beacon and host time stamps which are in the packets, which you can use to correlate and look at things like clock skews. There seem to be a ton of research papers on it on how you can figure that out. That isn't implemented in the current version, but we will probably do that very soon. Roadmap for enhancements. Now, you're probably thinking, okay, we just found a vulnerable network, sorry, an attack network to which we could connect to. What do we do about it now? I mean, is Chelm going to stop me from connecting to it immediately? Well, if we figured out that this is an attack network when we were scanning, Chelm will actually try to disconnect you from the network as soon as you try to connect. However, in version one, we are picking up everything from the wireless subsystem, right? So it happens and then we know. So what I'm already working on is version two, which should be out maybe in the next three or four months, which actually has an intermediate driver sitting about the mini port just below the protocol edge. And we are going to be looking at every single packet going up and down the Wi-Fi stack. Now, the solution is exactly similar to how your wired-site firewalls work. They have a kernel mode component. The kernel mode component is aware of the rule sets and anything which does not match the rule set is discarded at the intermediate driver itself, filter drivers, right? That's what they used to call it in the olden days. The preferred way of writing that right now, according to Microsoft, is call-out drivers. So we could have a filter or a call-out which sits there the moment it sees an open sysame or your home AP showing up, which is different from what it is used to. It'll immediately go ahead and discard it so that Windows doesn't even see it, right? And we could have a very simple alert which says, okay, you know, a rogue AP or something was found. The other thing which we wanted to do is assisted and automatic learning. Now, for a technical audience, we're going to be releasing cell phone tonight. You can download it. It's a complete free tool. Use it as you please. You can, you know, file bugs. Let us know what more you need. But what about, you know, my mother or my dad? So we're already building a feature where it could actually do some kind of automated learning, right? Just an idea at this point. You can actually write your own plugins where we are trying to see if we can actually use things like Python or Ruby to write your own plugins for cell phone. And that's the reason we actually chose the core of cell phone, all the data collection, all the analysis and all of that to be SQLite so that you can actually write your own plugins which can pick up stuff from some of the tables, work on that, push on other tables. And we can call you as a callback when different events happen on the system. cell phone will be available at the URL pentesteracademy.com slash cell phone. The link will be active by tonight. I tried to connect with an open VPN, but I don't know why at Defcon I just get, you know, getting disconnected. Now, why did I call that cell phone? Well, you know, this isn't a fancy name, you know, in Hindi or any other language for hacker or hacker tool. Chellum is my grandmother's name who taught me mathematics and English, so this is my dedication to her. Thanks. Thank you. We have time for questions? Okay, we have time for a couple of questions if anyone has. Okay, that's a very good question. As you notice, all the core principles, okay, his question was, what about creating something like this for Android? We're already working on it. If you notice, the exact principles actually apply pretty much to any operating system, right? On Linux's and many other OS's, it's actually much easier to get data on beacon frames and things like that. So probably in the next three to four months you should see an Android version. iOS, maybe never. Simply because Apple is super restrictive about what we can and cannot do. So unless, you know, maybe for this audience where everyone might have a jailbroken iPhone where then we could run our own little programs to do monitoring, I don't see any other way to do that. Was that? It's completely free. You can just download and use it. So right now the GUI isn't, couple of the other components are, once we freeze the GUI, that will be as well so you can download and use it and modify it. Okay, what language is this written? The core of Chellum is actually written in CC++. The GUI which you see is actually WPF in C-sharp, right? Okay, thank you very much.