 Today, we'll be looking at WPA Enterprise Hacking, basically creating honey pots for WPA-WPA2 PSK networks. Before we begin, just a quick introduction about us. I started as a programmer and an architect, worked with Cisco Systems, found a bunch of Wi-Fi attacks. I run security tube.net and Pentester Academy, written a bunch of books, and we're actually releasing a new book by the Defconn vendor booth called Make Your Own Hacker Gadget. Probably giving out a couple of these for free based on questions I ask and who can answer it. Hi, I'm Thomas. You probably already know me by the nickname Mr. X. I'm the guy behind aircrackNG. Also, I have a project. Unfortunately, I haven't had much time to work on it, which is open-webs, open-source wireless IPS. I created the off-sec waifu, which is already known these days as wireless attacks. I spoke at a bunch of conventions in the U.S., in Mexico, in Badgem. I work for a company called Minder. We are actually doing a lot of talks at Black Hat and Defconn combined. Today at 3 o'clock, I'm also doing a Wi-Fi IDS talk for Windows called Chellum. I'll actually use Chellum and see how you can do a little bit of protection today. Tomorrow, a network-based IDS, which actually uses SQL at its center to go ahead and run arbitrary queries. That's something we are doing tomorrow. And also, another village talk here of how you can script your own Wi-Fi attack tools in Python using WPA supplicants, WPA control, and D-Bus API. I don't know if anybody's ever used it. Okay, it's quite powerful for automation. And we also have a booth in the vendor area. So just go directly to the slides for WPA enterprise. Okay. At a very high level, when you look at WPA enterprise, there are three entities, right? One, you have the client or the supplicant, which is providing authentication information. Then you have the access point, which is basically just an in-between proxy for all practical purposes. And you also have the authentication server, which is typically radius, which in turn can probably talk to LDAP or something else to go ahead and authenticate the user based on the EAP mechanism being used. The most popular radius server is FreeRadius. Any of you have used FreeRadius for this? Okay. Couple of guys. Which supports a ton of EAP techniques. Now, FreeRadius, unfortunately, is a very well-behaved radius server, right? It's actually used in enterprises. It has a very legitimate use for that matter. Now, when we go ahead and want to use it for our purposes and create honeypots, we would have to patch the FreeRadius server. And that patch, which is available right now, is called the Wireless Ponage Edition, right, from Joshua Wright. Now, what does this patch actually do? Very simply put, it actually logs things like the MSChap v2 challenge responses and a lot of other inner authentication, which goes in the tunnel, which we create, right? So that we can pick these inner details, and then we can go and start cracking them. Now, if we look at WPA and WPA2 Enterprise, we have PEEP, TTLS, TLS, a bunch of others, some of which might not be used anymore. Why is PEEP so popular? PEEP is the only EAP mechanism which Windows supports out of the box, right? That kind of made it de facto, the one with the highest amount of usage. So, let's try and understand PEEP at a very high level. The best analogy which I can use is SSL. How many of you here know how SSL works at a very high level? You know, not the crypto protocols and all of that, okay? So, I'll just go ahead and repeat some of the essential aspects of SSL. We create an encrypted tunnel, and within that encrypted tunnel, we send data, right, which otherwise would have gone in plain text. Now, in the case of PEEP, the exact same process is followed. Phase one is creating the encrypted tunnel. In PEEP, this also happens using server side certificates just like in SSL. So, once the tunnel is created using the server side certificate, which in the case of PEEP is the radius server, we go ahead and send the inner authentication credentials, right? In the case of PEEP, the de facto inner auth is MSChap V2, simple challenge response protocol. MSChap V2 itself is known to be broken 100%. I think two or three years back, Moxie did a talk as well where I think they'd use GPU infrastructures and a couple of things to go ahead and prove that you can crack it 100% of the times. So, if you're thinking why MSChap V2 is being used, well, the whole security here is maintained by ensuring the integrity of the tunnel itself, just like SSL. So, if you're logging into Gmail or Google, the same username and password goes through, but it goes inside the encrypted SSL tunnel. If someone compromised that encrypted SSL tunnel by doing an MITM attack or an SSL strip attack, then of course the username password or whatever gets sent inside the tunnel is also going to be available in plain text for the attacker doing the MITM. The exact same principle applies when we create MITM setups for WPA enterprise. Now, if you look at clients, in the case of Wi-Fi, you actually see very heterogeneous behavior in what a client does or what is the default configuration of that client. So, when you get an SSL pop-up, right, says there is a certificate issue, how many of you have at least clicked okay once in your lifetime? A couple of guys, okay. Never, never. Never? Okay. Now, keep in mind if you say never, that actually means you cannot log into your own security appliances because all of them use self-signed certificates. Right? Quite unusual, but pretty much all your firewalls, IDSs, anything you're running locally has self-signed certs, so you must have at least clicked once, unless of course you've never used one of those devices. Unencrypted. Unencrypted. Okay. So, when we look at Wi-Fi clients, there are broadly three different behaviors which can happen, right? Behavior one, the client has a very strict configuration and the configuration enforces that if there is any certificate mismatch of any kind, silently drop the connection, do not prompt the user to accept new certificates which might kind of go ahead and lead to, once again, the SSL MITM happening. That's possibility one. The second possibility is clients are misconfigured. This is something you'll actually find out of the box on most Android devices. How many of you have Android phones on you right now? Okay. Very, very notorious to actually have super bad configs out of the box for enterprise, right? The simple reason is your Android vendor is not interested in maintaining the software and keeping things up to date. They just want the very first time you connect to a wireless network, whether that is open or has peep, you should probably just connect to it immediately. If your connection breaks the very first time, you might actually think there's something wrong with your device, right? So, make it kind of fail open out of the box. And we'll see that in the demo once we do it. How many of you have laptops here to kind of do the demos along with us in the second part? Okay. Okay. Perfect. So, we have a bunch of access points. People who don't have, you can even share with guys who have, but we'll actually cover everything conceptually in the first half. So, folks who don't have a laptop can probably find something else interesting to look at. The third Wi-Fi client behavior is typically what you see in the case of the browser world, right? We get a pop up. So, the client actually tells you that, hey, there is a certificate problem. Do you want to accept this? Go ahead with this, right? One of three possibilities. It depends on the version as an example of Android. It depends on devices and operating systems. For example, iOS has a completely different interesting behavior, which you shall see. And your endpoints and what they're configured for. Okay. So, how does SSL, man in the middle, attack work? Now, let's assume that I'm the attacker. Gmail is the server the client is trying to access. Probably, I mean, Thomas is the author of Aircrack. I can't point to him and say he's the vulnerable client, right? So, you know, okay. So, he's the vulnerable client. I'm the attacker creating the MITM setup and then you have Gmail. So, when Thomas tries to access Gmail in a typical SSL MITM, I send my own self-signed fake certificate to Thomas, right? Assuming Thomas clicks okay, or the client goes ahead and accepts the certificate because it's misconfigured, the encrypted tunnel between Thomas and me happens using my certificate. Now, of course, Gmail isn't going to accept that same encrypted data. So, I'm going to create an encrypted tunnel between me, the attacker, and Gmail using Gmail's certificate, right? So, in an SSL MITM, there are really two separate encrypted tunnels. One between the attacker and the victim, and the other between the attacker and the final destination server, right? The attacker encrypts decrypts, puts it here, again encrypts it, sends it to Gmail, and all the data flows back and forth. When we create a honeypot for a P-based network, the principle is exactly the same. I as an attacker, I'm going to go ahead, spin up my VM, advertise a network with the same SSID as that of your enterprise. At the back end, I'm going to be running my own fake radius server, which has its own self-signed certificate. So, let's say Thomas now sends out probe requests, and I create a honeypot with the exact same name at an airport or any other location, and Thomas connects to my setup. Now, P typically is network logon. So, Thomas, if this is the first time he's connecting, which wouldn't be the case because he's sending probe requests, most clients automatically try to do a connection, right? They might not even prompt you. During the demos you do, well, you will be prompted because the network isn't there in your preferred network list yet, right? This is your first connection. So, when Thomas connects to me, at that point, a fake certificate would be sent to him. Now, everything depends on how his wireless client software behaves, right? Possibility one, silently accepts. Android devices do that, and you'll see that during the demo. Possibility two, the device goes ahead and shows him a certificate mismatch, and he may have to accept it, right? iOS devices would do that. Possibility three, a very strong policy where the device automatically rejects very few devices, some which have been configured, typically after our Black Hat classes. So, here's what I'm going to do. I'm going to create the setup. Just start to give me a minute or two, and I'll show you how it works. Okay. Do you guys have any questions so far? So, the question was, why are you a machine? Yes, it could be a physical machine, too. Just convenient, we have the slides on one machine, and we need a Linux machine to do that. Is there anybody that could explain the Cafe Latte attack? So, there's a book for the person who can answer that. So, you're going to ask some questions about different wireless attacks while I'm setting it up, and you can answer it. Can somebody describe the Cafe Latte attack? Okay. How does Cafe Latte, I'll be very, very specific. How does Cafe Latte go ahead? So, Cafe Latte is AP less web cracking, right? One of the very first attacks, which I found. And Cafe Latte does something very, very interesting with the initial R packets, which comes in. So, what does it exactly do? The other alternate questions are, how does the Corek attack work? Anyone heard of the Corek attack? Okay. Or the Chop Chop attack? Okay. Does anyone want to explain how WPA PSK cracking works? Okay. There you go. So, I'll give this a shot. Basically, when you're connecting to a wireless router, you have to send your information about who you are, and what your physical device is, so that you can establish this connection with the server. And there's a four-way handshake that occurs where you're sending information to the router. It sends information back. You send more information to the router, and finally, it sends more information back. And in the process of that four-way handshake, one of the things that's being transferred is the hash of the WPA access point, you know, the passphrase or whatever authentication it's using, so you can extract that hash from the packets and then use it to brute force the password. Yeah. Very good. Crack WPA PSK without an access point being around, which is AP less WPA WPA2 PSK cracking. How do you create such a setup and how would that work? Anybody? Yeah. How do we deal with that when we don't have the access point around? Yes. You're on the right track. Crack. There are tools too. Yeah. There's a tool in there crack that can do. Ehrman is just for creating or stopping monitor mode interfaces. Yeah. That's one answer. There's another tool in there crack. Yep. Okay. So, managed to get the setup ready. The very first thing which we're going to create is the fake access point, right, which has the same SSID as the enterprise AP. So, here is what we are trying to do. Create an enterprise access point with the same SSID as yours. When the client connects to it, our fake AP will talk to the radius server which we've set up with the self-signed certificate. As soon as the connection happens, the self-signed cert is sent to the client. The client now has a choice, as I said, one of those three. Assuming it accepts the encrypted tunnel which gets created is with the fake radius server certificate, just like SSL man in the middle attack. Once that happens, the MSChap V2 challenge response pair inside gets sent and we can easily cache it. So, I'll go through the whole process. The first step is actually to create the host APD config. Host APD is a good choice because it can work with EPOL packets, right. That is a requirement for any software based access point. All hardware APs can do that, right. So, here is the WPA enterprise configuration for host APD. We have the interface. We have the hardware mode, the channel, the driver, SSID. WPA enterprise is always open authentication. You selected WPA2 and key management is going to be EAP and we are using CCMP so that it's WPA2 enterprise. 802.1x is set to ON. I am running the radius server on the same machine, right, so that I can actually use the loopback interface and my access point using host APD is actually going to be on my client card. So, this is a TP-Link WN722N. It's a fantastic card, has an athros based chipset. Highly recommend purchasing one. When we checked during our black hat class, it was retailing at $12 on Amazon. Probably want to buy 10 of them. They run out of stock very fast and it's difficult to get your hands on them. I mean, we did a class of 40, 50 people and took quite some time to actually get that many cards. So, highly recommend buying one. TP-Link WN722N. 722N. Okay. Okay, so I am going to go ahead and start the fake access point and then I am going to start the radius server and now I am actually going to go ahead and connect my client to it. I know most of you already have your alpha cards out to de-auth the AP. Just give me a couple of minutes and then you can de-auth as much as you like. So, as soon as I try to connect, it shows me a username and password prompt. It realizes it's WPA Enterprise. I am going to just put in, let's say, Vivek demo 1, 2, 3, hit join. Now, on iOS devices, this actually shows me a certificate, right? At this point, this is the default bootstrap certificate. So, looks completely easy to detect. It says example cert, but we could actually change it to something which looks more legitimate. Once we accept the cert, of course, we get an incorrect username and password, but if we go back and look at the log files, just started this. Here we go, right? Let me go ahead and do this once again. There you go, right? Here is something you can try. Using your own mobile devices, try connecting to this network and see if you actually get a certificate error. Don't worry, no malware will be served, right? I'm sorry, yeah. The SSID of the network is hyphen ENT demos. The de-auth guys in the room, just a couple of more seconds and then you can play with it. And everyone who's trying, try not to be too profane about what you put in as the username, right? We all understand we should be hacked, but, yeah. There go. I hope you're a woman writing this. That's better. Well, I'd agree to that, as I said, only if you're a woman. People who are trying, how many of you got a certificate error, an actual certificate error? I have a device? Okay. Androids, anyone tried with androids? Did not get a certificate error, right? There you go. Now, if this was your enterprise network, an actual enterprise network configured, your device would just automatically connect to it without you even knowing when you're in the proximity of it, right? And androids are very, very notorious for this. It's unbelievable. I get to do this demo almost for the last three years now, right? Nothing much has changed. Now, can you go ahead and fix this on Android? Yes, you can. Deep down in the settings, you have to figure out the place which says validate certificate, right? If you manage to figure that out where it is, depending on the version of Android, hey, you are protected. To begin with, there are a couple of other interesting hacks which we can do as well, which I'll just show you in a bit. People who are trying, anyone else Android device or any other devices, the Windows phone, anyone with a Windows phone? Okay, that shows market share. Yeah, Windows is the good thing about Windows to some extent now is because the entire Wi-Fi stack and the security has evolved along with the OS itself. Most of what you see on the phone is just that getting ported. So, androids are bad, really bad. Now, for people using iOS devices, there isn't much to celebrate immediately, right? This is a tech audience. The certificate name is a dead giveaway, example cert. But how many non-technical folks in a company, when we can actually make the certificate look extremely legit, would go ahead and not click okay to that, right? If we actually said, okay, this is ABC Corp, you know, put in all the details as well, all iOS also says is, hey, do you want to go ahead and accept this certificate? iOS isn't specifically warning you what can happen if you do it, right? So, it's great, at least that it does it to begin with, but hey, there are no warnings. It just says this is a new certificate. You want to accept it. Now, the problem is if you accept it, it's cast forever. Why? Because on iOS, the only time you can remove a network is when you're in its vicinity. Do you notice that? You can never remove preferred networks on iOS devices. Unless you jailbreak it, find the right SQL IDB where all of that is stored and actually run a SQL delete command for all rows. Okay. I haven't checked with that. Just let me know. I have my email at the end, so if the reset networking does that. Yeah. Yes. Yes. So, all of your cached passwords and things like that, including of course, the wireless ones, are all in the keychain. I think the file name was keychain-2.db or something. The last time I kind of jailbroken had a look at it. Yeah. It's just an encrypted SQL IDB, but you can decrypt it very easily using the machine key which is there on the iOS device. So, once you jailbreak it, you can recover it. Question. When you connect to the network and use a username and password, does it silently fail? Okay. So, that is an example of probably a strong policy just like Chrome does for its browser. So, great. Yeah. That's fantastic. Okay. Wow. So, yeah. It's still there. Because I mean, I think maybe logically what happens is you accept a certificate that probably goes elsewhere on a system-wide certificate database or system-wide certificate bank rather than being stored as part of the config of the network profile. So, that could probably be a logical assumption as to why resetting networking isn't solving the problem. Right? How many of you have tried and not gotten certificate errors? Okay. Android device is notorious. You can actually change it if you go deep down in the setting somewhere, but it's quite painful to do that. Now, what is the biggest worry with WPA Enterprise? In the case when you are actually cracking WPA to PSK, what you are getting is at most the network key which the admin can change or make it very, very extremely difficult to actually crack. In the case of Enterprise, if you do a parking lot attack or probably roam around in the nearest coffee shop near the Enterprise, assuming they have a couple of Android devices on their employees, this is something quite easy to pick up. Keep in mind that all you needed was a quick exchange. This doesn't require unlike something like Web for thousands of different packets to pass by, right? This whole exchange is probably under 60 packets, 50 to 60 packets. At the very same time, the interesting part is once you crack the challenge response spare, I'll show you what tools are available and online. There are even infrastructures which you can use. What do you finally get? You actually get the user's credentials. The user name actually goes in plain text in the EAP packet itself. So if you actually just ran wire shark and put a filter on EAP logon, you would be able to harvest user names on an Enterprise network anyway. This has nothing to do with it going inside the encrypted tunnel. It's also available outside. So you can just run a scanner near an Enterprise and do username harvesting. Once you get the password, what you can actually do is log on on that network as that user because anyone using PEEP actually has network logon associated with it, right? The radius server talks to the LDAP and just logs you on as the current user. What that means is once you do that, you have access to common shared file systems. The best way from here to go to root is most companies actually also have web mail and because they have single sign on available, you can actually just find the web mail URL and log into his email using the same username and password. And then if you have one of those interesting little PDF attacks where you can package in some goodies, you could actually send an internal email to all of his colleagues. The email system won't reject it because it isn't fake email, right? It's actually legitimate email from one to the other. So this could be a very good starting point for, now this is when everybody appreciates the talk and APT, right? Advanced Persistent Threat. So a very easy illustration of how you can move from just Wi-Fi to network credentials and then trying to see how many more users you can attack on the Enterprise network, right? Questions? Questions? It's just MSChap V2. So MSChap V2 is well documented of how the challenge response pairs are created. You can probably dig up some documentation and share it with you. Now MSChap V2 itself is known to be broken. Previously, we used to use AS Leap to run a dictionary attack on it, which is what I can show you right now. But I think three years back Moxie and David Hulton, right? Moxie and David Hulton, they did a talk where how you can actually crack MSChap V2 using a cloud or a GPU infrastructure 100% of the times. It's a DEF CON talk. You can see it. I think they even released some sample code along with it. And they have a website called cloudcracking.com or something where cloudcracker.com where you can pay $17 and save yourself a lot of time, right? I mean, in case you're doing a pen test upon a per hash basis. Okay. So how do you protect against this? All of this is going to be even more worrisome as the internet of things and all of that comes in and everything uses Wi-Fi, right? IoT devices almost always use Wi-Fi as the way to connect to the internet. Some of them use 3G networks as well, but most of them. Okay. So let's actually go ahead and look at the secure configuration. Depending on your client device, you have to validate certificate. You have to make it idiot proof, right? Do not prompt user to authorize new servers or trusted CAs. Unbelievably, Microsoft has this, right? They have it in their config, which you can turn on, right? So that's how you secure it. No, that isn't the default state. But is this secure? I mean, you just took my word for it. This is actually more insecure than the last one. And the interesting thing is that when we used to do a lot of audits, the only thing I did when I had to do WP Enterprise auditing was just have them open up this setting, right? And the moment I see this, well, it's game over already. And now I can actually do a whole network wide attack without even having to worry about a certificate pop up, right? Yeah. Okay. So if you look at the entire attack which we discussed, we said the problem is certificate validation probably isn't turned on by default on most client devices, right? So here is a config where certificate validation is turned on. We've kind of made it, you know, kind of user proof, which is do not prompt the user to authorize new servers, which means there are going to be no pop ups, asking the user to accept a new certificate from a network. So this is fantastic. And actually many networks have exactly this. But this is way more easier to beat than the previous case. And if I see this, it's like game over already. Of course, I build the client still for seven days, right? Roam around, you know, with my interns, trying to look all stressed out. When all we're actually doing is playing a game against each other, right? A video game. And that's the reason why we're stressed out. And then after seven days, we come back and here you go. This was difficult. No, no, no, we never do that in case you're probably thinking of hiring us. So anyone, this goes out one book. Why is this insecure? Yeah. Okay, but how would I find the legitimate cert? I mean, in the sense, how would I know what is a legitimate cert for the enterprise? Okay. Okay, very good. So one off, here you go. Clap. So one of the things you probably noticed is the admin forgot to add connect to these servers and there are no domain names mentioned here. So all that means is you need a valid certificate from one of these CAs, right? What is an example? On most of your Windows systems, you actually find a couple of dozen CAs and you can purchase a certificate from any one of them. Use it in your radius server and now that is a valid certificate, right? For the chain of trust which you have. So this is a very common mistake in enterprises. Now the best part is once your fake AP and radius server uses a valid cert, all your devices would happily connect. I mean, because we are playing by the rules now, right? Easiest case and this configuration, super easy to abuse. Unfortunately, nobody wants to go through the pain of setting up PKI and all of that locally, right? And even people who do are always worried of what they could break. So they don't try to really constrain it by the FQDNs and domain names and all of that. You actually need a very good experienced PKI team to get all of this right and not many enterprises invest in that. Of course, some of them have secure configs and this is something you can check in your enterprise to begin with. How many of you use WPA Enterprise, PEEP, TTLS, okay? You can check on your laptops or on your devices, right? On Windows 10, I still haven't opened this up and checked it yet. The only way is Microsoft would have to go ahead and prompt you at this point when you click okay that you've forgotten to mention, you know, which domain names for this, for which this should be valid, right? That's the only way. So now that we've looked at the attack part of it, and I'll show you the ASleep part later because that part is quite insignificant to do. It's just a command line tool. How do you protect against such attacks? How can you protect yourself from someone who just created a fake AP with the same SSID? Okay, so that is really where, just give you a sneak preview of the antidote. I created Chellum, which is my DEF CON main stage talk today at three o'clock. So in case you get interested, but I'll show you how many of these can be mitigated using a Wi-Fi firewall locally. So Chellum, at least in my humble view, is the world's first pure Wi-Fi firewall ideas for Windows endpoints. You can extrapolate the same concept to any operating system. We're already working on a Linux version of it, but Windows is actually more difficult to work on simply because it is quite restrictive of what you can get from the different APIs. Also, the only way in Windows now that you can go ahead and do really good quality sniffing and packet monitoring if you write your own call-out intermediate drivers, something which we are working on for version two. So let me run Chellum. It starts with a cool-looking Ninja. The Ninja changes color. I have four different colors. You can go around it every time it starts. How does Chellum work? It actually reconstructs how the access point beacon would look like using different Windows APIs. So we look at the Wi-Fi subsystem in Windows and pull out a ton of data from that. And then I reconstruct how a beacon frame would look like. Once I do that, we can actually see the AP's beacon frame and try to see what we can fingerprint. Now, Chellum has out-of-the-box detection for attack networks for some of them fingerprinted. I think actually someone is running AirwaysNG with an SSID default. Anyone here? Okay, it's actually picked it up. Come to how that does it a little later. Here is another as well. So you're going to see a lot of pop-ups today. So it actually shows you that Lotor coffee as an example is actually created using a fake AP. Or probably this is Airbase responding to probe responses and one of them got picked up. Come to this a little later. Let me actually go to the settings and pull down at least some of the alerts. So Chellum begins with trying to be a better wireless scanner. What I did is I saw a lot of tools like Insider, but I wasn't happy personally with the way they were handling a lot of the data. Now, Windows does something very, very funny. My Defconn talk is going to be quite noisy, which means people can project stuff and all that. So what Chellum does is it actually looks at the different APIs and unfortunately Windows's wireless manager doesn't give you a lot of this information, right? It just gives you the SSIDs. That's about it. Chellum can actually pick up the individual SSIDs and look at the actual BSIDs behind them. Not just that, it can actually pull out a ton of other information. Like example, the frequency, the auth. This is going to be a completely free tool which I'll be releasing today. Anyone can download and use it after my main talk at Defconn. So it actually gives you a lot of information depending on what you'd like to look at. It can actually even show you, yep, Chellum found me. Okay. Who tried that? Okay. I mean, we deserve a little clap for that. So you tried a black box kind of thing in the sense I didn't know. So you can actually figure out fake APIs. You can actually write your own fingerprints. This one has an older one, I think for airbase and a couple of other tools, but you could write your own fingerprints if you wanted. But Chellum does both black listing and white listing. That's kind of the more interesting part. Black lists will never work eventually. It's always going to be a game where you're trying to fingerprint the latest version of a tool. So that wouldn't help. So how does Chellum work? We reconstruct the beacon frames. So if I click on details, what I've actually done is using the APIs, we reconstruct how the beacon frame looks like, all the different information, elements and all of that stuff. Now keep in mind, I am not sniffing. This does not require custom drivers. This does not require custom hardware. This will work on any Windows system, Windows seven and above, right? And compatible hardware. So you could actually plug in any card and this would work, right? That was one of the design goals I had in mind when I started working on this is, you know, I didn't want people to kind of find the right hardware, right? So Chellum shows me all of this. Now let me actually show you how we could go ahead and create a firewall. So once we can actually look at the different beacon frames or rather reconstruct the different beacon frames, we should be able to create a signature for an access point. Now how would that actually work? Is that your attack tool complaining about Chellum? Someone already built in a little alarm saying Chellum's around. So how do we go ahead and fingerprint a network, right? Unfortunately, I'm sorry about the popups. I have to disable it. So what we actually do is once we reconstruct the beacon frame, I can actually pick up the different IEs from the beacon and start fingerprinting how my home AP looks like. Now how do wireless attackers work? You sniff the air, you look at probe requests and you create fake APs with the same SSID, right? At an airport, no one can know the different IEs or at least some of them which your home AP uses. No one can know the BSS ID of your access point, right? So Chellum allows you to go ahead and create a rule set based on that. How difficult is it to create the rule set? Quite easy. Can actually go down, find the right network. So I have a little network in here called OpenSysame somewhere. Chellum can also find hidden SSID networks. That's why you see a lot of the hidden SSID stuff up there. Okay, here it is. So let's say this is my home network. Now if I wanted to create a rule to white list this home network, all I would have to do is right click and say create rule. Now what this does is it'll pick up all the different IEs which are now recreated based on what I got from the Wi-Fi subsystems and the different APIs. And this actually creates quite an interesting rule. Let me dismiss this real quick. Okay, one of the things is the tool this refreshes. There you go. So now this actually allows you to create your own Wi-Fi firewall rule, at least to the best of my knowledge is the world's first. Right? How do we work with this? We can actually create a rule. You can enable the rule. Now unlike a wide side IDS, what I figured out in the case of wireless, there are two times roughly when you probably want to find something wrong is going on. The first is when you're connecting to a network. And the second is there is an attack network with the same SSID as once you're probing for. Right? So you can tell Shellum to check at both or one of those stages. Let's go for both right now. Now Shellum has automatically filled up a lot of the info. For example, the BSSID. And this can actually be multiple ones as well. I apologize for the pop-ups. You know, I have to change the code to quickly kind of make that change. And we can actually say, can this change or not? No, the BSSID can't change. No, this will always be infrastructure. No, this is going to have this exact same physical layer. And if I'm on a fixed channel, no, this can't change as well. Now, one of the other interesting things which I figured out is the attacker can never figure out your neighboring APs. So I also go ahead and create a list of the neighboring APs. And you can tell Shellum that at least one of them or more of them have to be around anytime you see opens his aim. Okay? The attacker in the wild would never be able to figure this out. So if this isn't, those APs aren't around, then Shellum knows something is wrong or it's probably 3M in the night, right? But you can configure that if you want or you can just let it be. Right now I can just say, okay, it's fine simply because people are running stuff and many of these APs might not be around. Then you have capability information and then you have all of the beacon frame information, right? And I can actually tell Shellum that this is the only set of beacon eyes which may be allowed. So I can actually say, well, new eye elements cannot be present. If it is, then that's an anomaly. So now I go back and I can say create rule. Okay, rule created. Now I can go back to my attacker setup. Yes, the entire parameter is something you can completely configure. Now keep in mind, an attacker in the wild can never guess all the parameters correctly. Is this impossible? How do you know all the parameters in the IE? How do you know the BSS ID of the fake AP of my home AP? But you're at the airport and I'm talking about my home AP and my access point at my office, right? Actually, even if you sniff all the parameters and create an identical replica, still Shellum has some intelligence. I'll get to that. It has something to do with clock skews. So that's probably possible. Yeah, it's possible. And that could be the case when someone actually follows you to your home and clones your AP, then you have bigger problems than Wi-Fi issues, right? Yes. Yes. Yes. So what I did is when I architected it, I actually made all the rules and everything go inside a SQLite database. So you can just copy the rules.db to any machine, start Shellum and automatically pick up those rules. Maybe later on, if people like the tool, want to use it, we might spend more time, you know, kind of refining and creating a front-end tool. Right now, this is complete freeware. Okay, so now let me go ahead and create a fake access point with the same name. So it takes a couple of, probably a minute or so, simply because Windows only scans once per minute. And that's when we get the results. Windows also caches results from time to time. So we might not get the AP immediately. Might take a couple of seconds. And now I don't have host APD signature in Shellum. But there you go. Do you notice Shellum actually found it? And it says that, hey, looks like a rule set was hit, opens his aim and this was the issue. Now, Shellum does something interesting. This is the part which is still a little buggy from a view perspective. So I apologize if you just see a crash. But you can actually view and Shellum will tell you what was different because of which it actually flagged it. Rules which you haven't forced where anything is just, okay, this can change. Those are all green. So it tells you the BSSID didn't match. The center frequency didn't match. Some of the capability information didn't and most of the IE's never matched. So Shellum tells you, hey, you configured me and told me that when you see opens his aim, you should actually see all of those IE's as well with certain values. But I don't see those when I see opens his aim right now at the airport, right? Or at DEF CON. So this definitely is not the AP you're typically used to connecting to. Right? Personally, I think it's going to be very, very hard to beat something like this. The only way is if you have complete full knowledge of the access points you're cloning or trying to create fake AP against, of course, apart from software bugs, right? Here I'm talking about conceptually the idea itself. Right, right. So basically what is the design goal really? There in my DEF CON slides where I can just pull up what was my design goal behind it? Just kind of go ahead and stop Shellum for a second. Too many alerts right now. Okay. My first design goal when I started was to build a better wireless scanner. I wasn't happy with what was there at least on Windows. And a lot of people at least who aren't very Linux aware unfortunately don't know how to go ahead and use something like AeroDump or some of these other tools. This can actually even run on your Surface Pro or any of those devices as well, right? Any Windows system. The second thing which I wanted was that it should be able to learn networks you connect to, right? Similar to most IDSes, you have to decide what the baseline is, which is the first time you connect to your home network. You actually say, hey, this is the one which is whitelisted. You decide what to whitelist. The same goes for Office as well. Can Shellum tell you, look at a new network, a Starbucks and tell you, is this good or bad? No. It's the same thing as you can't look at an EXE and say if it's malware or not. I mean, you can run your heuristics, but you're as good as what you have. However, you can go to your nearby Starbucks for the first time and actually go ahead and add a rule set for your home Starbucks, right? So after that, if someone does create a Starbucks, Shellum can actually tell you this isn't the Starbucks you're used to. Now, Shellum can actually even deal with multiple BSSIDs or multiple values. Shut it down, but you can right click create a rule on just an SSID and it'll automatically pick up many of the BSSIDs it sees around. So this rule would actually be like an aggregate rule for multiple SSID vs. SID combinations, right? Of course, the only time that would work is if most of those APs are similar or else you would be significantly diluting the rule by having to ignore the differences between different APs. If you have a wireless controller as in an enterprise, this won't be a problem at all because you have the exact same characteristics can have pushed to all the endpoints or all the access points, right? Any, any other question about this? That's a very good question. So what do we depend on right now is the wireless subsystems? So let me could be interesting. This is more of the architecture of the tool. It's just going to start with a clean slate just so that everyone can see how that changes. Okay, now what do we do? We do not sniff the air, at least for version one. Okay. So we look at the entire Wi-Fi subsystem and pull all of that data out from Wi-Fi APIs, little events happening on the network subsystem. So if I actually go in here, you'll automatically notice Chalam gives you a scan complete WLAN notification scan complete WLAN notification network available, right? So in Windows, all of these different subsystems are continuously interacting, raising events, sending stuff to each other. I'll disable the alerts for a second and we can actually go and configure which exact events of the subsystem you want Chalam to monitor, right? So when I was building it, I wasn't very sure about what events give me what data. Each of these events actually gives me ton of data. So then I had to go on and parse all of those event data logs and look at, okay, you know, this is interesting, this isn't. But then we finally went ahead and kind of created an interface where you could select the events you want to log. So at this point, some of these events have happened, per se, and that's the reason why we have it on scanning mode. So if you're connected to an access point, once we get an event which says connected, you're already connected. We could disable the interface and disconnect you, but the Windows subsystem informs us that has happened. What are we doing in Chalam version two? I'm actually writing an intermediate driver which will sit above the mini port just below the protocol driver. And this will actually look at all the packets which basically go up and down from the mini port to the protocol. So when we go ahead and say that, hey, this is the AP beacon we would like to white list, then the intermediate driver sitting down below sees an attack traffic for the same SSID and automatically drops it exactly the same way as wired side personal firewalls work today, right? They have a kernel mode component which does this. So we would do the exact same thing. And all you would see is a little alert saying the threat was mitigated. The only way is going to be a call out driver or an intermediate driver. Microsoft's recommended way right now is to write a call out driver. There isn't any documentation at all. So it kind of takes some time to find it out. Second, once I had the initial driver ready, what I figured is it has to be co-signed by Microsoft now for Windows 10 and above. So the co-signing might take us some amount of time to achieve, but in the next four months, you should probably see the call out driver version available as well. Of course, it takes some time to even check the drivers are stable or not, right? If the driver crashes, your system crashes. Right now, Chellum can run comfortably. You can even disable your wireless and Chellum wouldn't crash or complain simply because it depends on the event-based systems. Any questions? This will be complete freeware. Yeah. You have to enable validate certificates. From what I've seen, if you don't enable validate certificates, regardless of whatever servers you've mentioned, should kind of allow you. I mean, at least in Windows 7, I had checked that when I initially tried it, but you can try it out. Logically, unless you enforce validate certificate, well, everything else is insecure, regardless of whether you have the names in or not. Yeah. Yeah. You just have to go ahead and add your certificate in there and remove the rest. Right? Actually, a lot of enterprise firewalls do deep packet inspection using exactly that technique. They would add the firewall certificate as like a root CA certificate on your list of certs. And then that transparently issues certificates for any of the domains you're trying to access. And then they can actually look inside the packet. So yes, and you have to just remove the rest of them. You could do that. Questions? Okay, great. So we have around 20 minutes and let's do quick demo for people who are around and we can help out. If you have any other questions, you can ask us, right? WPA, WPA Enterprise or anything related to Wi-Fi security. Here is the resident expert. Any questions of AeroDump? I mean, every single time Thomas demos AeroDump in the classes we teach together, I'll learn some new stuff, some new interesting feature, which I never knew about. So, hey, if you had AeroDump questions, he's your guy. Okay, so we'll start the labs. Does everyone have a Kali VM, whoever wants to do the labs live? And then I can go through the processes step by step. And as I said, I'm doing a three o'clock talk today on Chelum. And I'm doing a 12 o'clock talk tomorrow in DEF CON on creating your own network ideas by taking pcap files, converting the packets into SQLite database tables and then running arbitrary queries on them. So, if you always thought of how you could begin with network forensics for Wi-Fi, that talk can be interesting, right? But beware, things may crash. I mean, looking at the kind of traffic I see, my tool is really being tested. So, but I have videos. So just in case everything crashes and burns. Okay, let's start the labs. Okay. How many of you want to try out the labs? Okay. Can everyone just move to this side? It's just easier for us to probably move around and help you out. And you can just raise your hand so that we know you have a laptop and you want to do the labs, right? One, two, three, four, five, six, seven. Okay. So we have seven people here. Oh, sure. And if you're in the vendor area, we're giving out the hacker gadget and the Linux forensic book together at $40. So the hacker gadget book is really how to create your own supercharged Wi-Fi pineapple using OpenWRT. So you can actually go ahead and install OpenWRT, port all the packages and all of that on it, and then you can create your own pineapple if you want. Or you can just plug on the pineapple and enjoy whatever you like to do. So, yeah. Okay. So I'm going to start the labs given we have less amount of time. Okay. So there are two ways to go ahead and create an access point using either an external access point, such as the TP-Link one which you have, or you can create an internal one using host TPD, like the one which I did, right? Both of them are pretty much equivalent. So we'll use the external one because we don't have enough wireless cards for all of you. Okay. So in the case that you have a real access point, the setup would work like this, right? I have my Kali VM running inside VirtualBox and I have my network connection which is bridged to my wired adapter. Okay. This is important because we want the access point to be able to talk to the radio server directly. So you have to bridge it. At the very same time, the TP-Link which you've been given has a switch on the side and sure it is set to 3G, 4G. That's the default config. I know, you know, most of us, when we see a switch, we have to toggle it. But if you change it from 3G, 4G to anything else, the DHCP server will stop. Now, once you do that, you can start your Kali VM and sure you plug in the Ethernet connection of the access point as well. Okay. If any of you do not have FreeRadiusD installed, then I'm just passing a USB. You can just copy it inside your VM, right? You can copy it and pass it around. The process actually is quite simple to configure and install FreeRadius. You can just have a look on the screen while the USB is being passed around. So once you go ahead and unzip the USB, sorry, unzip the file Wi-Fi class.zip on the USB, you can go to a directory called WPA ENT for Enterprise. There is a little file in here called kali.txt. This just contains very simple commands to un-tar patch and compile and install FreeRadiusWPE. Yeah, yeah. I think this, this, do you remember who wrote this patch? Okay. Okay. And you can just run the file. I mean, and should automatically compile and install FreeRadiusD. If you have the USB, you can pass it around. Or if you have RadiusD already installed with you, you can just run the dot slash kali.txt. I mean, these are just shell commands, so it will automatically run it. You don't have to type any of those in, right? Once you have the zip file, you could just run it as a bash script. I mean, I've called it a .txt, but it would just run. It just un-tars the FreeRadius server, patches it, and just does the regular make, make, install and ldconfig just to ensure all the libraries are immediately available for use. Okay. So because we are so close to running out of time, I'll just show you how to go through the process just after this. Okay. So let me, so once you do that, the process actually quite straightforward. It isn't complicated at all. So just have a look at the screen and you can try it out, you know, in case we run out of time. Once you download, install and compile this, you just have to configure your radius server on both the access point, first to begin with. So the default IP address of the AP is 192.168.0254, the one you have, or later on whichever one you use. And you can find the WPA settings. We're going to wireless security, wireless security, and then you can fill up the appropriate IP address. You can easily find what IP address you have through the Kali VM. And if you notice the IP address given to me by the router, because I've kind of bridged the interfaces is 198.168.0.101. Pretty much all of you should have that as well because that's the first IP address to be handed out in the range. So we can put in that IP address. The radius port 1812 is always the same unless you've changed it for some reason in the config. And then you have something called the radius password. So let's actually figure out how to set this up. So we'll have to go to the radius server config directory, just at user local, user local ETC raddb. Now this contains all of your radius server config files, the certificate which you generate and all of that. So we can generate a temporary certificate if we wanted to by going inside search and then just typing dot slash bootstrap. Once you do that, we can then finally go to a file called clients.conf where we have to give a range for the client to the radius server. The access point is the radius servers client. Right? So we can actually go in there and this should be line 196 in the clients.conf and you can just uncomment this section. So as you can notice the shared secret is testing 123-1 which is this here. You already set it and then you can save your settings, restart your router if it prompts you. And at the other end, now all you have to do is start the radius server with the hyphen s hyphen x option. So once you do that, when a client connects to the access point, the AP will start talking over EAP to the radius server. And all of those messages would be encapsulated go back and forth. The fake certificate would be put out and then the attack would be conducted. I'll just show you that. Okay, so I'll just show you the last step and you know, we've kind of finished our time, but you can set your laptops up at the back and we can help your people who would like to do the demos. Right? Okay, thank you. Okay, guys, thank you. Thank you very much. And if you want to do the demos, you can just set it up in the back and we'll be there to help you. Thanks.