More MitM makes Mana mostly mediate mischievous Messages
CC Attribution 3.0 Unported:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
singe
cablethief
Et al.
In 2014, we released the mana rogue AP toolkit at DEF CON 22. This fixed KARMA attacks which no longer worked against modern devices, added new capabilities such as KARMA against some EAP networks and provided an easy to use toolkit for conducting MitM attacks once associated. Since then, several changes in wifi client devices, including MAC randomisation, significant use of the 5GHz spectrum and an increased variety of configurations has made these attacks harder to conduct. Just firing up a vanilla script gets fewer credentials than it used to. To address this mana will be re-released in this talk with several significant improvements to make it easier to conduct rogue AP MitM attacks against modern devices and networks. After years of using mana in many security assessments, we've realised rogue AP'ing and MitM'ing is no simple affair. This extended talk will provide an overview of mana, the new capabilities and features, and walk attendees through three scenarios and their nuances: Intercepting corporate credentials at association (PEAP/EAP-GTC) Targeting one or more devices for MitM & collecting credentials "Snoopy" style geolocation & randomised MAC deanonymization As a bonus, you'll be able to download a training environment to practise all of this without requiring any wifi hardware (or breaking any laws).
 Send in cable thief. Hello everyone. So this is the first time I've spoken out loud for like a day and a half because I lost my voice and I've been walking around like a breathy Hannibal Lecter. So if I suddenly start squeaking like a teenage boy, please forgive me. I'm just gonna be sucking on this thing. So today we're gonna be talking about some Wi-Fi hacking stuff. In particular, we're gonna be talking about rogue access point attacks or evil access point attacks or whatever you feel like calling them. And it's a kind of a continuation of a talk that we did in 2014. We released something called the MANNER toolkit. So the way we're gonna talk about stuff is there's three scenarios and you might not be doing exactly what the scenario is describing, but I'm just using them as examples to kind of go through some of the capabilities, tools and techniques that we'll be releasing today. So my name's Singh. This is Michael Kruger underscore cable thief, but we're trying to call him Squirtle Boy. So if you're looking to give him a nickname, please help us out there. We work at a company called SENS Post. It's a penetration testing company based predominantly out of South Africa and London. We've been going for about 18 years. We were told we weren't allowed to use PowerPoint. So this is a PDF. That used to be an animated gift in the corner. So yeah, all right. So the first scenario we're gonna jump straight in. In 2012, a colleague of mine, Glenn Wilkinson and Daniel Cuthbert released something called Snoopy. Anyone here ever use Snoopy? Three people. Cool. Sorry? Sorry, I can't hear you. So Snoopy was a framework for tracking wireless devices. I'm trying to geolocate them based on networks that they were looking for and then using the fact that the device ID was unique. Fortunately in 2018, Snoopy is dead. Yeah, they killed Snoopy. And the primary reason Snoopy is dead is because there's been some changes to the way device manufacturers make their things work across Wi-Fi. So the first thing is that passive sniffing is mostly doesn't work anymore. It's what two reasons are going to now. And the other thing is that device manufacturers have changed the default behavior that instead of a device going, hey, is my home network nearby? It just says, hey, are there networks nearby and is one of them my home network? So it does it tries not to reveal the networks it's looking for and its preferred network list. But I first spoke about the spectrum issue. So this is a really awesome tool called Wi-Fi Explorer. It's commercial, but if you want to play with Wi-Fi, it's good. It's not a hacking tool. It's more like an understanding tool. And this is their default view for the Wi-Fi spectrum. So the 2.4 gigahertz and 5 gigahertz spectrum. Actually, that bottom one was something a snapshot I took at the blackout keynote that Prishtabris gave. It's just an insane number of access points. And when you look at a picture like this, you get the idea that the 5 gigahertz spectrum is a little bit bigger than the 2 gigahertz spectrum. But in reality, the 2 gigahertz spectrum has three non-overlapping 20 megahertz channels. So if you put something on channel one and two, they technically overlap. But the 5 gigahertz spectrum has 24 non-overlapping channels. So what that means is if we were to draw this to scale, it looks a little more like this. There's way more 5 gigahertz spectrum available for Wi-Fi than there is 2.4 gigahertz. And so if you want to passively monitor all of that stuff before, you know, you could do things like hopping channels and stuff. Now if you're hopping through all of these channels, you're just going to miss lots of it. So instead you have to engage in the very practical and very good-looking attack like this. It's really great for Opsik. Clients, clients never see you coming. It's the pineapple on the top. It distracts them. So that's not hugely practical to try and get, figure out what devices are doing in the Wi-Fi around you. And we want to do it with that. You know, I'm from Africa, we're cheap. And so what we can do is we present ourselves as an access point. And wireless clients are already very good at finding access points and then broadcasting their management frames at them. So if we're an access point, then the devices come to us. We don't have to go to them and monitor all of the spectrum. And so this is why it's quite desirable to do some of these more active attacks rather than plain passive attacks for tracking purposes. The other thing that changed is devices are probing much less. For some reason we were a little present in 2014 with that. So we implemented something called Loud Mode, which provides an ability for manner and tools that use something similar to learn networks nearby and re-broadcast them. So maybe your device isn't actively probing for Bob's House of Pain, but your older iPad in your back pocket is or somebody you went there with last night is. And then we can learn that that's a network that somebody might be connecting to and re-broadcast it to your devices and learn either nearby networks. But the problem we end up with is anonymous devices. So manufacturers wanted to make it that you couldn't uniquely identify devices. So increasingly they use these randomized MAC addresses. And that's what you see flying around. Last year at Defcon Dent and Gentry or Gentry, I'm sorry if I'm butchering that, did some really cool work into creating unique signatures for Wi-Fi devices. And that got built into HostAP, which is predominantly what MAN is built off of. And so that gave us a really cool way of de-anonymizing devices. You probably can't tell, but I drew that myself. And let me give you a practical example of what that looks like. Thank you. I mean, this is the best part of the whole talk, just be careful. All right, so if we've got four devices, so we've got four MAC addresses and they're all probing for some non-unique network called Internet. So if they're probing for something unique, then maybe we could identify a device that because no other devices are probing for that. But these ones, we don't know what device is which. Now the one thing we've implemented in MANA is random device detection, so the output will mark whether something's a randomized MAC address or not. So if we put that stuff in there, and this is taken from an actual MANA output and imported into Maltigo, which makes this really easy. So we can see that there's two randomized MAC addresses and two non-randomized MAC addresses. So we can maybe start making some guesses that some belong to the other. We don't know which randomized probe belongs to which legit MAC address, and we don't even know that these randomized probes belong to those MAC addresses. So what we did is we took Denton's work and we extended it to generate the signatures also for devices before association, so that in MANA we can get these device signatures. So if we put that in there, this shows that there's two devices. So probe one and three belong to one device, and probe two and four belong to another device. So he did some really cool work and allows us to effectively de-anonymize devices. So things like Snoopy can work again because you've got something like Loud Mode getting them to advertise the networks they connect to, and then you've got signatures which allow you to de-anonymize the device, so you can start tracking individual devices again and be creepy. And I'm not showing you lots of detail about how to do that stuff because for a change I put a lot of work into documentation. And so like the host APD MANA Wiki's got a massive amount of information labeling all of the different configuration options and what they do and how to make it work. I'll give you links to these things at the end, so don't worry too much about taking pictures now. Okay, so that first scenario was talking about tracking and probing, and it's kind of well trod territory. We've made some changes there, but I didn't want to spend too much time on it. So next we're going to look at enterprise networks, so these are EAPTLS kind of things that most people are running at companies. And so this is the domain where something like host APDWPE, Wireless Purnage Edition has traditionally done its work. MANA was also doing some of this stuff in 2014. We've made some changes there. The nice thing about having both of this capability in MANA is you can get lots of devices to connect to you and you can also get lots of passwords from devices. So being good at getting devices to connect you also helps for this part. All right, so the most common implementation is the Evil Twin attack. So this is Spock's Evil Twin from the Mirror universe. And Evil Twin attack, you create an access point that looks the same as the legit access point that you want to go after. And like when people talk about it, they mostly say, yeah, that's all you do. You just make another access point. But in reality, you've got fancy enterprise access points that implement all sorts of crazy 802.11ac stuff really well with well engineered antennas well placed in the ceiling. And you're walking around with like a dinky alpha card in your backpack. You're probably not going to beat the enterprise AP. So what often happens is then people do things like the orths. And so people start implementing management frame protection 802.11w and this becomes much harder. So actually the way I'd recommend you do this is go buy a fancy enterprise access point like a Ruckus or Naruba. And then you can use Manor as just a plain back end radio server and it'll actually capture the creds there. Now this is something that's already implemented in host APWPE. And if any of you familiar with Celeste Barba, so she takes pictures of celebrities and then she kind of rips them off. And it's pretty hysterical. Most of them are her awkwardly wearing underpants. So this was the least awkward one I could find. So we're the Celeste Barba to host APWPE with Manor. So Brad Antonievich, Joshua Wright in 2008, they released the free radius WP in the sleep tools, which sort of were the first attacks against EAP networks where you could capture credentials and crack them. So that stuff's been in Manor for a while. I've cleaned it up, cleaned the output up. People kept sending me rude messages saying I have to hand carve things into hash cat and stuff and I'll just display it right. What I've also done is I've extended it so it does more EAP modes. So at the moment it does about 13 different EAP modes. It'll try and capture credits, plain text, CHAP, MS CHAP, MS CHAP version 2, GTC, things like that. And about seven of those fairly well tested in real client environments and that's working quite well. But we did some other stuff too that I want to take you through. So here's another back of the napkin drawing I attempted to describe how EAP connections work. So the first thing that happens is a Wi-Fi connection if you're familiar with Air Replay, if you do a fake auth, that's that first part. And then these tunneled EAPs, so people, TTLS, their security comes from this TLS session that it creates. So the idea is we use best practice TLS stuff and then we can do crappy MS CHAP inside that tunnel because it's protected by TLS. Now the sort of fundamental flaw in all of this, and I'll cover in a bit more detail now, is that we don't have a very good way of validating certificates in the wireless world. And I'll get into that in a second. And so then you've got this MS CHAP challenge response. Now MS CHAP version 2 provides a method for approving that the access point knows the password and proving that the client knows the password. So what we did in 2014 is we did this auto-crack and add thing so that if you capture the password, it'll try and crack it. And if it's weak enough, you can quickly add it to the radius users file. If the device tries to reconnect, you can then also man in the middle then. But then Brad in hostAPDWPE implemented something he called EAP success. So instead of doing that, because the access point can't prove that it knows the password, if it hasn't cracked it, it would just send an EAP success method back. And I thought this was silly because why would that work? And then Michael kept telling me I must make it work and he wouldn't let up, really wouldn't let up. And so I eventually spent a hot evening digging through code trying to figure this out. And what actually turns out is that all Mac and iOS devices have a broken implementation. So they won't validate that the access point actually knows the password if you send an EAP success. They'll just be like, okay, sure, I'll connect. So it's, I mean, from iOS 9, I've tested it on iOS, my latest one on here, my latest Mac OS. I've reported it to Apple. We kind of had the discussion on Twitter. So, and Brad had built this functionality ages ago. So it's not really a zero day, but it's an interesting thing to know. So you don't need to use things like autocrack and add with iOS. They'll just connect. And then the other thing is the certificate validation problem. So on the left hand side is the legitimate certificate chain for Defcon's Wi-Fi certificate. And on the right hand side is a cloned version of that chain that I built using a colleague of mine, Rogan Dawes, this tool called Appasteele, which is good for cloning certificate chains rather than just an individual certificate. And now on something like iOS and some other supplicant devices, if you connect to a Wi-Fi network, it'll pop up the certificate. And it could be signed by a valid cert authority and it'll still pop up the certificate for you to hand validate. So if I saw the certificate on the right and it had all the Defcon things, everything looks exactly the same except for the fingerprint because the hashes are going to come out differently. And humans aren't very good at memorizing long strings of hashes. So for things that try and force you to validate on the actual certificate, that becomes problematic if you aren't doing automated rollout to client devices. And even then, if you are doing automated rollout to client devices, we've got this problem with IT where client devices tend to stop being compliant to your policies and you always end up with that one MSO8067 or that one fully configured supplicant. Then on the flip side, there's a bunch of supplicants which will validate on the CA, the certificate authority. So WPA supplicant used in Linux and Android does that. Windows default configuration will do that. And so here you can see that Defcon bought a certificate from DigiCert. So I can go spend $150. I mean, they know let's encrypt exists, right? And then I can buy a certificate with the same CA. It doesn't have to be a Defcon certificate. I can present that on my rogue access point and devices will connect to it. I tested just to make sure I wasn't going crazy. I used Defcon's configuration and compete with your username and your password all in bold, put up my rogue access point and the things happily connected to it. So that, and there's no option in WPA supplicant at the moment to validate on the actual certificate, which is kind of stupid. And in Windows, you've got an option to validate on the actual hostname. So you can see it's wifi-redge.defcon.org. I can't buy a certificate for Defcon.org domain. So if you validate on the actual server name like Defcon instructed you to, then actually Windows is in a pretty good place. And for iOS, they pushed out, yeah, there's only one guy. I hope Microsoft's paying you well. And then for iOS, they pushed out a mobile profile like an MDM profile, basically Apple configuration profile to validate on the exact search, which works quite well, although I fat-fingered it and I've not been able to connect to the wifi. So we've got this problem with wifi search. So if any of you saw Prishtor Brzez's keynote at Black Hat and she was talking about how they're trying to get rid of SSL or HTTP pages and they've got this consistent set of iconography, I was thinking what a nice problem they have, like when your problem is just trying to get people to do something everyone knows they should and you need to make some icons more consistent. Wifi devices don't even have a consistent way of validating service certificates. I mean, we're in a pretty bad place there. And all of this is just talking about if somebody's actually trying to put effort into validation, because most of us and most users will click on the wifi network, type in your username and password, and yell whatever the certificate. Okay, but the general recommendation is to use something like EAPTLS. So again, very advanced diagram of EAPTLS. And what EAPTLS does is it does away with the certificates, I mean the passwords, and you just have certificates. It's mutual authentication, so you've got a client certificate and you've got a service certificate. Yay, it's fixed. We'll just use EAPTLS. Except the problem is with normal TLS, you create an encrypted tunnel and then the communications can continue. In wifi, it's a kind of a once-off authentication. Afterwards, the tunnel's torn down, then you have the WPA2A handshake and the normal wifi stuff. So what that means is if the client is not validating the service certificate, then you can just accept whatever certificate it sends you and, yay, now you're man in the middling EAPTLS. So EAPTLS isn't necessarily a fix for this. As a matter of fact, it comes down to the exact same security decision as people, TLS decisions. It's a single certificate validation of the service certificate. So all of that problem with the service, with certificate validation and wifi kicks back in. So this was actually implemented in Manon 2015 by Meatballs, thanks guy. And then I broke it, sorry. And then I fixed it again about a month ago. So that works again. Okay, but then Michael one day was cracking some wifi hashes and he noticed that hashcat, let me go here for the moment, hashcat uses mode 5500 I think for cracking MS Chap hashes, which is also NTLMv1 ESS. And he thought, hey, there's this NTLM relay thing. Maybe I could do like an MS Chap relay. And so he came up with what he's calling Sikafant. It's a play on supplicant. And so the idea is that you can have two separate devices. You can have Manor being a rogue access point, negotiating a session with a victim device. And then you can have WPS Sikafant negotiating a session with a legitimate target access point. So those two don't need to be physically near each other. They just need internet connection. So you can be targeting someone at their house and then have the other thing at the target organization. And what's really nice about this is you don't have to crack the password. So if it's a harder password to crack and it's going to take a little longer, you still get connected to the network fairly instantly. And so Michael's going to give you a demo of what that looks like. And we're going to release that toolset today. Thank you, Dominic. So I've broken this demo down into three parts. The first two parts do happen simultaneously because the two things need to be happening at the same time. But the first part is I'm just going to show you what Manor looks like when it's pretending to be the corporate AP. And then the second part is a supplicant retrieving the required information from Manor to connect to the legitimate corporate AP. So in this scenario, we can imagine that there's a chap at home. He's got his device for the BYOD network that also uses domain creds. So if we just relay this thing, we should be able to connect to the normal AP or the normal legit corporate domain. So here's the command for running Manor. This we put on a pie and throw it in his garden. And hopefully our access point is stronger than his little router that he got from his internet service provider. And hopefully he's not got any of the certificates properly pinned and those sorts of things. So I'm just gripping out the relevant information. Otherwise there's a lot of noise. So I'm just gripping for Sikafant and Manor. I've added a config option to Manor to say enable Sikafant, which just instructs it to not use, to not generate, well, it still generates a challenge, but to not use that challenge rather retrieve a challenge from my supplicant, Sikafant. So let me be past to the client. So I just run this and we wait for the chap to connect. Here they've initiated a connection with us. So the phase one identity and the phase two identity, phase one establishes that outer tunnel, phase two is starting the actual EAP, the MS chap handshake. There is a delay after this because now Sikafant is starting up on the other side and is trying to play catch up. So we're quickly connecting to the actual corporate AP and getting the challenge which is then passed to Manor to present to the client so that we may get a valid response. As you can see here, it's retrieved the first auth challenge contents is what host APD, our rogue generated, but we don't want to use that one. So there's auth challenge contents after copy, which it's actually gone from the legit access point. We send that to the client, John in his bedroom and his phone has decided that our access point looks more appealing. So it knows the password, it generates a response using our hash. Manor takes that response, writes it down to a file and essentially passes it on to my Sikafant. And we get the hash anyway in case we want to crack it later. So then next we have the other half of this equation, which is my Sikafant, WPA Sikafant. I'm running it using the adapter ending in U6 thanks to the new naming convention. Once again, grepping out the relevant data and I'm also grepping for an EAP failure, which just to show that there's not one. So we run it, oh, in the config is now, so this is now happening near in proximity, in close proximity to the, an actual legit corporate AP because we want to connect to it. So this portion has to run close to your client. So then you just put where you want to connect to in the config file using the standard Sikafant, well, supplicant syntax and we don't need creds, so we leave those blank. Cool. So what we got here is phase one came in, phase two came in and supplicant immediately, well, Sikafant immediately starts to connect to the access point. It gets the challenge data, passes the challenge data to Manor and waits for the response. Manor at this point has been waiting for a little while, the client's been waiting for a little while, the client's been waiting for the response, so they immediately come back with the response. See here, Manor contents. Cool, take that response, we pass it off to the access point, the access point goes, okay, cool, you showed me, you know the password, EAP success, you're done, now you're connected. Brilliant. I specifically didn't run DHCP this time just to show this bit where we don't have an IP address, we have a basic client just to get an IP, this is just to prove that we do have full comms to the network I connected to. Again, IP of 10.0.0.5, I double check it, and then I attempt to connect to a service or server on the client's network. I go back because I'm lazy and I copy it, but yeah, essentially I'm going to connect to a web server on 8080, and we automatically just connect to people's Wi-Fi. Cool, thank you very much. So yeah, we're going to release that stuff today, WPSSIP of sick offense in the Mods to Manor, so that you can do this attack yourself. Michael's used it successfully on some of our client's engagements, so it's a practical working attack on some live environments. Then to the most important part, coming up with a name, Michael sent me this image, which was deeply disturbing. Which we later found out was called Squirtle Boy, which was, I'm not sure it made it less disturbing. So this is why we really want Michael to be known as Squirtle Boy from now on. So interestingly, back in 2002, I'm never going to get these names, right? Let me look them up on my phone here. So Enos Sakan with Nyemi and Nyberg wrote a paper in 2002 about Malarying the Middle Tunnelled Authentication Modes, and from that, the IETF spec for this thing in 2004 made short included a section on defending against these attacks. So if you zoom in, there's something called cryptographic binding or crypto binding. And the point of crypto binding is to make sure that some of the keying material used in the outer TLS session is used in the inner EAP method so that they can be, you know that the same device, that relaying isn't happening. So it's always disappointing to implement an attack and think you're the first and then find out that the standards had a defense against it for over a decade. On the flip side, people don't seem to be turning on crypto binding, and we think that's really just because of a lack of practical attacks. That said, thanks to Synchronicity, we were definitely not the first. So in 2014, Peter Robbins released a similar sort of an attack, but it was against a specific thing that Apple was doing, I think something around Leap in a WISEC paper in 2014, which Apple then fixed. So it wasn't a full implementation. And then this morning, 15 minutes before we woke up, somebody logged an issue against Manor, asking for this as a feature request and linking to a paper that had been written in 2016 and sent to the FOSTA mailing list by Ciarre Siniak. I'm so sorry for butchering that name. And so he also has a partial implementation. It was done against the EAP state machine in host AP and WPS applicant. But as far as we could tell, it's not a full working practical implementation just yet. So we think this is the first practical implementation of this attack that can be used by people. And so because there's no practical implementation of the attack or certainly not a widely known one, what you see is that the default configs for a lot of networks don't turn on crypto binding. So here's a picture of Microsoft's radio server configuration. And by default, they will not disconnect clients that don't have crypto binding. So because this is something that needs to be done on the client side, the access to the radio server can detect whether it's been done and disconnect clients, which makes it slightly less usable, I guess, but a bit more secure. So maybe that's why they didn't do it there, is they don't want to make it harder for people to get on the network. But here's a fully updated Windows 10 default connection dialog, and their crypto binding is not enabled either. Host AP tries to do some crypto binding by default. So there are some places where they try to do it, but most people aren't running host AP networks in their enterprise organizations. So for the most part, crypto binding doesn't seem to be turned on. You can go turn on crypto binding, but I think the biggest defense against these sorts of attacks is just to make sure that your client devices are properly validating the server certificate that gets presented. Because if that's done, then this part doesn't matter too much, because they won't get past the tunneled, the outer TLS negotiation, because they'll say, that's not the right access point. You're fake. All right. Okay, so those first two scenarios is once the first one was getting a bunch of devices to connect to you and being able to figure out which device is doing what, and the second one was doing EAP attacks. Oh, sorry, one other thing is you would have seen a hash cat and Atom's PMK ID thing. Anyone who's interested in WPA2 handshake cracking, put some basic stuff in just to try, like if a client ever sends a PMK ID to just log that into the same file, I need to do way more testing to see if it's a practical attack from a rogue access point perspective. But that might be fun. Okay, so now we're going to look at some Mitom stuff. So back in 2014, we released the Manor Toolkit, and the idea there was lots of people take and then you can Mitom as, you know, for granted. But the reality was, if particularly if you're new to this, you have to sort of orchestrate networking and access point stuff and protocol stuff, and that can be quite a lot to do. And then with the increase in certificate pinning and things like HSTS, sorry, I'm just... Hmm, it's about to get breathy. With things like certificate pinning and HSTS, it's not sort of a given that you're going to be able to man in the middle all the things and get all of the passwords. So the big problem we ran into with Manor Toolkit is the ability to construct pipelines. We were using IP tables to redirect traffic from one place to another place. So for example, you can SSL strip something, but you can't then pass the traffic through to SSL split. Maybe there's some IP tables gurus in here who can show us how to do it, but it wasn't pleasant. And then along came BetterCap. So BetterCap written by EvilSocket in Go, it can do all of this stuff, and it's really fantastic. Initially, we wanted to get EvilSocket up on the stage to talk about some of this stuff, but he's got a whole bunch of really cool Wi-Fi attack things built into BetterCap. So if you want to do captive portal attacks, or you want to beef hook browsers through your Mitten, all sorts of other things, then you can now do that with BetterCap. So we're just effectively deprecating Manor Toolkit and saying, use BetterCap, it's better. And just a big shout out to EvilSocket for the awesome work he's done in there. I know based on the issues that get logged, that guy takes some bullets. The other problem you face is trying to orchestrate setting up a network and all the network, well, the Wi-Fi network and all of the networking. Okay, so I'm seeing people waving hands. And Michael found a cool tool written and maintained by a guy named Obliq called CreateAP, and what this does is just makes it really easy to say, create an access point and bridge it between this network and this network or NAT it. Without all of the sort of complexity that Manor Toolkit brought in. However, there were some things that it didn't do. It doesn't allow you to create EAP networks, certainly doesn't allow you to do Manor modes, and it doesn't allow you to create more than one Wi-Fi network. Sometimes you might want to create more than one Wi-Fi network because probes don't say what kind of security principle they're connecting to, but you might want to present an open PSK and EAP network and see which one it connects to. So Michael made CreateAP, which is a fork of CreateAP that can do all of these things, it's something else we're releasing today. So it does all that networking and access point orchestration for the most obvious ways in which you would use Manor Toolkit to do this stuff. If you want to get into the detail of all the other config options, then you can handcraft your own config files and do it that way. You can do it all up in the Wiki, but this just makes life much easier. So that's an example, ignore the dash N at Creptin there. But this is an example of setting up a Manor EAP malicious access point. That's if you don't have the dash N, netting traffic from WLAN 0 to S0 called EvilCorp. If any of you use Manor Toolkit to edit some of the scripts, this is way easier than any of the stuff we did before. Okay, and then there's also a bunch of really cool proportionality options that have been built into Manor. See, it's a sniper rifle proportionality. So by default Manor is a bit of a flamethrower. Like it'll just target every device it sees and any network it sees. But if you're on an engagement where you've got specific scope, you might want to limit it to specific devices or specific networks. Or if you're in law enforcement or something and you've got a specific mandate, you might want to limit what it does. So we built a bunch of options in there like SSID filters that was contributed by a guy named CyberDevil. But one of the things that we think is really cool is we extended MAC ACLs down to a management frame level. So any of you should be familiar with the way MAC address ACLs work on Wi-Fi. You know, your home router does it. You can say only these MAC addresses can connect. You can see the AP, but if you try and connect and you're not in there, you'll get rejected. So we brought that down to management frame level. So if the access point receives a probe request, sorry, if the management, if the access point receives a probe request from a disallowed MAC address, then it's not even going to respond to the probe request. So that means for the most part it won't even show up in their list of available networks. Also provide some ability to kind of hide from people who might be looking for these devices or wireless intrusion prevention systems. We think it's quite cool. And then I borrowed a concept from the Aircraft guys. They've got this idea of binary net masks so that you can kind of mask out certain bits in a MAC address. So you can do things like anything with this OUI, you know, any of these devices can connect, but these can't. But it also allows you to do things like for randomized MAC addresses, go full manner on them. But when they try and connect, be a little more circumspect about checking what the MAC address is. So it's a really flexible way of dealing with different MAC addresses. And then lastly, if you want to get into Wi-Fi hacking, it's really difficult to practice. On the one hand, you've got to buy hardware, you've got to make sure that chipset works with what you're doing. So for example, those new black alphas, the chunky ones, those things, because they're doing more stuff in firmware, you can't use manners, probe manipulation stuff, the radio stuff will work, but not those things. So you've got to make sure you get the right hardware. And then also it's really difficult to kind of not target people you don't mean to. You know, you might be testing between your two devices, but it's meanwhile, it's like men in the middling somebody next door. Anytime somebody is playing with the stuff in the office, we just plug into the wired network because it's like dossing the Wi-Fi. I've even had really weird situations in busy environments where it ends up kind of dossing Bluetooth, which is kind of strange. So in 2014, we built some CTFs in AWS where you could practice Wi-Fi hacking, which we're kind of proud of because Wi-Fi in the cloud is a thing now. And today we're going to release some Docker images that let you, well, the moment is one Docker image, but hopefully some more Docker images in the future that allow you to practice some of these things. So you don't need any hardware. It's not going to target any live environments. And you've got some kind of known completion criteria so you can make sure that you're able to run these commands and they work. So that's actually Michael in the picture there, if you look carefully. And Michael's a Kendo nerd and he told me that these wooden swords are called Chenise. So hardest problem in computer science naming things. So I'm calling the environment Chenifi. And I'm just going to show you a little silly demo of what that looks like. So here's the Docker container running on my Mac. And there's a whole other story about, so if you're running Docker for Mac, just don't try and do this on that. There are ways, but like I'm currently was asked to politely take that stuff down by Docker. So rather do it on your Kali's or your Linux boxes because it needs certain kernel modules. But okay, so here's the Docker container. It doesn't have anything, any hardware plugged into it. So if we look, there's a WLAN zero, which means there's a Wi-Fi device. And if you use Airmon, you'll see that that's a software simulator of 802.11 radios. There's this kernel module Mac 802.11 hw sim, which allows you to simulate fake Wi-Fi devices that can connect to each other. And so if you then run, if you put one of those devices into monitor mode, we've got some sticky tape and chewing gum in the background, which tries to figure out when you're doing these things. So if you run error dump, you'll actually see Wi-Fi networks and devices that are there. Again, no hardware. These aren't real things. There's a WPA handshake. So you can try and capture that handshake. If you bring up a MANA network, you'll see clients trying to connect to you. You can capture those credentials and crack them. And you can do all of this without needing any actual hardware. So yeah, we're going to release that Docker image. You can just Docker pull it, run it, and away you go. And that's kind of the end of our talk. So we're going to, I bought a domain called Wi-Fi.net, but with ones, w1f1.net. So a little bit later after this, somebody will lend me a computer. Thanks, guys. I'm going to push all of the tools we mentioned up there so that you can grab it. So don't be disappointed if you do it right now. Try and go to the children and do it. And we also just want to use that as a bit of a repository for kind of how to do these attacks and which tools are working, keep updating that as time goes. And maybe if some of you are playing with things in this room and it's going, well, you can send pull requests or write wiki things for up there. Otherwise, you can tell us you hated the talk on Twitter. So I'm at syng.com, and he's underscore cable thief. We're going to check if Squirtle Boy is available. And we're from Sandspost. So thank you very much for your time and patience. Thank you.
 Send in cable thief.  Hello everyone.  So this is the first time I've spoken out loud for like a day and a half because I lost my voice and I've been walking around like a  breathy Hannibal Lecter. So if I suddenly start squeaking like a teenage boy, please forgive me. I'm just gonna be sucking on this thing.  So today we're gonna be talking about some Wi-Fi hacking stuff. In particular,  we're gonna be talking about rogue access point attacks or evil access point attacks or whatever you feel like calling them.  And it's a kind of a continuation of a talk that we did in 2014. We released something called the MANNER toolkit.  So the way we're gonna talk about stuff is there's three scenarios and you might not be doing  exactly what the scenario is describing, but I'm just using them as examples to kind of go through some of the capabilities, tools and techniques  that we'll be releasing today.  So my name's Singh. This is Michael Kruger  underscore cable thief, but we're trying to call him Squirtle Boy. So if you're looking to  give him a nickname, please help us out there. We work at a company called SENS Post.  It's a penetration testing company based predominantly out of South Africa and London. We've been going for about 18 years.  We were told we weren't allowed to use PowerPoint. So this is a PDF. That used to be an animated gift in the corner.  So  yeah, all right. So the first scenario we're gonna jump straight in.  In 2012, a colleague of mine, Glenn Wilkinson and Daniel Cuthbert released something called Snoopy. Anyone here ever use Snoopy?  Three people. Cool.  Sorry?  Sorry, I can't hear you.  So Snoopy was a framework for tracking wireless devices.  I'm trying to geolocate them based on networks that they were looking for and then using the fact that the device ID was unique.  Fortunately in 2018, Snoopy is dead.  Yeah, they killed Snoopy.  And  the primary reason Snoopy is dead is because  there's been some changes to the way device manufacturers make their things work across Wi-Fi.  So the first thing is that passive sniffing is mostly doesn't work anymore.  It's what two reasons are going to now.  And the other thing is that device manufacturers have changed the default behavior that instead of a device going,  hey, is my home network nearby?  It just says, hey, are there networks nearby and is one of them my home network?  So it does it tries not to reveal the networks it's looking for and its preferred network list.  But I first spoke about the spectrum issue. So  this is a really awesome tool called Wi-Fi Explorer. It's commercial, but if you want to play with Wi-Fi, it's good.  It's not a hacking tool. It's more like an understanding tool.  And this is their default view for the Wi-Fi spectrum. So the 2.4 gigahertz and 5 gigahertz spectrum.  Actually, that bottom one was something a snapshot I took at the blackout keynote that Prishtabris gave.  It's just an insane number of access points. And when you look at a picture like this,  you get the idea that the 5 gigahertz spectrum is a little bit bigger than the 2 gigahertz spectrum.  But in reality, the 2 gigahertz spectrum has three non-overlapping 20 megahertz channels.  So if you put something on channel one and two, they technically overlap.  But the 5 gigahertz spectrum has 24 non-overlapping channels.  So what that means is if we were to draw this to scale, it looks a little more like this.  There's way more 5 gigahertz spectrum available for Wi-Fi than there is 2.4 gigahertz.  And so if you want to passively monitor all of that stuff before,  you know, you could do things like hopping channels and stuff. Now if you're hopping through all of these channels,  you're just going to miss lots of it.  So instead you have to engage in the very practical and very good-looking attack like this.  It's really great for Opsik. Clients, clients never see you coming.  It's the pineapple on the top. It distracts them.  So that's not hugely practical to try and get,  figure out what devices are doing in the Wi-Fi around you. And we want to do it with that.  You know, I'm from Africa, we're cheap.  And so what we can do is we present ourselves as an access point.  And wireless clients are already very good at finding access points and then broadcasting their management frames at them.  So if we're an access point, then the devices come to us. We don't have to go to them and monitor all of the spectrum.  And so this is why it's quite desirable to do some of these more active attacks rather than plain passive attacks for tracking purposes.  The other thing that changed is devices are probing much less.  For some reason we were a little present in 2014 with that.  So we implemented something called Loud Mode, which provides an ability for manner and tools that use something similar to learn networks nearby and re-broadcast them.  So maybe your device isn't actively probing for Bob's House of Pain,  but your older iPad in your back pocket is or somebody you went there with last night is.  And then we can learn that that's a network that somebody might be connecting to and re-broadcast it to your devices and learn either nearby networks.  But the problem we end up with is anonymous devices.  So manufacturers wanted to make it that you couldn't uniquely identify devices.  So increasingly they use these randomized MAC addresses.  And that's what you see flying around.  Last year at Defcon Dent and Gentry or Gentry, I'm sorry if I'm butchering that,  did some really cool work into creating unique signatures for Wi-Fi devices.  And that got built into HostAP, which is predominantly what MAN is built off of.  And so that gave us a really cool way of de-anonymizing devices.  You probably can't tell, but I drew that myself.  And let me give you a practical example of what that looks like.  Thank you.  I mean, this is the best part of the whole talk, just be careful.  All right, so if we've got four devices, so we've got four MAC addresses and they're all probing for some non-unique network called Internet.  So if they're probing for something unique, then maybe we could identify a device that because no other devices are probing for that.  But these ones, we don't know what device is which.  Now the one thing we've implemented in MANA is random device detection, so the output will mark whether something's a randomized MAC address or not.  So if we put that stuff in there, and this is taken from an actual MANA output and imported into Maltigo, which makes this really easy.  So we can see that there's two randomized MAC addresses and two non-randomized MAC addresses.  So we can maybe start making some guesses that some belong to the other.  We don't know which randomized probe belongs to which legit MAC address, and we don't even know that these randomized probes belong to those MAC addresses.  So what we did is we took Denton's work and we extended it to generate the signatures also for devices before association, so that in MANA we can get these device signatures.  So if we put that in there, this shows that there's two devices.  So probe one and three belong to one device, and probe two and four belong to another device.  So he did some really cool work and allows us to effectively de-anonymize devices.  So things like Snoopy can work again because you've got something like Loud Mode getting them to advertise the networks they connect to,  and then you've got signatures which allow you to de-anonymize the device, so you can start tracking individual devices again and be creepy.  And I'm not showing you lots of detail about how to do that stuff because for a change I put a lot of work into documentation.  And so like the host APD MANA Wiki's got a massive amount of information labeling all of the different configuration options and what they do and how to make it work.  I'll give you links to these things at the end, so don't worry too much about taking pictures now.  Okay, so that first scenario was talking about tracking and probing, and it's kind of well trod territory.  We've made some changes there, but I didn't want to spend too much time on it.  So next we're going to look at enterprise networks, so these are EAPTLS kind of things that most people are running at companies.  And so this is the domain where something like host APDWPE, Wireless Purnage Edition has traditionally done its work.  MANA was also doing some of this stuff in 2014. We've made some changes there.  The nice thing about having both of this capability in MANA is you can get lots of devices to connect to you and you can also get lots of passwords from devices.  So being good at getting devices to connect you also helps for this part.  All right, so the most common implementation is the Evil Twin attack.  So this is Spock's Evil Twin from the Mirror universe.  And Evil Twin attack, you create an access point that looks the same as the legit access point that you want to go after.  And like when people talk about it, they mostly say, yeah, that's all you do. You just make another access point.  But in reality, you've got fancy enterprise access points that implement all sorts of crazy 802.11ac stuff really well with well engineered antennas well placed in the ceiling.  And you're walking around with like a dinky alpha card in your backpack.  You're probably not going to beat the enterprise AP.  So what often happens is then people do things like the orths.  And so people start implementing management frame protection 802.11w and this becomes much harder.  So actually the way I'd recommend you do this is go buy a fancy enterprise access point like a Ruckus or Naruba.  And then you can use Manor as just a plain back end radio server and it'll actually capture the creds there.  Now this is something that's already implemented in host APWPE.  And if any of you familiar with Celeste Barba, so she takes pictures of celebrities and then she kind of rips them off.  And it's pretty hysterical. Most of them are her awkwardly wearing underpants.  So this was the least awkward one I could find.  So we're the Celeste Barba to host APWPE with Manor.  So Brad Antonievich, Joshua Wright in 2008, they released the free radius WP in the sleep tools,  which sort of were the first attacks against EAP networks where you could capture credentials and crack them.  So that stuff's been in Manor for a while.  I've cleaned it up, cleaned the output up.  People kept sending me rude messages saying I have to hand carve things into hash cat and stuff and I'll just display it right.  What I've also done is I've extended it so it does more EAP modes.  So at the moment it does about 13 different EAP modes.  It'll try and capture credits, plain text, CHAP, MS CHAP, MS CHAP version 2, GTC, things like that.  And about seven of those fairly well tested in real client environments and that's working quite well.  But we did some other stuff too that I want to take you through.  So here's another back of the napkin drawing I attempted to describe how EAP connections work.  So the first thing that happens is a Wi-Fi connection if you're familiar with Air Replay, if you do a fake auth, that's that first part.  And then these tunneled EAPs, so people, TTLS, their security comes from this TLS session that it creates.  So the idea is we use best practice TLS stuff and then we can do crappy MS CHAP inside that tunnel because it's protected by TLS.  Now the sort of fundamental flaw in all of this, and I'll cover in a bit more detail now,  is that we don't have a very good way of validating certificates in the wireless world.  And I'll get into that in a second.  And so then you've got this MS CHAP challenge response.  Now MS CHAP version 2 provides a method for approving that the access point knows the password and proving that the client knows the password.  So what we did in 2014 is we did this auto-crack and add thing so that if you capture the password, it'll try and crack it.  And if it's weak enough, you can quickly add it to the radius users file. If the device tries to reconnect, you can then also man in the middle then.  But then Brad in hostAPDWPE implemented something he called EAP success.  So instead of doing that, because the access point can't prove that it knows the password, if it hasn't cracked it, it would just send an EAP success method back.  And I thought this was silly because why would that work?  And then Michael kept telling me I must make it work and he wouldn't let up, really wouldn't let up.  And so I eventually spent a hot evening digging through code trying to figure this out.  And what actually turns out is that all Mac and iOS devices have a broken implementation.  So they won't validate that the access point actually knows the password if you send an EAP success.  They'll just be like, okay, sure, I'll connect.  So it's, I mean, from iOS 9, I've tested it on iOS, my latest one on here, my latest Mac OS.  I've reported it to Apple. We kind of had the discussion on Twitter.  So, and Brad had built this functionality ages ago. So it's not really a zero day, but it's an interesting thing to know.  So you don't need to use things like autocrack and add with iOS. They'll just connect.  And then the other thing is the certificate validation problem.  So on the left hand side is the legitimate certificate chain for Defcon's Wi-Fi certificate.  And on the right hand side is a cloned version of that chain that I built using a colleague of mine,  Rogan Dawes, this tool called Appasteele, which is good for cloning certificate chains rather than just an individual certificate.  And now on something like iOS and some other supplicant devices, if you connect to a Wi-Fi network, it'll pop up the certificate.  And it could be signed by a valid cert authority and it'll still pop up the certificate for you to hand validate.  So if I saw the certificate on the right and it had all the Defcon things, everything looks exactly the same except for the fingerprint  because the hashes are going to come out differently. And humans aren't very good at memorizing long strings of hashes.  So for things that try and force you to validate on the actual certificate, that becomes problematic if you aren't doing  automated rollout to client devices. And even then, if you are doing automated rollout to client devices,  we've got this problem with IT where client devices tend to stop being compliant to your policies and you always end up with that one MSO8067  or that one fully configured supplicant. Then on the flip side, there's a bunch of supplicants which will validate on the CA,  the certificate authority. So WPA supplicant used in Linux and Android does that.  Windows default configuration will do that. And so here you can see that Defcon bought a certificate from DigiCert.  So I can go spend $150. I mean, they know let's encrypt exists, right?  And then I can buy a certificate with the same CA. It doesn't have to be a Defcon certificate.  I can present that on my rogue access point and devices will connect to it.  I tested just to make sure I wasn't going crazy. I used Defcon's configuration and compete with your username and your password all in bold,  put up my rogue access point and the things happily connected to it.  So that, and there's no option in WPA supplicant at the moment to validate on the actual certificate, which is kind of stupid.  And in Windows, you've got an option to validate on the actual hostname.  So you can see it's wifi-redge.defcon.org. I can't buy a certificate for Defcon.org domain.  So if you validate on the actual server name like Defcon instructed you to, then actually Windows is in a pretty good place.  And for iOS, they pushed out, yeah, there's only one guy.  I hope Microsoft's paying you well.  And then for iOS, they pushed out a mobile profile like an MDM profile, basically Apple configuration profile to validate on the exact search,  which works quite well, although I fat-fingered it and I've not been able to connect to the wifi.  So we've got this problem with wifi search. So if any of you saw Prishtor Brzez's keynote at Black Hat  and she was talking about how they're trying to get rid of SSL or HTTP pages and they've got this consistent set of iconography,  I was thinking what a nice problem they have, like when your problem is just trying to get people to do something everyone knows they should  and you need to make some icons more consistent.  Wifi devices don't even have a consistent way of validating service certificates.  I mean, we're in a pretty bad place there.  And all of this is just talking about if somebody's actually trying to put effort into validation,  because most of us and most users will click on the wifi network, type in your username and password, and yell whatever the certificate.  Okay, but the general recommendation is to use something like EAPTLS.  So again, very advanced diagram of EAPTLS.  And what EAPTLS does is it does away with the certificates, I mean the passwords, and you just have certificates.  It's mutual authentication, so you've got a client certificate and you've got a service certificate.  Yay, it's fixed. We'll just use EAPTLS.  Except the problem is with normal TLS, you create an encrypted tunnel and then the communications can continue.  In wifi, it's a kind of a once-off authentication.  Afterwards, the tunnel's torn down, then you have the WPA2A handshake and the normal wifi stuff.  So what that means is if the client is not validating the service certificate,  then you can just accept whatever certificate it sends you and, yay, now you're man in the middling EAPTLS.  So EAPTLS isn't necessarily a fix for this.  As a matter of fact, it comes down to the exact same security decision as people, TLS decisions.  It's a single certificate validation of the service certificate.  So all of that problem with the service, with certificate validation and wifi kicks back in.  So this was actually implemented in Manon 2015 by Meatballs, thanks guy.  And then I broke it, sorry.  And then I fixed it again about a month ago.  So that works again.  Okay, but then Michael one day was cracking some wifi hashes and he noticed that hashcat,  let me go here for the moment, hashcat uses mode 5500 I think for cracking MS Chap hashes,  which is also NTLMv1 ESS.  And he thought, hey, there's this NTLM relay thing.  Maybe I could do like an MS Chap relay.  And so he came up with what he's calling Sikafant.  It's a play on supplicant.  And so the idea is that you can have two separate devices.  You can have Manor being a rogue access point, negotiating a session with a victim device.  And then you can have WPS Sikafant negotiating a session with a legitimate target access point.  So those two don't need to be physically near each other.  They just need internet connection.  So you can be targeting someone at their house and then have the other thing at the target organization.  And what's really nice about this is you don't have to crack the password.  So if it's a harder password to crack and it's going to take a little longer,  you still get connected to the network fairly instantly.  And so Michael's going to give you a demo of what that looks like.  And we're going to release that toolset today.  Thank you, Dominic.  So I've broken this demo down into three parts.  The first two parts do happen simultaneously because the two things need to be happening at the same time.  But the first part is I'm just going to show you what Manor looks like when it's pretending to be the corporate AP.  And then the second part is a supplicant retrieving the required information from Manor to connect to the legitimate corporate AP.  So in this scenario, we can imagine that there's a chap at home.  He's got his device for the BYOD network that also uses domain creds.  So if we just relay this thing, we should be able to connect to the normal AP or the normal legit corporate domain.  So here's the command for running Manor.  This we put on a pie and throw it in his garden.  And hopefully our access point is stronger than his little router that he got from his internet service provider.  And hopefully he's not got any of the certificates properly pinned and those sorts of things.  So I'm just gripping out the relevant information.  Otherwise there's a lot of noise.  So I'm just gripping for Sikafant and Manor.  I've added a config option to Manor to say enable Sikafant, which just instructs it to not use, to not generate,  well, it still generates a challenge, but to not use that challenge rather retrieve a challenge from my supplicant, Sikafant.  So let me be past to the client.  So I just run this and we wait for the chap to connect.  Here they've initiated a connection with us.  So the phase one identity and the phase two identity, phase one establishes that outer tunnel,  phase two is starting the actual EAP, the MS chap handshake.  There is a delay after this because now Sikafant is starting up on the other side and is trying to play catch up.  So we're quickly connecting to the actual corporate AP and getting the challenge which is then passed to Manor to present to the client  so that we may get a valid response.  As you can see here, it's retrieved the first auth challenge contents is what host APD, our rogue generated,  but we don't want to use that one.  So there's auth challenge contents after copy, which it's actually gone from the legit access point.  We send that to the client, John in his bedroom and his phone has decided that our access point looks more appealing.  So it knows the password, it generates a response using our hash.  Manor takes that response, writes it down to a file and essentially passes it on to my Sikafant.  And we get the hash anyway in case we want to crack it later.  So then next we have the other half of this equation, which is my Sikafant, WPA Sikafant.  I'm running it using the adapter ending in U6 thanks to the new naming convention.  Once again, grepping out the relevant data and I'm also grepping for an EAP failure, which just to show that there's not one.  So we run it, oh, in the config is now, so this is now happening near in proximity, in close proximity to the,  an actual legit corporate AP because we want to connect to it.  So this portion has to run close to your client.  So then you just put where you want to connect to in the config file using the standard Sikafant,  well, supplicant syntax and we don't need creds, so we leave those blank.  Cool.  So what we got here is phase one came in, phase two came in and supplicant immediately, well,  Sikafant immediately starts to connect to the access point.  It gets the challenge data, passes the challenge data to Manor and waits for the response.  Manor at this point has been waiting for a little while, the client's been waiting for a little while,  the client's been waiting for the response, so they immediately come back with the response.  See here, Manor contents.  Cool, take that response, we pass it off to the access point, the access point goes, okay, cool,  you showed me, you know the password, EAP success, you're done, now you're connected.  Brilliant.  I specifically didn't run DHCP this time just to show this bit where we don't have an IP address,  we have a basic client just to get an IP, this is just to prove that we do have full comms  to the network I connected to.  Again, IP of 10.0.0.5, I double check it, and then I attempt to connect to a service or  server on the client's network.  I go back because I'm lazy and I copy it, but yeah, essentially I'm going to connect to a web  server on 8080, and we automatically just connect to people's Wi-Fi.  Cool, thank you very much.  So yeah, we're going to release that stuff today, WPSSIP of sick offense in the Mods to Manor,  so that you can do this attack yourself.  Michael's used it successfully on some of our client's engagements, so it's a practical working attack  on some live environments.  Then to the most important part, coming up with a name, Michael sent me this image, which was deeply  disturbing.  Which we later found out was called Squirtle Boy, which was, I'm not sure it made it less  disturbing.  So this is why we really want Michael to be known as Squirtle Boy from now on.  So interestingly, back in 2002, I'm never going to get these names, right?  Let me look them up on my phone here.  So Enos Sakan with Nyemi and Nyberg wrote a paper in 2002 about Malarying the Middle Tunnelled  Authentication Modes, and from that, the IETF spec for this thing in 2004 made short included a  section on defending against these attacks.  So if you zoom in, there's something called cryptographic binding or crypto binding.  And the point of crypto binding is to make sure that some of the keying material used in the outer TLS  session is used in the inner EAP method so that they can be, you know that the same device,  that relaying isn't happening.  So it's always disappointing to implement an attack and think you're the first and then find out that  the standards had a defense against it for over a decade.  On the flip side, people don't seem to be turning on crypto binding, and we think that's really just  because of a lack of practical attacks.  That said, thanks to Synchronicity, we were definitely not the first.  So in 2014, Peter Robbins released a similar sort of an attack, but it was against a specific thing that  Apple was doing, I think something around Leap in a WISEC paper in 2014, which Apple then fixed.  So it wasn't a full implementation.  And then this morning, 15 minutes before we woke up, somebody logged an issue against Manor,  asking for this as a feature request and linking to a paper that had been written in 2016 and sent to  the FOSTA mailing list by Ciarre Siniak.  I'm so sorry for butchering that name.  And so he also has a partial implementation.  It was done against the EAP state machine in host AP and WPS applicant.  But as far as we could tell, it's not a full working practical implementation just yet.  So we think this is the first practical implementation of this attack that can be used by people.  And so because there's no practical implementation of the attack or certainly not a widely known one,  what you see is that the default configs for a lot of networks don't turn on crypto binding.  So here's a picture of Microsoft's radio server configuration.  And by default, they will not disconnect clients that don't have crypto binding.  So because this is something that needs to be done on the client side, the access to the radio server  can detect whether it's been done and disconnect clients, which makes it slightly less usable, I guess,  but a bit more secure.  So maybe that's why they didn't do it there, is they don't want to make it harder for people to get on the network.  But here's a fully updated Windows 10 default connection dialog,  and their crypto binding is not enabled either.  Host AP tries to do some crypto binding by default.  So there are some places where they try to do it, but most people aren't running host AP networks  in their enterprise organizations.  So for the most part, crypto binding doesn't seem to be turned on.  You can go turn on crypto binding, but I think the biggest defense against these sorts of attacks  is just to make sure that your client devices are properly validating the server certificate that gets presented.  Because if that's done, then this part doesn't matter too much,  because they won't get past the tunneled, the outer TLS negotiation,  because they'll say, that's not the right access point. You're fake.  All right.  Okay, so those first two scenarios is once the first one was getting a bunch of devices to connect to you  and being able to figure out which device is doing what,  and the second one was doing EAP attacks.  Oh, sorry, one other thing is you would have seen a hash cat and Atom's PMK ID thing.  Anyone who's interested in WPA2 handshake cracking,  put some basic stuff in just to try, like if a client ever sends a PMK ID  to just log that into the same file,  I need to do way more testing to see if it's a practical attack from a rogue access point perspective.  But that might be fun.  Okay, so now we're going to look at some Mitom stuff.  So back in 2014, we released the Manor Toolkit,  and the idea there was lots of people take and then you can Mitom as, you know, for granted.  But the reality was, if particularly if you're new to this,  you have to sort of orchestrate networking and access point stuff and protocol stuff,  and that can be quite a lot to do.  And then with the increase in certificate pinning and things like HSTS,  sorry, I'm just...  Hmm, it's about to get breathy.  With things like certificate pinning and HSTS,  it's not sort of a given that you're going to be able to man in the middle all the things  and get all of the passwords.  So the big problem we ran into with Manor Toolkit is the ability to construct pipelines.  We were using IP tables to redirect traffic from one place to another place.  So for example, you can SSL strip something,  but you can't then pass the traffic through to SSL split.  Maybe there's some IP tables gurus in here who can show us how to do it,  but it wasn't pleasant.  And then along came BetterCap.  So BetterCap written by EvilSocket in Go, it can do all of this stuff,  and it's really fantastic.  Initially, we wanted to get EvilSocket up on the stage to talk about some of this stuff,  but he's got a whole bunch of really cool Wi-Fi attack things built into BetterCap.  So if you want to do captive portal attacks,  or you want to beef hook browsers through your Mitten,  all sorts of other things, then you can now do that with BetterCap.  So we're just effectively deprecating Manor Toolkit and saying,  use BetterCap, it's better.  And just a big shout out to EvilSocket for the awesome work he's done in there.  I know based on the issues that get logged, that guy takes some bullets.  The other problem you face is trying to orchestrate setting up a network and all the network,  well, the Wi-Fi network and all of the networking.  Okay, so I'm seeing people waving hands.  And Michael found a cool tool written and maintained by a guy named Obliq called CreateAP,  and what this does is just makes it really easy to say,  create an access point and bridge it between this network and this network or NAT it.  Without all of the sort of complexity that Manor Toolkit brought in.  However, there were some things that it didn't do.  It doesn't allow you to create EAP networks,  certainly doesn't allow you to do Manor modes,  and it doesn't allow you to create more than one Wi-Fi network.  Sometimes you might want to create more than one Wi-Fi network  because probes don't say what kind of security principle they're connecting to,  but you might want to present an open PSK and EAP network and see which one it connects to.  So Michael made CreateAP, which is a fork of CreateAP that can do all of these things,  it's something else we're releasing today.  So it does all that networking and access point orchestration  for the most obvious ways in which you would use Manor Toolkit to do this stuff.  If you want to get into the detail of all the other config options,  then you can handcraft your own config files and do it that way.  You can do it all up in the Wiki, but this just makes life much easier.  So that's an example, ignore the dash N at Creptin there.  But this is an example of setting up a Manor EAP malicious access point.  That's if you don't have the dash N,  netting traffic from WLAN 0 to S0 called EvilCorp.  If any of you use Manor Toolkit to edit some of the scripts,  this is way easier than any of the stuff we did before.  Okay, and then there's also a bunch of really cool proportionality options  that have been built into Manor. See, it's a sniper rifle proportionality.  So by default Manor is a bit of a flamethrower.  Like it'll just target every device it sees and any network it sees.  But if you're on an engagement where you've got specific scope,  you might want to limit it to specific devices or specific networks.  Or if you're in law enforcement or something and you've got a specific mandate,  you might want to limit what it does.  So we built a bunch of options in there like SSID filters  that was contributed by a guy named CyberDevil.  But one of the things that we think is really cool is we extended MAC ACLs  down to a management frame level.  So any of you should be familiar with the way MAC address ACLs work on Wi-Fi.  You know, your home router does it. You can say only these MAC addresses can connect.  You can see the AP, but if you try and connect and you're not in there, you'll get rejected.  So we brought that down to management frame level.  So if the access point receives a probe request, sorry,  if the management, if the access point receives a probe request from a disallowed MAC address,  then it's not even going to respond to the probe request.  So that means for the most part it won't even show up in their list of available networks.  Also provide some ability to kind of hide from people who might be looking for these devices  or wireless intrusion prevention systems.  We think it's quite cool.  And then I borrowed a concept from the Aircraft guys.  They've got this idea of binary net masks so that you can kind of mask out certain bits in a MAC address.  So you can do things like anything with this OUI, you know, any of these devices can connect, but these can't.  But it also allows you to do things like for randomized MAC addresses, go full manner on them.  But when they try and connect, be a little more circumspect about checking what the MAC address is.  So it's a really flexible way of dealing with different MAC addresses.  And then lastly, if you want to get into Wi-Fi hacking, it's really difficult to practice.  On the one hand, you've got to buy hardware, you've got to make sure that chipset works with what you're doing.  So for example, those new black alphas, the chunky ones, those things, because they're doing more stuff in firmware,  you can't use manners, probe manipulation stuff, the radio stuff will work, but not those things.  So you've got to make sure you get the right hardware.  And then also it's really difficult to kind of not target people you don't mean to.  You know, you might be testing between your two devices, but it's meanwhile, it's like men in the middling somebody next door.  Anytime somebody is playing with the stuff in the office, we just plug into the wired network because it's like dossing the Wi-Fi.  I've even had really weird situations in busy environments where it ends up kind of dossing Bluetooth, which is kind of strange.  So in 2014, we built some CTFs in AWS where you could practice Wi-Fi hacking,  which we're kind of proud of because Wi-Fi in the cloud is a thing now.  And today we're going to release some Docker images that let you, well, the moment is one Docker image,  but hopefully some more Docker images in the future that allow you to practice some of these things.  So you don't need any hardware. It's not going to target any live environments.  And you've got some kind of known completion criteria so you can make sure that you're able to run these commands and they work.  So that's actually Michael in the picture there, if you look carefully.  And Michael's a Kendo nerd and he told me that these wooden swords are called Chenise.  So hardest problem in computer science naming things.  So I'm calling the environment Chenifi.  And I'm just going to show you a little silly demo of what that looks like.  So here's the Docker container running on my Mac.  And there's a whole other story about, so if you're running Docker for Mac, just don't try and do this on that.  There are ways, but like I'm currently was asked to politely take that stuff down by Docker.  So rather do it on your Kali's or your Linux boxes because it needs certain kernel modules.  But okay, so here's the Docker container. It doesn't have anything, any hardware plugged into it.  So if we look, there's a WLAN zero, which means there's a Wi-Fi device.  And if you use Airmon, you'll see that that's a software simulator of 802.11 radios.  There's this kernel module Mac 802.11 hw sim, which allows you to simulate fake Wi-Fi devices that can connect to each other.  And so if you then run, if you put one of those devices into monitor mode,  we've got some sticky tape and chewing gum in the background, which tries to figure out when you're doing these things.  So if you run error dump, you'll actually see Wi-Fi networks and devices that are there.  Again, no hardware. These aren't real things.  There's a WPA handshake. So you can try and capture that handshake.  If you bring up a MANA network, you'll see clients trying to connect to you.  You can capture those credentials and crack them.  And you can do all of this without needing any actual hardware.  So yeah, we're going to release that Docker image.  You can just Docker pull it, run it, and away you go.  And that's kind of the end of our talk.  So we're going to, I bought a domain called Wi-Fi.net, but with ones, w1f1.net.  So a little bit later after this, somebody will lend me a computer. Thanks, guys.  I'm going to push all of the tools we mentioned up there so that you can grab it.  So don't be disappointed if you do it right now.  Try and go to the children and do it.  And we also just want to use that as a bit of a repository for kind of how to do these attacks  and which tools are working, keep updating that as time goes.  And maybe if some of you are playing with things in this room and it's going, well,  you can send pull requests or write wiki things for up there.  Otherwise, you can tell us you hated the talk on Twitter.  So I'm at syng.com, and he's underscore cable thief.  We're going to check if Squirtle Boy is available.  And we're from Sandspost.  So thank you very much for your time and patience.  Thank you.
DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_0_6767.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_6768_6815.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_6816_6935.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_6936_7091.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_7092_7139.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_7140_7211.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_7212_7343.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_7344_7463.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_7464_9167.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_9168_9371.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_9372_9623.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_9624_9851.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_9852_10103.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_10104_10343.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_10344_10907.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_10908_11459.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_11460_12251.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_12252_12335.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_12336_12467.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_12468_14483.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_14484_16415.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_16416_16463.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_16464_16511.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_16512_16559.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_16560_16607.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_16608_17267.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_17268_17375.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_17376_18131.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_18132_18539.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_18540_18827.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_18828_23603.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_23604_24371.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_24372_26111.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_26112_26243.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_26244_26291.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_26292_34823.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_34824_35039.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_35040_35147.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_35148_35231.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_35232_35471.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_35472_36755.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_36756_38435.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_38436_40907.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_40908_45095.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_45096_45431.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_45432_45563.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_45564_45839.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_45840_53171.png DEF_CON_26_-_singe_-_Practical_and_Improved_Wifi_MitM_with_Mana_eYsGyvGxlpI_53172_56824.png