 Hello. Hello. Can everyone hear me? All right. Welcome to our talk. The war never changes. Attack against, or attacks against WPA's new open standard. Enhanced open or, uh, yeah, open wireless encryption or opportunistic wireless encryption. So this is, um, this is Steve Derricott. He's the co-author, co-developer, co-parent of SNF Glue. Um, SNF Fair, sorry. Uh, he's an amateur botanist. Always wearing shades. And, yeah, I wrecked your bio, man. And this is Solstice. He made a crappy tool called E-Pammer. He wishes he could be a botanist and everything he learns comes from Google. All right. So onto the talk. So we're here to talk about, uh, some of the new technology that's coming out with open, uh, open technology on Wi-Fi networks. What we're currently familiar with, uh, is the standard that was released, you know, in 1999, literally 20 years ago, was when this technology came out. And, uh, obviously mass adopted by people, um, because it was the new hotness. But then, you know, this is, uh, this stayed around. This stayed around for a while. We can go to the next one. We started off with WEP and OPEN, with those two initial standards, 802.11a and 802.11b. And, uh, OPEN obviously seems less secure because, uh, WEP was wired equivalent privacy. So it was supposed to be encryption for the networks, um, because they knew that having an open network, anyone could passively receive those packets. So, uh, out of those two technologies, you know, OPEN is the only one that's still here today, not WEP. Um, and the reason for that, you can go ahead and go to the next one. Right? Why, why is that? Why is OPEN still around, even though it's 20 years old? Uh, WEP has been replaced. WPA2 is soon to be replaced with WPA3. Um, it's the battle we see every day in this industry of security versus convenience. If something is more convenient, people are going to be more willing to use it. If it's, they don't care if it's secure, they just want to get to Google and their, their Facebook and, and their Gmail, right? So, the fix actions, right? Um, who here uses Zoom for conferences? Uh, yeah, the web conferencing software Zoom. Remember there was a big issue with that and, uh, you know, if you use it on a MacBook and they weren't going to patch it. So Apple just took the nuclear option and patched it themselves, right? They released a patch for that over Zoom and just said, forget that. This is similar to what we saw on the internet. With OPEN encryption or with OPEN networks ubiquitous everywhere and people constantly using them, websites were aware of the vulnerability. So major vendors or major people, Google, Facebook, et cetera, started implementing HTTPS only to force people to use HTTPS. Right. So then we had that mass adoption of HTTPS everywhere. And that's similar to what we're seeing with OPEN wireless or the OWE and the new enhanced OPEN. Is that it's still going to be, um, like going to Google, right? There's no authentication. You don't have to log into Google to establish that initial HTTPS connection. It's just an encrypted handshake happens. Boom. The certificates are validated. You're there. Um, this is going to be the same thing, but for OPEN networks. So there will be an exchange between the access point and the client. And that will encrypt the traffic between the two. So still no authentication needed to connect to an access point, but you will have an encrypted session. Just like when you go to Google, no one can technically sniff your, um, packets because they're encrypted with HTTPS, but yeah. Right. So because of this, this led to downgrade attacks where, um, well, yeah, this is what forced Google and Facebook and all of them to enforce HTTPS only was the downgrade attacks that took place. So, um, many people here in the wireless CTF, or if you have ever messed around with wireless technology, you know, you can stand up people, twins, get people to connect to you. And then you're the network administrator at that point. So you can do whatever an evil network admin would do, like downgrade connections to, you know, redirect websites to HTTP versions. And that is why Google and other websites started forcing people to use HTTPS. But yeah, I'll hand it over to Gabe now. Yeah. So, I mean, just to kind of like, you know, build off of what Derek Ott was saying, um, imagine if, you know, every time that you went to, uh, go to like an encrypted website on, on the internet and you had to type in a password, uh, can you guys actually hear me? Okay. Can you hear me better? Okay. I guess I have to tilt this. Is it, is it shaky if I do this? Does this work better? Okay. Yeah. Um, yeah, I'll give you that one back. Okay. So this mic is a little better. Um, yeah. So, just rewind a little bit. Um, so I mean, we mentioned that, you know, 8 to 11 came out, you know, circa like 1999, right? And, you know, not looking after that, you know, people realize, oh, you can sniff passwords from open networks. And, you know, by 2002, we actually had the earliest documented use of, of rogue AP attacks, evil twin attacks specifically to intercept traffic. Um, which was, which was like these mental attacks that, that Steve was talking about. Um, you know, these attacks in, in combination with, with other techniques that started to merge around that time period in the early 2000s, you know, such as ARP cash poisoning, et cetera. Uh, this, this led to the widespread adoption of HTTPS. Uh, you know, you know, a lot of, a lot of major, uh, like, I guess like internet-ish companies started, you know, actually just really, you know, rigorously like rolling this out. Um, and, and this effectively ended the, the, the passive in the golden age of passive sniffing. You know, nowadays it's really difficult just to sniff stuff offline and, and get anywhere with that. Um, it did put a dent in, in the effectiveness of evil twin attacks for a while. Uh, but it did resurface as a threat model in 2009 due to the discovery of the, the downgrade attack, as we mentioned, uh, by Moxie Marlin Spike. Um, you know, so essentially by doing this, uh, you essentially kind of act as, as, as a malicious proxy of sorts and you, and you are able to downgrade, uh, encrypted HTTP connections, so HTTPS connections to HTTP. Um, this was mitigated later on, so at this point you saw a resurgence of, of rogue AP attacks. This was, uh, mitigated later on by the introduction of HTTPS and cert pinning. Uh, so essentially on paper, uh, you know, this would have happened around 2012 although realistically, you know, widespread adoption of HTTPS didn't take off until much later, uh, just because it's, it's hard to roll out and it, it took some time to set up. Um, and you know, for, it was like that transition page, kind of like what we're seeing now with WPA3. So, you know, what is HTTPS? Well essentially the way HTTPS works is that the client, you know, when, when your web browser is going to request a resource from an HTTPS enabled web server, uh, this server is going to add a special header called an HTTPS header to the response. And you know, and this is actually down here, kind of what this looks like, that this header is going to tell the browser that it should always request content for the domain over HTTPS rather than HTTP. So, you know, if you attempt to use a downgrade attack, which at its core you're just, there's some redirection involved where you, where you redirect the, the victim's browser to the HTTP version of the site. Uh, the browser actually refused because it's been, you know, this domain has been added to a preload list essentially, or not preloaded but an HTTPS list, um, that says this domain can only be loaded over HTTPS. So you'll get a, a basically an internal, um, I believe it's a 309 redirect that the browser will issue to the HTTPS version of the site, um, and you won't be, and, and essentially the HTTP downgrade attack won't work. Um, so there, there were some, some bypasses that came out for HTTPS in 2014. Uh, one of the most notable ones is by Jose Selvy. Um, so essentially HTTPS headers, they have a max age parameter, uh, that dictates when the web browser should stop treating the header's origin domain as an HTTPS site, because, you know, imagine if you accidentally set something to a, as an HTTPS site and you could never ever undo it. Um, so, you know, essentially what, what, uh, Selvy figured out is that unless unauthenticated NTP packets are cryptographically signed, it's possible to tamper with them and you can essentially shift the victim's system clock forward past the max age set in the HTTPS, uh, header, and by doing that, um, you know, essentially you, you can, you can expire the HTTPS, um, entries in, in, in their list and you know, HTTPS is effectively bypassed at this point. But there's, you know, since his, uh, bypass technique came out there, you know, there are a lot of actual other ways that operating systems deal with, um, uh, kind of, kind of deal with the threat. So for example, Windows they, you know, it has, um, their directives that, that basically say, uh, you cannot shift the time forward past, you know, further than a certain, you know, delta of time because, you know, it, it would allow you to do this. Um, the reason why I mentioned this though, you know, if we look at the current wireless security threat model, um, and, and just kind of examine how today's attackers use wireless attacks, um, you know, they're primarily used for gaining initial network access to weakly configured WPA and WPA2 networks. You know, either you will want to get attacks against EAP or, or you're, you know, finding ways to get PSKs from WPA PSK networks and crack them. Um, or they're used for stealing active directory credentials using GTTC downgrade attacks or hostile portal attacks. Um, or you see people using them, you know, for social engineering attacks using captive portals. You don't really see, um, you know, if you do see attacks against open networks, you know, they're really most effective, uh, because of this widespread use of HTTPS and also the widespread use of, of HSTS on the stuff that really matters and would be attractive to, to an attacker. Um, you know, really if you're, if you, if you want the most bang for your buck um, you're going to be doing, you're essentially going to be looking for static content or mixed content issues that will allow you to, you know, inject payloads and, you know, into, that will eventually get loaded into the, the user browser. So for example, you know, you start intercepting traffic, set up your, your, um, your interception attack and, uh, you know, you're intercepting traffic and you notice that they're, you know, loading, you know, third party JavaScript code over HTTP. Well, you can replace that with your own JavaScript code, you know, that eventually their, their system. But, you know, really you don't see a lot of credential stealing attacks. Um, you know, because most high value targets are using HTTPS and cert pinning and defeating HTTPS is difficult the best. Uh, HTTPS is difficult the best. And defeating cert pinning without social engineering is virtually impossible. Um, and really doesn't make sense in light of other attack paths, you know, just, if you're going to go to that length, you might just use spearfishing or something. Um, as for passive sniffing, it, it is, it's, it's very rare. Um, and this is, this is kind of the reason why we bring up this background information. If we kind of go to, um, you know, look at OWE, right? Um, you want to go for this part? Or you want me to go, okay. So, so OWE, right? It, it, it kind of was introduced fairly recently. Um, and it's, it's being rolled out kind of as we speak. It, it, it kind of solved this problem of not being able to have unauthenticated Wi-Fi access, um, you know, without you know, so essentially it, it's designed to give you encryption capabilities, uh, you know, and act as if you were connected to an open network. Uh, but you don't need to authenticate. So, you know, how you connect to a HTTPS site over, um, you know, you know, and you don't have to enter a password. OWE is supposed to work the same way with, uh, open networks. Um, you know, the way it works is, you know, you start out with your typical association. Um, and when this happens, the client AP has a pairwise master key or PMK. Um, after that, the AP is going to initiate a four-way handshake, kind of similar to what WPA does, uh, but using that PMK, and you're going to generate a key encryption key, or Keck, and a bunch of other stuff. Uh, but at, at, at that point you do this four-way handshake and you end up with some encryption keys that are used to protect both unicast and broadcast data. Um, but basically it's an open network with crypto. Um, so, I mean, the way this works, right, and I'll, I'll, I'll load this up in Wireshark so you can get a better idea of what this is doing, but, you know, the way, the way that OWE works is the access point is going to advertise its, its support for this protocol using, um, an AKM suite selector. It's basically an RSN element that's added to all beacon frames that are getting sent out from the AP. Uh, the client's going to discover these OWE, it's going to discover that the AP is OWE compliant, uh, because it's a authentication process with it so to show you what I'm talking about because it's a little more clear if I do it this way. Well, at least pulling that up. Um, Gabe just talked about a lot of attacks that you can do against open networks, um, from injecting your own code and uh, all of these things and passive sniffing is not something that we commonly use on our wireless Pintas. It rarely generates anything worth benefiting from. So OWE is fixing a problem that we weren't even concerned about. I didn't know that. I rarely am sniffing passive data to begin with because everything is typically encrypted by major vendors such as Google and Facebook. So there's no reason for me to passively sniff open networks anyways. Alright, so I'm going to, right now I've just, I've just launched an OWE access point. I'm using virtual, um, wireless interfaces here. I'm just going to filter here for beacon frames. I hope you can actually see this. Um, alright so cool. I have a bunch of beacon frames here. And the SSID is open Wi-Fi, but it's not actually open Wi-Fi. This is a, if you look here, right, you scroll all the way down to the bottom. Actually, I'm going to minimize some of these tags here because they're, they're probably, I, I don't know why, um, you know, Wireshark by default just opens everything that you want to look at. Like it's not helpful, but uh, RSN. Okay, so tag, RSN information. Can everyone see this? Can anyone not see this in the back? It's probably really small. Um, but you know, feel free to ask us later if you want us to walk through this in person because I have a feeling it might be hard to see on the screen. But, okay, so there's this tag here, RSN information and you can see here that um, you know, this is coming from the AP to beacon frame. And we have this um, off-key management, AKM, and it'll actually tell you that it's using um, um, opportunistic wireless encryption and it'll also have the RSN so essentially everything you need to know about how this thing uses crypto basically. Um, let me go back to these slides. So, um, so an interesting thing, um, in case you're not aware, so um, a little background information, uh, so elements are actually, what you're seeing here in the Wireshark thing, right, these are what are known as elements, um, or information elements. And they're set between the client and the AP as request and responses. And they're used to facilitate protocol communication between wireless devices. Um, they're basically, elements are basically a form of time length, or type length value, uh, which, which means that they're, it's a data, the type, a TLV is a data type that's comprised of three parts. It's going to have an element ID, which is identifying the elements data type. Um, it's going to have a length, which is the elements length and the value, which is basically, you know, this field is entirely dependent on the elements data type, which is, um, so essentially what this lets you do is you can send something from the client to the AP and the client doesn't have to really know what data type is receiving. Um, I, I talked to a guy who's into reverse engineering later and this terrified him, but earlier, but essentially it'll first check at the, basically the TLV, the element is just a, a string of bytes and, you know, your, your wireless device is going to look at the first, uh, you know, the first bytes in it and it's going to use that to determine the data type, then it's going to grab the length from the next set of, set of bytes and then from there it's just going to know how, basically how large the next field of bits is. Herb bytes. Um, so, the reason why I mention this is that in 802.11, 8 association requests and responses are constructed entirely by appending elements to one another, so you just get a bunch of these TLVs and start appending them off, off each other. And in OWE, um, there's a Diffie helmin parameter element that's dependent to both association requests and responses and this is how the AP and the client, uh, give each other their public keys. Uh, so you know, essentially, uh, once you reach the association process, uh, the client is going to send an association request to the AP and it's going to have an element in, you know, kind of in the packet there that, that is, is going to contain its public key. The AP is then going to give, you know, respond with the association response and there's going to be an element, a Diffie helmin parameter element that's going to have the AP's public key and at this point they've exchanged keys and they proceed to the, the four-way handshake we talked about. Um, so just to, uh, so we have this, this OWE access point running right now and I'm going to get this thing to authenticate. Right. So on the left we're just using WPA sublacant where we're going to connect to this AP and I'm going to go back to Wireshark and at this point I'm just going to start sniffing packets again. Actually I might have to do this a second time, uh, because I missed it, kill that and then I'm going to start that's going to associate. And I'm going to change this to say that I don't want any beacon packets because there are a lot of them and they'll get in the way of what we're doing. Okay. So let me just figure out if I lose this thing here. Hey man, do you know how to like, what's up? Get this thing to come back down. Now, uh, oh I got it, never mind. Okay, cool. So here we have, um, I'm going to try to find that. I'm going to go back to the request, probe response. We've really talked about that. I'm going to scroll down until we see. Okay, here's the association request that we talked about that's coming from the AP or I'm sorry, from the client device. And if you look in here, we have this extended tag, uh, which is this element we were talking about and it contains the public key from the client device that's being set to the AP. And then you get a, you have an acknowledgement from the, from the access point and then below that you have an association response thing. Here we have these OWE Diffie helmet parameters and then that's going to get sent back to the, the client device there. So then the key exchange happens and we have this little four way handshake here and then you have basically encrypted open Wi-Fi, which is what happens after that. Right, and all this would happen invisibly to you. You, you, if you just open up your phone, looking at Wi-Fi networks, you would see an open network, you would connect to it. If your phone is capable of OWE, it would read that packet that, um, or the, those OWE packets that Gabe was just pointing out and then it would go through that process. If not, it would just connect to an open network normally. Yeah. Yeah, exactly. I mean, so I guess the problem with OWE, right, I mean, it, it does some good things, right? It addresses the needs providing encryption for unauthenticated wireless connections, um, you know, and also makes use of protected management frames, uh, and, and makes them mandatory. We're going to go more into that a bit later. Um, unfortunately the, the thing that it does not provide a means of verifying the identity of the access point. We're not the first ones to point this out. Uh, you know, I mean, people have been kind of bringing this out. Even, even the authors are like, you know, in the RFC itself, there's actually a big disclaimer that's saying it does not do this. But you know, just want to do a little thought experiment here. A thought experiment here. Imagine if HTTPS did not provide a means of verifying the identity of the web server. So in other words, whenever you use, you know, HTTPS, everyone use self-signed certs and no anything whatsoever. It, it would kind of negate, you know, the effectiveness of HTTPS, right? And that's kind of what OWE is like, you know. Good thing. It's hilarious. Um, so, do you want to, do you want to grab this part? No. Oh, yeah. So OWE doesn't address any real threat or attack in the, that you see in the wild today. It's only encrypting, you know, the traffic, which if I'm standing up my access point and you're connected to me, I'm a network admin at that point. I'm going to see your traffic regardless because I'm going to route it wherever I want. It doesn't matter if it's encrypted between your phone and my access point. Once it gets to my access point, I'm in control of the packets. Yeah. So, I mean, it really only succeeds at preventing malicious users from doing passive sniffing. Which, as we mentioned is kind of a fruitless exercise in the first place. Um, so, yeah. So, alright, so, when we kind of embarked on, I mean, we kind of, a few months ago, we were like, hey, we should look into ways to attack OWE. And we thought it would be much more complicated than it actually was. Um, and it turned out it's actually not really that hard. Uh, you know, yeah. Right. So, I mean, the first thing you, I mean, if you do want to, I mean, the first technique that we, I guess, I don't even want to say we came up with this because it's like literally the same attack that people have been using for 20 years. Um, but, the first technique is just to stand up an OWE evil twin, right? You make an evil twin access point, um, you know, using your favorite rogue AP tool, like sniff glue or uh, eat, eat, blammer. And then, and then you, you know, do what you're going to do. So, which, I mean, we kind of demonstrated that works here. I mean, like, just to keep this simple, I'm just going to tell WPA Supplicant to start probing for stuff and this is pretty much exactly what would happen if, like, you were just wandering around somewhere and had your Wi-Fi on and someone stood up, and it would like, they essentially knew the network on your PNL and stood up their own access point, right? As expected, it would, it would connect. Um, yeah, I mean, that's, it's, it's, it's fairly straightforward. Right? That's a standard evil twin attack, nothing new there. It just has open, or OWE. It's really nothing novel, but that's the problem. Um, I just, yeah. But this is the more surprising part. Um, as it turns out, and we kind of just discovered this by accident, but, and this is probably like a, honestly an implementation issue, but, you know, for WPA Supplicant, for example, which is what you'll find on most Android phones, you know, well, check this out. Okay, so instead of, instead of using an open, an OWE access point, or I'm going to create an open access point. So, here I'm going to show you the config file we just, we just used to connect to that OWE access point. Right? And you can see, right, it's using key management OWE. This is, this is the OWE config file we're passing to WPA Supplicant. And then for, for ePammer, or whatever the tool you're using, trying to remain agnostic here, but, um, you know, what happens if we, if we spin up an open access point instead? I mean, this shouldn't work. But, like, these two things should not be able to communicate with one another. I mean, unless it's in transition mode, which it's not. Um, so, here we go. We've started, and oh, what's this screen? Okay, so we've now have this thing that is configured to use OWE, but is connected to this open access point, which, at least in this case at WPA Supplicant, it looks like you can execute rogue AP attacks against stuff that is expecting an OWE network using open Wi-Fi. So you don't even need the new, you know, retooled versions of all these rogue AP tools to do this. You can just use the same tools that you've been using for the past two decades as an open network, and in this case it, it works. So, yeah, that's kind of what we thought about this, too. Um, you want to talk about compatibility mode? Ah, I guess. What's, uh, what's it, through this slide? Okay, so compatibility mode or fast transition mode, I believe it's also called. Um, what happens is, within the beacon frames of an open network, uh, it will have within an information element a hidden SSID. So it'll be a BSSD, a MAC address associated to a hidden network that is doing OWE. So, invisibly to you, your device would connect to that network or receive that frame and notice, oh, hey, I need, if I'm OWE capable, I'm going to look at this hidden, uh, network and connect to that instead. So, um, yeah, that, it's when you're broadcasting frames like that, anyone can read that as well. So we got the idea of, well, why can't we just look at that packet and then spin up our own evil twin using that same BSSD that's in that same packet. And, uh, yeah, to kind of illustrate how this works, you know, actually, so I'm going to spin up a, um, I'm going to, I'm going to wait for this event loop to stop this computers. So, what I'm going to do is I'm going to set up OWE transition mode AP, right? And what's going to happen, oh, okay. Did I spell something wrong? Give me a second. Oh, open, okay, yeah, so that was typo on my part. So right here I'm, I'm creating a, uh, wouldn't have happened if I was using SNP there. So, um, essentially we're going to, we're going to launch this thing, we just created an OWE transition mode AP, which is kind of interesting because it's actually two APs. It's two BSSs being started off a single piece of hardware. Um, so if we go back to Wireshark really fast, uh, and this time we actually do want to look at beacon frames again, so I'm going to just kind of replace that. Um, you'll, you'll see two, uh, two SSIDs here. Uh, the first one is a wild card. So this is a hidden SSID that we're seeing. We don't really know what this is. And then we see this, this open, this open, uh, SSID. So, essentially what happens is, you know, the idea of the transition mode is that it's supposed to have a setup where, you know, no matter whether the device only supports open authentic, open, whether it supports OWE or not, it can still connect to this network. Um, so what'll happen is that the publicly visible SSID, right? It's, it's, it belongs to an open BSS. So an open, open network. Um, and then we see that here with this SSID, uh, that's visible. Um, and if an OP, if a device that only supports connecting to open network, it doesn't support OWE, attempts to connect to this thing, that'll be it. It'll, it'll, it'll just use the open network. However, um, an OWE, an OWE capable device, when it tries to connect, essentially it'll, it'll look through these fields and grab the SSID of the, um, of the hidden network that we see here. Right? In this case it says, you know, that SSID is open Wi-Fi. Um, but it's usually just a random string of characters. It will, it will grab that SSID and it'll send a pro request for that SSID and then reconnect to the wildcard one that we see here. Right? So just to kind of demonstrate that I'm actually going to have to edit this really fast. I guess the, the default here is for it to use spelled backwards, so there we go. Okay. So here we have a device that's going to attempt to connect using open explicitly. Right? And I can't type today. And you'll see here that it's connected to the public SSID, though, the one that's visible, right? Um, uh, Remapay or whatever this is. Right? And you know, all is expected. If we instead elect to use the, um, the config file that, that makes it look for an open, an open, um, sorry, the OWE access point, it will first connect to the open Wi-Fi which you should see in a second. Come on demo gods. That's a little weird. Okay, hang on a minute. It should be right. Oh, live demos, gotta love them. Yep. Yeah, I, I don't know. Well, good thing we have, all right, I'm going to try different config really fast. Okay. All right. I see what I did. I tried to specify the random SSID instead of the open one. Okay. Cool. So this should work. So, um, yeah, so you see here, it says try and authenticate with, uh, so despite the fact that we configured it to go for the visible, um, network, right? Uh, which was, which was this. Instead, shifts over and tries to go for this randomly visible one. So going back to Wireshark really fast, um, just to kind of uh, show you what we're doing. We replaced this with the public, SSID is now open Wi-Fi and the random one, the random hidden, uh, OWE, uh, SSID is this, this random string of characters there. It's not really random, I just mashed keyboards, the keyboard a bit to get it, but, um, so it's connected to the random one. So that's how that works. And I just did that. Uh, I think we just talked about this basically. Yeah, so this is just basically what we talked about, but, um, if your client doesn't do OWE, then it's just going to connect to the open network, but, uh, if it does support OWE, then it's going to look for that hidden network and then associate to that one instead. So, we tried a number of techniques to attack this kind of network. The first was just creating an OWE evil twin, you know, just, we figured just grab the RSN, or the grab the SSID from that, that information element. It turns out this doesn't actually work, uh, because the, the offline device, and actually that's, that's why the first demo failed, is because we essentially tried to do that. Um, you know, but if you just, if you just try to, you know, create an OWE evil twin using that, that random SSID, it's, it's going to fail. However, um, what does work is that you just do an OWE transition evil twin. So you, you match it exactly, you know, you match both the, uh, the public SSID and the private one. And the, um, the third technique that we figured out is you just use an OWE evil twin. And surprisingly, that works as well. Because remember what we, and, and, and once again, that is likely, uh, just a, um, implementation issue or something, because it really isn't defined that way in the RFCs, but, whoops, I locked myself out. Um, for example, if we just create an open network here, even if this device is expecting OWE, for some reason, it'll still connect to your open access point. Or at least it'll try to. There's some weirdness going on there. But, uh, there we go. Yeah, off failure. Well, anyways, it worked earlier. So, the one thing that I think actually OWE gets right is the use of PMF. I mean, yeah, uh, with, uh, management frame protection, you're, um, getting rid of de-auths. So, that's one of the most common attacks that we see today is knocking people off a network and then recording the transaction of when they connect right back to that access point. And that's one of the major features of WPA3 is that it's going to enforce all of that, uh, the protected management frames so that de-auths is going to be no longer a thing if you guys walk around at cons with your de-authors, you know, it won't matter anymore at that point. And this also relates to the rogue AP attacks, the issues that we were talking about earlier. You know, it's not always possible to, um, get something to connect to you, uh, to get a device to connect to your rogue AP, uh, simply by providing a superior signal. That's often actually harder, uh, than it looks. Um, and, and when that happens, you know, pretty much the go-to technique that, that people rely on is, is, you know, de-authending the target access point, of course, the, the connected client device is to roam somewhere else. Um, and you know, I think what it does get right is it, it does prevent you from doing that. Uh, because, you know, with management frame encryption, basically you, you have a, you encrypt all the management frames that are going between the client and the AP, so you can't just like inject the authentication packets and get it to work that way. Um, but, you know, the problem is that you could still just kind of go back and, um, uh, you know, if, if you're, if you're targeting a client that's like by itself, it's not connected to an AP, then this doesn't even bear any relevance, uh, because, um, yeah, you wouldn't have to de-auth at that point. Um, but just to kind of show you what I mean by that. So, you know, say I, I create this, this OWE access point, right? And then I connect this, this supplicant to it. Well, provided this can actually authenticate because it was having some weirdness earlier. But, well then. Okay, so, likely this is a driver issue. Um, I'm using virtual Wi-Fi drivers. So, what I'm going to do, so I'm just going to reload them really fast. Do RM mod Mac 8 of 2 to 11. That's why you don't do live demos, folks, but we decided to be, uh, a little bold about it. I'm going to set radios to 5. Alright, this should work now. Alright, yeah, so that worked. It was a driver issue. Um, let me just take a look at my Mac address that's really fast. Okay, cool. So, just to show you what we kind of mean by this, we do air replay. You don't look like the dash A or dash B. I can't remember. Air replay. Uh, just to specify the AP. Yeah, it's A. Okay. At Google. Alright, so I'm just going to specify the, the SSID of the, um, of the access point, which is just 0, 0, 1, 1, 2, 2, 3, 3, 4, 4. I believe it was 5, 5, if I remember correctly. No, it was 0, 0. And we're going to specify the, uh, the Mac address, the client device, which in this case was, what was it? Hey, what was this thing right here? Okay, cool. Oh, we got to give it an interface. Yeah. I'm going to do that really fast. So I'm just going to put my third Wi-Fi interface into the monitor mode really fast and bring it back up. And, alright, so we're literally just spamming this thing with the authentication packets right now. And, you know, nothing's happening. Um, so you can see that those d-auth attacks don't work anymore. Um, one interesting thing to think about though is, is this. You know, if we're pushing out protocols in which, um, you know, protected management frames are required, right? Then that's inevitably going to lead to more devices, uh, supporting the use of protected management frames. Right now it's not that widely used because there's, you know, not a consistent support across, you know, hardware for this kind of thing. Um, but something to think about, right? You know, the way a lot of like IDS systems or wireless intrusion protection systems work, um, you know, to contain these kinds of attacks that we're showing you, uh, essentially if they see a rogue AP and they see one of their own devices connecting to it, they'll start d-authing it. Well, now you're going to have a situation where you're going to have widespread use of, uh, uh, support for PMF and on top of that, you know, if you're an attacker, you can make use of that as well. So if you actually successfully execute an attack and get one of these devices to connect to you, um, and you're using PMF yourself, uh, regardless of whether you're not using OWE, then you've kind of made yourself immune from, you know, what is essentially the standard containment method for the WIP's, uh, devices today. So that's going to be interesting to see how that plays out, um, in terms of how people design those things. Um, any questions? If you have any questions, we're team WhatTheFreak over in the wireless CTF. If you want to come hang out, ask us stuff over there. We'll be over there. Thanks.