Good afternoon, everyone.  Thank you 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.  This has been a team, and was responsible for most of the testing.  
A little about me.  I started as a programmer than as an architect.  I found a bunch of virus attacks the caffe latte attack, after that went full time.  I run security tube training and Pentester academy.  Written a bunch of books on wireless security and we also have our very first self-published book.  How to build your even own wi-fi from scratch.  
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 have always been doing attacks.  I found my own attacks, talked about them, demonstrated them to my customers and that is fun.  We all love attacks.  But what about defense?  So every single time I create a honeypot and the clients connect to it, 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 is not the authorized access point that it should be connecting to.  
It 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 -- some infrastructure windows are trying as far at roaming clients are concerned, at this point generally it's policy based.  You can switch off your bluetooth, your wi-fi, once you're out of the enterprise, unfortunately nothing is intelligent enough to detect things like actual wi-fi attacks.  
Why is this so complicated to solve?  Well, you have tablets, phones, 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.  Without your own custom on Windows you can't do anything.  
So when I started off I decided let's look at attack surface so we can narrow the problem down.  Now, most wi-fi clients now most people actually think honeypots are restricted to open networks.  These request packets are searching for different SSIDs which the client has in its preferred network list.  
At that point the attacker creates different honeypots and the client may be lured to connect to one or more of those honey pots.  When that happens the hacker can give a different IP address.  This is you how typically pretty much every device out there works in having clients connect to it.  
Is the captioning working okay?  
I'm sure a lot of the stuff must be fun to read.  I don't know if it can pick up everything I say with my accent.  It will be fun.  
(Laughter.)
At least you'll have fun either way.  
So one of the different ways by which clients can be attacked, so as I said, AP less cracking is what happens in the wild.  When there is no encryption, that's of course easy.  You have WEP, PSK, and you all of that.  And there are different techniques or AP less cracking which include the caffe latte and a bunch of others.  You could be attacked pretty much anywhere and once someone goes ahead and hijacks your wi-fi, he basically owns your lair too.  
So when we begun researching on this, I decided to define the scope first.  To create something that should work across all operating systems if day one, is always difficult to solve.  So windows end points.  In version one, the biggest stipulation which I added is 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 which is Windows compliant.  Unlike when you create fake access points which require specific cards like the Rio tech chip set, this will work out of the box on every Windows endpoint, including the surface pro.  I've done a little test, and it will work.  
Now, I wanted that we should be able to detect honey pot creation tools automatically out of the box, and actually have the world's first only firewall with the only denying vets which we can create, change and modify.  
So for version one, this was our goal.  First to develop a wireless -- 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 IP.  Can we learn how your home AP looks like so when you're at an airport sending out a probe request, and an attacker brings up a honey pot the tool tells you this isn't your home AP, right?  Could we do the same for enterprise where you have a bunch of access points serving the same network.  
Now, this is a 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.  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 pick 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 spend 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.  
Some of the things maybe show from the bottom.  Comes in four different colors.  So every time you start to select a new color.  There's actually a loading bar at the bottom but because we are on low resolution, you can't see that.  
So as soon as Chellam starts, it gives you an interface where you can start looking at all the networks around.  
Now, Chellam 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.  
The moment we get back, you see a ton of -- let me suppress the alerts.  At the top left we've already discovered 128 networks.  
(Laughter.)
Right?  And if I were to sort it, this will actually give you here in the society 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.  If you look at alpha you can see all the different BSSIDs that are giving it out.  Something that are wireless configurators doesn't tell you anything.  Just a list.  
You already see Chellam has found 171 networks and we can see a ton of details about these networks.  So this gives you an immediate snapshot.  
Here is the another thing.  I'm not sniffing the air but I can always query the 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 was impossible.  
Now Chellam integrates closely with the we if a subsystem.  Now Chellam tells you you've been momentarily disconnected.  It will try to aggressively reconnect.  If the connection succeeds, it's completely happy.  It doesn't worry about it.  Chellam will show you all of these smaller transitions as well.  
Chellam runs entirely in the background.  You can switch off your wi-fi network if you desire and it will run in the background here.  We have tried our best to have a very small memory this time, but of course this is very early software so I assume there will be bugs.  
Now once we've collected all of that incredible data which I just showed you, we push that into SQL databases.  So this may allow you later to do simple SQL queries and look at what was around.  To begin with Chellam can be an auditing wi-fi tool.  
Then we have the analysis and rule matching engine.  This can look at different rule sets which we create and do interesting things with it.  So let me give you an example.  
Here is my attacker machine.  
Let's start Chellam from a clean slate so you see how it works.  So what we've done is -- and you could write your own signatures and create your own rules.  
That's a black list.  Unfortunately, beyond the point, black lists aren't very useful.  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 more pop-ups.  The reason for that is Windows catches the scanned 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 Chellam.  I can look at the list of networks which are around.  And I can find one which let's say is my home AP is an example.  One of the things I forget to mention, Chellam will show in red the fake access point so you know where it is so the other details about it.  Here is an AP which we have set up.  How do we fingerprint the access point using beacon frames?  We made it really simple.  Just right click.  You're taken to an interface which goes ahead and creates a prepopulated rule which you can use.  So I can go in here and say my home AP enabled 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 already figured out about our home AP.  The first is the BSSID.  At the extreme right I have an option that says hey, can this value change.  So if we tell Chellam that this value can change, it's going to ignore it.  So I'm going to say no, it's never going to change, it's an infrastructure AP, the hardware type is not 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 and formation, IE elements and all of that.  You can decide how rigid or how flexible you want your rule to be.  Right?  The power is your hands.  
Now, one of the other things we have 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 the next time you actually see your home network.  An attacker could 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.  
(Laughter.)
(Applause.)
So Chellam 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 start up an IE, it doesn't change.  If you change the configure, you could change the rule set then.  So we say cannot be present.  So we go up here and create this rule.  Rule created.  Now Chellam is protecting you from connecting to any other open system which has parameters different from what is in the rule set.  So we can allow Chellam to run in the background.  I can go back to my attacker machine.  I won't use air base because we already have the detection for that built this.  I'm going to use host APD, kernel mode access point.  And I already have the open config for that.  This could be a WEP the process is really the same.  The IEs will change.  You have window specific IEs.  So I'm going to run host.  Now when we create a new access point open system.  At this point it will be a regular AP or a software AP, right?  Chellam doesn't have the black list in it, but Chellam says if I see an open system, I have to see these parameters in it.  If I don't see it, this isn't the one you're used to connecting to.  And there you go, Chellam picked it up.  
(Applause.)
It actually gets even better.  As a security researchers 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, it worked.  
(Laughter.)
I wish I could take that statement back.  The moment I say buggy.  I would have looked way more cooler if it just worked.  
So on the right-hand side you can actually see that the network BSSID did not match.  A 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 we see that a ton of things did not match in the capability and the formation IEs.  So Chellam actually tells you that hey, this access point opens the same.  It looks completely different in so many ways from what you're used to connecting.  
Now if we go back, we can actually extrapolate this.  At the very top there we have the entire 802.11 set.  Let me close Chellam.  So we are looking at a bunch of things in there the EIs, the neighboring APs, the AP details.  Keep in mind we could learn all of these things repulsively as well.  Typically this AP has a couple of these IEs, 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 address which you get, that also can be sometimes unique to your network.  The gateway.  Hey, you can actually go overboard and scan and do an OSN map fingerprinting on the gate way and say every time these are the ports which I see are open.  The lower part 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, Chellam allows you to click on SSID and if it has multiple BSSIDs, it can keep them all together.  Keep in mind that's only a good idea if all of your APs are using the same controller so the characteristics are roughly the same.  If not you can as an admin create combination rule sets and push it out to all the end clients.  
Now how complex are Chellam's tables to allow us to do all 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.  So every single thing that Chellam actually sees is something which goes in there.  For example, all the scanned results, right?  In just the last five or ten minutes that we ran the tool, because I started with a fresh copy of it, you already have 3,500 scan results taken at different times.  So we collected all of this data, co-related them -- correlated them through different queries, picked up what was 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?  I'm going faster than I should.  
Why is this interesting or important, at least in my humble view?  
To date most wireless attack tools do not try to understand or try to mimic the authorized network.  Once you use Chellam, the tools you'll find it extremely difficult to go ahead and create honey pots for any network you're sounding out a probe request to if you have a white list on Chellam 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 package which you can use to correlate and look at things.  There seems 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 soon.  
Road map for enhancements.  Now, you're probably thinking okay, we just found a wonderful -- an attack network which we could connect to.  What do we do about it now?  I mean is Chellam going to stop me from connecting to it immediately?  Well, if you figure out this is an attack network when we were scanning, Chellam will actually try to disconnect you from the network as soon as you try to connect.  However, in version 1 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 2, 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're going to be looking at every single packet going up and down the wi-fi stack.  
The solution is exactly similar to how your fire walls work.  They have a kernel component and anything that does not match the rule set is discarded at the intermediate driver itself.  Filter drivers.  The preferred way of writing that right now is collar drivers.  We could have a filter or a call out.  The moment it sees your system showing up from what it is used to, it will immediately go ahead and discard it so that Windows doesn't even see it and we could have a very simple alert that says a rogue AP or something was found.  
The other thing if you wanted to do is assist an automatic learning.  For a technical audience, we're going to be releasing Chellam tonight, you can download it, it's a complete free tool, use it as you please.  If you find bugs, let us know what more you need.  What about, my mother or my dad.  So we're already building a feature where it could actually do some kind of automated learning.  Just an idea at this point.  You can actually write your own plug-ins where we are trying to see if you can actually use things to write your own plug-ins for Chellam and that's the reason we actually chose the code of Chellam, all the data collection, all the analysis and all that to be SQL like so you can write your own plug-ins which can pick up stuff from some of the tables, work on that and push the other tables.  And we can call you as a call-back when different events happen on the system.  
Chellam will be available at the URL Pentester academy.  The link will be open by tonight.  At Def Con I kept getting disconnected.  
Now, why did I call that Chellam?  Well, you know, this isn't a fancy name in Hindi or any other language.  Chellam is my grandmother's name who taught me mathematics and English so this is my dedication to her.  
(Applause.)
Thank you.  Do we have time for questions.  We have time for a couple of questions if anyone has.  
>> All the core principles -- his question was what about creating something like this for Android.  We are working on it.  If you notice the exact principles actually apply pretty much to any operating system, right?  On Linux's and many other iOSs it's easier to get data on beacon frames like that.  So you should see an Android version.  IOS, maybe never.  
(Laughter.)
Simply because Apple is super restrictive about what we can and cannot do.  So maybe for this audience wherever one might have a jail broken iPhone where we can run our own little programs to do monitoring, I don't see any other way to do that 
>> It's completely free and you can just download and use it.  
So right now the Gui is in, a couple of other components are, you can download and use it and modify it.  
What language is this written?  The code of Chellam is actually written in C++.  The GUI which you see is WPF in C sharp.  Right?  
Thank you very much.  
(Applause.)