 All right, hi everyone. I'm Josh Evor. I'm Prize like partners. And you are currently attending the BYOD peep show, mobile devices bear off. Today we are going to be playing with the wireless here, specifically DEF CON secure. It is not my fault that it's down right now. I really truly have nothing to do with that, but that actually helps us. It makes it easier and makes me not have to blast you with that thing. So we'll let you know when that's actually going to happen. It's completely voluntary. We've made it so that it will likely only affect you guys. But of course it's who knows what everyone else is doing with the wireless. So just a heads up, again, we'll make sure that you have full warning. I do encourage you to participate because I know that the credentials that you used for the DEF CON secure Wi-Fi are not the same as your Gmail. At least I would hope. So I hope you don't mind if I do capture those. So keep that in mind. And when the time comes, it would be really nice if you could turn your phones on. I'll let you know. All right. So over the past five years or so, a perfect storm has been brewing. This perfect storm has three components, much like the perfect storm of 91, which you see the NOAA weather graph from. So these three components started in 2008 with a single event at Schmucon 2008 that we'll talk about. Then there is the growth of BYOD. And then a talk here last year at DEF CON that made everything really easy for what we're trying to do. So let's take a look at those. In 2008 at Schmucon, Joshua Wright and Brad Antonowitz shared a talk that basically outlined how PEEP was very commonly misconfigured. And at this time, this only really worked with desktop operating systems. BYOD wasn't a thing yet. The iPhone was less than a year old. So this is not on anybody's radar that this would then eventually affect BYOD and mobile devices. So this research actually included a tool called FreeRadius WPE. And that's been a standard for network penetration tests ever since. What Joshua and Brad found was that by default, the PEEP configurations that were in use on desktop operating systems did not do certificate validation. There were some other findings within the research. I encourage you to look at it. But that's the thing that we're going to leverage today. Because they didn't check the certificates, they had no way of knowing whether or not the authentication server they were talking to was a legitimate one or a Rogue One. So the result from this research was that desktop systems were changed. There were upgrades and patches. There were security advisories that came out telling people how to actually configure things properly. And this has largely gone the way of the dinosaur as far as an issue. We still run across it once in a while. But typically, it's largely mitigated at this time. At least in desktop operating systems. One of the lessons that came out of that research, at least at that time, was the notion that these PEEP network can actually still be configured properly and be secure. And that's something that we're going to revisit today in the light of the other two parts of the storm. Then there's bring your own device. And I do have to apologize for how many times I'm going to say that buzzword. But do know that when I say bring your own device, I'm not just talking about BYOD as like in its true definition, which is users actually bringing the devices that they own. This research and the tools and techniques we're going to talk about also works against mobile deployments within a corporation. So if your business buys you an Android device or an iPhone or a BlackBerry, these attacks can still work against you. It's not just the devices that users bring that they personally own. So BYOD is huge. I don't think I need to talk too much about that. What's been really amazing is how fast it's grown in the past five years. So it's just, yeah, it's absolutely crazy. It's grown so fast that metrics that are reliable are really difficult to find. So the best I can give you is that anywhere between 60 and 85 percent of companies support BYOD in some shape or form. Whether or not that means, oh, hey, we give you an open Wi-Fi or we set up WPA2 Enterprise with PEEP, it's hard to tell. And there are no real hard numbers that we can give you. There's also the issue where we don't really know what the definition of BYOD is when we're trying to collect metrics because that definition changes between environments and based on who's actually collecting those metrics. What we can tell you is that in BYOD deployments that support the WPA2 Enterprise, the vast majority of those deployments use PEEP for the authentication protocol. And we'll go into a little bit more detail as to what that is in a few minutes. But just know that by and large that is the most common WPA2 Enterprise authentication protocol which is why it was the juiciest target. And the third part of our storm and the most recent was Moxie's research last year that was presented here at Dofcon in Dofcon 20 and his associated product called Cloud Cracker. So Cloud Cracker for those of you who might not have heard about this or weren't here last year is a commercial service that's available now and through Moxie's research where he was able to reduce the strength of MSChap V2 challenge and response responses. He was actually able to work with some other guys to come up with some heavy-duty computing systems that are available online now that guarantee that they can crack an MSChap V2 credential challenge and response in 24 hours or less for 100 bucks. And so if you think about the companies that tend to use BYOD deployments, they tend to have a lot of users that would be a network that I'd really like to get on. So 100 bucks is really not that much money when we're talking about a type of credential that will get me on a network. While we're talking about that credential it's important to know that it's not just some random user name and password that that person is using just for logging on to the network. That's typically because of the way that these deployments work. Those are typically the AD creds, your domain creds, the same creds that get you into the VPN, they get you into your email and any other services that are managed through Active Directory or the equivalent. So this is a credential that we'd really like to have and that makes it much more likely that someone's going to be willing to spend 100 bucks in order to get that. Also, don't forget that it's a weak password. You can also crack it locally. All right. I'm going to spoil the rest of my talk here. So I'm going to tell you everything that we want you to walk away from this talk. So on paper, PEEP should work. As long as everything is perfectly configured, PEEP should work. If all the devices validate the certificate, everything's going to be okay. But that doesn't actually happen in real world deployments. Even when you have a multi-million dollar company with a huge and really expensive and really fancy mobile device management system or MDM, those networks still have the same issue. And we know that because we've worked with those organizations and we've found this issue. And so this isn't something that you can say, just flat out that it's going to always be okay if you can figure everything properly. And we'll talk more about why that is a little bit later as well. The impact is absolutely staggering if you take a look at who could potentially be affected. The organizations that use BYOD are growing. The vast number of organizations that use BYOD are growing. And over the next few years, it's expected that we're going to get closer and closer to 80, 90 percent acceptance. And that means that by default we're going to see the use of WPA2 Enterprise increase as security becomes more of a concern with mobile devices and as mobile devices need more access to internal network assets. And that's something that we're seeing with the development of more mobile applications that integrate with what used to be traditionally only internal or non-mobile internal assets and services. If you support one of these networks, first of all, I did come prepared. I have two motion sickness bags for you if you need to come up and get one. So they're right here. So the impact is enormous and there is no corrective action that's going to fix this really easily, but we need to start working on it immediately. We'll have some ideas as we start to wrap up near the end here on what you can do to actually fix this issue if you are in the position of needing one of those. The key thing that damages the assertion that PEEP can work if it's configured properly is the fact that in a PEEP network, the users are in complete control. And that's because all I need to know is my user name and password to get a mobile device on the network. And I don't know about you, but if I was running the wireless network for an organization that had 10, 20, 30,000 users, I'm not going to trust all of them to know how to configure their devices right. And even if I configure their devices right for them and even hand it to them, nothing stops them from bringing on their own mobile device because they know how to connect because it's just their username and password. So here's the bottom line. Again, vomit bags up here. On defense, this is bad news. We'll go through some things that you can do to make this a little bit better, but it's going to take a while for this to be fixed and for these issues to go away. Right, LeFroy. Now that is rocking. What's this called? Shot the noob. Thank you very much. Why are we doing it? First time speaker. Who do we need on stage? Someone who's first time at DEF CON. All right, this guy over here. Thank you, yeah. So good question. Only the second person who's asked that are the speaker goons doing a shot in every track for every new speaker. The answer is yes. How many is that during this DEF CON? We have way freaking lost count. There is no chance we know that number. Think about it this way. We're almost ready. It's four to six an hour since 10 a.m. every day. All right, to our new speaker and our new attendee. Now if you happen to be on the other side of the fence, you should be really happy. And I know at DEF CON this is an appropriate crowd to share both of those images. The barrier to entry to gain local access to a wireless network has been drastically lowered. And remote access to services that use the active director credentials that are exposed to the internet is also reduced. And you don't really need that much equipment to go out to do that. Now there are some people who disagree. And this dates back to right after Moxie's talk last year. And some of the things that you'll find, there's lots of follow up after Moxie's talk last year, mainly about the VPN issue but also about WPA2 enterprise with PEEP. There's a lot of response from technical writers and people interested in security. And some of it is absolutely right. But some of it I tend to disagree with as well. So like I said earlier, it is completely true that a perfectly configured PEEP deployment is going to be just fine. But that never happens in reality. And so what we're going to see is that we're going to rely on the same people who did the same follow up last year after Moxie to hopefully help come up with better like deployment guides and configuration guides because we typically still see these issues in pentests with mobile devices where some features that exist within mobile platforms aren't being used. A good example that comes to mind is iOS profiles that can be installed on phones and makes it really easy to deploy things, deploy configurations including WPA2 enterprise configurations. So that's one of the things that we're going to rely on the people who a year ago were saying this isn't a problem to then turn around and say hopefully, well, okay, this is a problem, let's figure out some more solutions on how to fix it easier. So let's talk about some of the risks. These are broad generalizations just to kind of give you a decent overview. Of course it drastically differs in site to site and organization to organization. But typically we find that individual users, the chances of you being targeted and the chances of you really carrying that much if your work email is compromised, you know, at some point, especially if it's a device that your employer handed to you, you can fairly say, hey, that's not my problem. I didn't configure it. So the user experience varies. And in the type of attack that we're going to talk about in a few days, you'll kind of see why that is. Of course, there are certain attack methodologies you could use to try to target really high profile users. So let's say for example that you knew that a few CEOs from a group of companies were going to be in a certain location, the attack that we're going to demonstrate and talk about shortly will be a lot easier and a lot more impactful. The smaller organization, I'm talking about smaller both in size and in IT resources will also tend to have a, excuse me, smaller in numbers of people, not resources. Smaller number of people will likely have lower risk. And that's primarily because you have fewer devices that you need to actually configure. If you're a mom and pop shop that uses WPA2 Enterprise with PEEP, we'll first kudos to you for configuring that on your own. But you probably have your hands on every single one of those devices every day and probably make physical contact with every single person that carries one of those devices. So it's probably going to be pretty easy to manage. The twist to that though is that once you get into like small and medium size, like full grown businesses, but they lack those IT resources to come up with a full fledged MDM solution, we see that they're much more likely to be vulnerable. If you have a user base that doesn't change very much, then you're going to have an easier time configuring and managing those devices regardless of your MDM solution or if you have one or not. Of course, the higher risks are to the internal network assets that exist within the network that can then be compromised with those credentials. Large organizations with more users, of course, have more users that are likely to have misconfigurations. And I'll share some metrics from my testing experience a little bit later. And of course, the more phones and devices you have coming in and out, the more likely you are to make mistakes. And this misconfiguration is everywhere. And one of the things I wanted to point out is a public example that we can share. I'm not going to call out any individual universities or public education institutions, but you can do that yourself. It's really easy. Because those types of organizations have to support so many users and their IT help desk staff is typically just swamped regardless of trying to manage the BPA2 enterprise, they tend to put all of their instructions for accessing the wireless network online, which private companies tend not to do. But if you can see their wikis, like if you guys go back to your employer and you want to check to see what the likelihood of your organization being vulnerable to this type of attack is, then check your internal wiki or documentation that tells you how to configure your mobile devices if you have a BYOD policy at your employer. And that will tell you pretty quickly whether or not you're going to have an issue. And we'll show you what that looks like. So this is taken from one of the universities in that search result. And typically what we find is that the instructions are super old. Really old versions of Android, BlackBerry, the Windows phone before his Windows phone, Windows Mobile is on there too often. And what we see as well is that either the user is explicitly told not to install a certificate or they don't say anything about the certificate and just put up a screen shot like this. And so that's the configuration that I need, that's the configuration I'm going to go with. And we still even see that for Windows as well. Where even today, even after Brad and Josh's talk in 2008, we still see publicly available information from the authority for a network telling users not to validate the certificate. You see that in the other settings comment at the bottom there. So that's pretty scary. So we have a lot of catching up to do even from 2008. But now we have to catch up even faster because BYOD is growing so much. So why PEEP? Well, this shows a little bit of it. So PEEP and EAPTLS, EAPTLS by the way requiring mutual certificate authentication. So the authentication server presents a certificate and then the user validates that hopefully and then sends their own certificate back. So it's not actually using AD creds. EAPTLS and PEEP are the two most widely supported, most widely supported EAP types across mobile device platforms and in general as well for desktop operating systems. It used to be that the Wi-Fi alliance required support for EAPTLS if you're going to be WPA2 enterprise certified. That's no longer true. I think that changed back in like 2005 or 2006. I wasn't quite able to get an exact date on that. But what you see is that PEEP is the most widely supported across mobile devices. And so if your goal is to just support as many devices as you can, truly be a BYOD organization, then PEEP is a very attractive option. It's also much easier to configure. Because I don't know about you, but I know that like my mom doesn't know how to actually download and install a client certificate. I mean it's hard enough trying to tell her how to find a PDF that she downloaded on her mobile operating system. It's very tricky. And then trying to actually go ahead and manage a certificate and then get that on the device securely, especially for device platforms that don't support MDM solutions or that don't have a robust integration with them. That can be troublesome. There are many other EAP types, but the ones that you see on the screen are the ones that are supported by those devices or not. So really quick, just for a few minutes, I'm going to talk about the WPA2 enterprise and the difference between why we use that versus a pre-shared key, like with WPA2 or open. We'll just talk about this briefly. So it's all about access control granularity. In an open network, it's open. We get that. With WPA2, you just need one shared key, the passphrase. And everybody knows it. And that's great for like your family network and what you go home with. It gets pretty bulky and cumbersome. Because what ends up happening is, unlike WPA2 enterprise, where each individual user has a username and password or some other credential that it associates that device to that user, when we actually have a compromise of those credentials, or let's say it's not even a compromise but somebody leaves an organization and we don't want them to know the password, it becomes an issue. And that's why WPA2 enterprise is used to widely in large organizations. Because at that point, all you have to do is lock a single account and you're good. So let's talk about where these issues actually lie. And this will build up the path to talking about the actual exploitation methods and we'll get into those fun details. So 802.11 is pretty straightforward as far as association to the access point. What's interesting here is that there's a request for the 80 username, the request for the identity, the identity is then given back. That's actually outside of directly speaking to the radio server as far as establishing a secure tunnel. So regardless of whether or not you have a rogue or real access point, or access point displaying a rogue or real radio server, you can still get the username of the person that's trying to connect their device. That's something we've known for a really long time. It's just fun to know. So outer authentication, and this is what was broken by Brad and Josh with FreeRadio WPE. So that identity goes to the radio server. The radio server then sends back a certificate. The client is supposed to validate that certificate. But in order to do that, it has to have a pin already, or it has to have a trusted route for the CA identified. And we'll get more into that later. But that establishes the secure tunnel, and then inside of that secure tunnel is where Moxie comes in. So now that that secure tunnel has been established, there's an access challenge that comes from the radio server to the mobile device. And then a challenge response that goes back from the mobile device to the radio server. That's the part where if you can get a mobile device to connect to you, even with an invalid certificate, the fact that you can capture those challenging responses means that you can then reverse that using Moxie's tools and research. We're going to get into the mobile platforms and talk about how they differ, because what's really interesting in doing this research and in the live testing with organizations is that none of the mobile device platforms are perfect. Some are better in some areas, some are worse in some areas. It's just a really diverse set of support and features for WPA2 Enterprise. One thing I want to note here is that just remember that I'm not saying that one platform is more secure than the other overall. We're specifically just talking about WPA2 Enterprise. We're going to take a look at the four major, I guess, mobile platforms. We're going to take a look at Android, BlackBerry, iOS, and Windows Phone 8. So for Android. Android has the largest user base just in the general population worldwide. What's difficult to find metrics on is in organizations that support BYOD is how many users are using Android versus iOS. That data is not readily available at this time. But from the experience that I've had doing tests at different environments, iOS and Android from the organizations I've worked with are probably about 50, 50, 60, 40 years out there. So Android supports the types that you see up there. What's interesting about the user interface for configuring WPA2 Enterprise is that it's reused between EAPTLS and EAPPEAP and all the other EAP types. And so they made it really easy for the developers and to some extent to the users because nothing is going to move around. But people actually tend to start to ignore the certificate if they're not explicitly told what they need to do with it. So you can see that I'm configuring my device here following the instructions that we found on the college's website. By default, if I click on the CA certificate, there's nothing available to me. And that's both good and bad. It's good because public CA's can be used, but there are some drawbacks to using public CA's for authenticating server. The reason that that can be a challenge is because mobile devices don't actually validate the CN name of the certificate. And so let's say that you use TrustWave for your or VeriSign for your certificate. That means that all of your mobile devices are going to have that root CA as the trusted CA for your wireless network. All I really need then is a certificate from one of those public CA's in their public. So I'm going to spend 100 bucks, 150 bucks, something like that. And then I can then potentially get your devices to connect to me and I'll pass that validation. So it's good and it's bad. This prevents you from selecting a whole bunch of different public CA's by default. But it also doesn't prompt you or anything to communicate with the radio server and actually see what the certificate is or to install one that inside of the phase 2 authentication you actually see that there's a whole bunch of different options there as well. That also leads to some misconfigurations that are outside the scope of what we're talking about here. But let's just say that when you're doing testing and your devices are misconfigured you can see some really silly things coming over the network. On to iOS. iOS has a relatively very strong business presence. Part of that from the feedback I've received are their configurability especially with those iOS profiles that can be pushed out to the devices. The peep configuration is really straightforward. You enter your username and password. It actually prompts you to validate the certificate. It's a trust on first use approach. So the user has actually shown a certificate. It says not verified if it's not in one of the installed CA's within the operating system. And before you accept it you can actually take a look at the details. And this way you can see whether it's the default certs that come with free rate is still BPE or if it's actually the certificate that you're expecting from your organization. Now users really are terrible at figuring that out but often times if the organization says example Inc. and you're expecting that it's going to be your businesses certificate hopefully that's going to raise a flag. Blackberry. And I do apologize for the screenshots. It's not easy to get a screen capture out of it. So Blackberry actually has a lot of different e-types that they support. They have the most of any of the mobile platforms. Not all e-types are created equal though. And only a handful of them remain secure. And if you want more information on that, Josh and Brad's research goes into a lot of the details there. So this is both good and bad. There's wide support on the platform for just about every e-type that you can find in a mobile environment. But again, some of those are not that great to use. The peep configuration is nice in that if you see the blue bar at the bottom, you actually have to explicitly disable certificate validation if that's what you want it to do. By default Blackberry requires you to validate the certificate. You can't complete that configuration until you've either disabled it or given it a CA. But this one, Blackberry, has all the public CA available. Again, it's both good and bad. It depends on your risk profile and things like that. Windows Phone 8 doesn't have a very large business presence right now, but seeing that it comes from such a well-known vendor and manufacturer, it's something that is worth talking about. The peep configuration is similar to iOS at the start, where it's just a very simple user interface using a password. But you'll notice that the validate server certificate option is at the very bottom and it's off by default. That's something that makes it pretty easy to accidentally just click through without installing the certificate. In fact, you don't even see a certificate prompt or a place where you can actually enter a certificate until you turn that on. The certificates that are available on Windows Phone 8 are actually kind of interesting. There's a very small number, but it's good because the fewer CAs that you trust, the better. But they actually, and this has nothing to do with the security of the platform, but I did find it interesting that there are actually two expired certificates that it chips with. It was just odd, a strange finding. All right, so you understand now the different platform support for WPA2 Enterprise. You see that peep is the most widely supported and oh, yeah, I just want to mention again that you saw on the table that Windows Phone 8 only supports peep, not TLS, no other eP types. So now that we've gone through all the different mobile platforms and you understand that the user experience varies and that's one of the reasons why it's so difficult to write instructions for your users to follow, like if you're a university or a large organization, for example. So the chances for misconfiguration are pretty high. Let's take a look at how we attack then. That's the fun part. I'm telling you about these things in the traditional network attacks here. We're going to be using some anonymized data about some real life attacks that we're able to do. As we get into the more exotic and fun attacks, there will be some hypothesized things based on some other fun stuff. So in a traditional attack, it's a regular rogue access point. All you need is a laptop really. In my setup up here, we'll talk about that later, but I'm actually using a regular router and another Wi-Fi card and antenna. That's mainly because I expected a lot more pushback from the audience and the hostility of the wireless network here. But it turns out we might not actually run in any problems there. So with a... What's that? Now since I said that, yeah, I see all the laptops coming on. Actually, that would be good for me. I'd really like that right now. Actually, in about a few more minutes. Just like trying to capture somebody on an open Wi-Fi network with a pineapple or something like that. The best way to perform one of these attacks is to broadcast as an access point connected to a radio server. The de facto standard is free-radius WP right now, although we'll talk about more tools that can actually do that as well. I'll broadcast the SSID, the network name of Company X. And the best way to do this attack is not to be on site at Company X. What you want to do is go to some place where you're going to find their employees and users, but away from their wireless networks. And that's for multiple reasons. First, it makes it a lot easier to actually get them to associate with you. Because then you're not fighting the broadcast and the power of the other real access points. Sure, you can de-off, but then that makes it a lot more of a headache. Secondly, testing away from buildings and away from the real network reduces the likelihood that you're going to be caught. A lot of wireless systems now actually come with features where you can triangulate the location of rogue access points. And so if you're camped out in a parking lot and you're a little too close, there's a good chance that physical security might come knocking on your door. I can tell you from experience though I'm going to mess with you. So, story time. So an example that I can tell you about is an organization with about 1500 users. They didn't have their own building or anything like that. They were on a multi-level building on one of the floors. Their access points were weak enough where you couldn't really get reception outside of the building though. So a great way to perform an attack like this is actually to sit out if there's an exit. That's great. Was able to sit down in the lobby and actually get everyone on their way in and out as they're going to the elevator or the stairs. And so that was pretty easy. There's one single choke point. Now that type of organization would be pretty difficult to target out in the general population. I'm saying that because I'm going to lead up to some of the more fanciful attacks that are coming next. When you have a much larger organization or some of the organizations that come to mind can even be in the tens and maybe even hundreds of thousands of people. You're much more likely to run across those users other places just out in the general public. For organizations that have their own campus, one of the best ways to pull off this attack is actually to sit at the edge of the parking lot. Especially if there's a major freeway there or a stoplight or anything like that where they're queuing up to actually come into the premises was doing a test like this on the edge of a on the edge of a campus. And there was a lot of people that rode their bicycles to work. And as I'm sitting there monitoring the tools and you actually see who's trying to access your access point and talk to the radio server and you just all of a sudden see all this traffic go by and it drops off as they ride by. And so that was pretty fun. So finding a choke point and a physical presence is great. Now these traditional attacks are well known, they're well established. Everyone can do this. The trouble is what if you're not there? What if you want to be able to compromise somebody's active directory crads from their mobile devices and you can't get access to where they actually work? Well, you have to go find them somewhere else. And that's where the more interesting attacks come up. So for multiple networks, I didn't just want to get into my banks network. What if I wanted to get into any or all banks networks? Can't do that traditional attack. I mean I could, but I have to sit in one place, broadcast one network name, one SSID for a long time, wait, stop, do it again. It's going to take a long time. So what if we did something like create a tool that would actually let us rotate the SSIDs on a predetermined basis? What that would let us do is actually hop in the car and do like we're driving 3.0. Which is where you're not actually targeting access points. You are the access point and you're targeting mobile device users. So I'm going to use San Francisco which is where our headquarters is as an example. So if I wanted to target banks, what I would do is hop in my car with my list of SSIDs matched to a whole bunch of banks there and all I have to do is drive around the financial district at lunch time. Chances are I'm going to find a bunch of people who are out to lunch away from their organization, away from their Wi-Fi networks and that means it's going to be very easy for them to connect to my access point. And the only catch is that we have to make sure that we're rotating SSID frequently enough in order to make it effective. If you think about that, you can actually curate this list by industry or even by geographical location. In that example we did both. You can get some really awesome extra credit if you do it on public transit as well. Public transit is fantastic especially in the Bay Area because you have a lot of tech companies that use services like Bart and Caltrain. So public transportation services can be a really good hunting area. Finally, what if we just don't care? I just want to get on some network I want AD creds. I just think it's one. Well, we can do that too. That just means that instead of having a predetermined curated list, it means that we're going to dynamically change the list. And we can do that by listening for probe requests, for beacons and also by going a little bit further and using some outside tools. So let's talk about that. The existing tools that we have, free-rated WPE, which you heard me talk about, that's just a radius server that's been modified to shoot out the MSChap V2 challenge and response instead of keeping it secret. That's pretty fun. There's hostAPD and hostAPD WPE. Brad actually did hostAPD WPE for testing EAPFast which you should probably look into if you want to support that. There's also DDWirt and OpenWirt which you can easily script. And one of the things that I haven't done yet but I'd really like to look at is patching the free-radius tool that's available for OpenWirt with free-radius WPE. That would be pretty cool because you can just have a standalone low-power router that you just drop somewhere and let it go. So the goal of this tool is just give it to everyone. So what's next for that tool? Well, you can script the rotation of SSIDs in DDWirt and OpenWirt and that can get kind of cumbersome and annoying because you have to listen for them, you have to build the list and they have to get them onto the work somehow. Now you can probably do that within the work. I haven't got that far yet. There's a tool called hostAPD Python script which allows you to control hostAPD from within Python which also means you're happy to listen for all those probes and the beacons and then dynamically add those to your list. HostAPD Karma as well? All right, that's fantastic. That just made things easier. So hostAPD Karma. All right, so getting fancy, what else could we do? We could use GPS potentially. Haven't done that yet, but if you can give it coordinates and you can query a resource like APA2 Enterprise SSID within 10 miles of where I am, you can go anywhere in the world and potentially exploit a whole bunch of networks that you don't even know exist and then you can just do the research and figure out where they are and what networks you got into. So the goal is eventually to get this into a single tool. My colleague Ryan Lacy and I have been working on this for a little bit. It's difficult, it's not easy at all. There's a group called, a tool called EAPC I believe that got pretty far along that path but I think that they took a different approach later on. But it's not easy, but we're getting there. Hopefully eventually we'll be able to release a full single tool that will actually do all this in one install. We're not quite there yet. We will be sharing some of the tools that we've used to build up to that including the logic that we've been using to build those dynamic SSIDs. So how do we fix this? You can't just turn off your internet and I bring that up because well it actually happened here which reminds me of a place that we did this at once. We were working with an organization where there was a PEEP network and after working with them realized hey, we can't support this. Rolled out an EAPTLS network with a different name and you can probably see where the problem is because you can exploit this even without the network. So five, six months later you can go back potentially and broadcast as that old network name if you happen to know it and still communicate with the devices. And if they don't rotate their credentials regularly and if they don't have high device turnover there's a really good chance that you're still going to find somebody who is misconfigured even though the network doesn't exist which is kind of creepy. So really EAPTLS is difficult to support and difficult to roll out but it leads to more security. We also need better mobile device management. So quick comparison EAPTLS is nearly universal as is PEEP. The difference is that PEEP is easy, EAP is hard or EAPTLS is hard and let's take a look at why. I'm running out of time and I want to get to the demo. So doing PEEP write takes a lot of work. We talked about a perfect storm. You have to do so much work that hopefully and this is what I hope you experience for those of you who are on the defensive side of this in order to do PEEP write you have to do so much work that it's probably going to still be easier to deploy EAPTLS because in the end remember even if you perfectly configure your network that one user or ten users that want to add their own device still know their username and password and your MDM solution isn't going to touch that especially if they misconfigured it so badly that they don't even bring it to work anymore and it's just sitting in their car and you can still pick it up while you're driving 3.0 all the way around. So DEF CON is secure. I'm hoping some of you didn't install the certificate. Those of you using iOS probably are going to be more okay. Right now we're going to go ahead and get into the demo. We have four minutes for that. Last warning I'm asking all of you to be victims this is not going to hurt I promise. I will not crack your passwords I don't really think your DEF CON secure password is worth 100 bucks or the time and energy it would take for me to do it on my own no man in the middle is going to be conducted so like I don't have I'm not connected to the internet here so I can't even provide you a service even if I wanted to you're going to be all set there and yeah, we'll see what happens so last chance if you don't want to participate please turn your phones off mobile devices your wifi switch on your laptop but otherwise please this end of DEF CON and this would be kind of fun if I got like 40 of you so turn your phones on please and participate and let's go ahead and get into that by the way that's everyone probing so this might actually work and I was going to need DEF but I don't think I need to anymore now we got to make sure that I'm actually on the right IP address yep should be is anyone picking up DEF CON secure now nope, okay might take a second here I got to turn my wifi back on okay it's still booting up okay should be coming up oh wow yeah okay we're getting it alright now let's see if I can show you not there yet so one of the problems is that even if you don't even if you do validate the certificate you still talk to this and so a lot of you are talking to it and this little thing is falling apart but I do have a backup example I can show you I'm connecting alright I just saw my name go by what you see is the output every time somebody is trying to connect to me and when you see the big TLS blobs go by that's when I get happy really that's awesome that's a good name you guys are validating your certificates oh a black hat no that was not me a black hat well that's disappointing what's that thanks though no other way at least in my experience I've had it so that when the log is there it won't update the current log alright well I'm running out of time so what I'm going to do is I'm going to leave this on for another couple seconds maybe a minute or two and hopefully get some more we see all the eep traffic going by and I can tell you the name that we saw oh wow somebody had strong feelings about black hat so what I can tell you is that I see like my name coming by and the eep blobs when you saw that big blob there that's the cert and that's the challenge and that's the eep message going back and forth we're getting it it's just not logging so there's too many of you alright so I got to wrap up but thank you it's been a lot of fun