 uh so welcome to the uh mi casa su casa talk uh now I've never been good at introducing myself so uh I did what uh any hacker does when presented with a uh with a new problem for the first time. I uh I looked on Google. So uh I searched for presentation ice breakers and uh one of the top results was uh enchant your audience with statistics. Now I'm not gonna subject you lot to a presentation that starts with statistics. So instead I'll start with a confession. The last time I was on stage was 20 years ago. I was dressed as a donkey for my elementary school Christmas party. Um and unfortunately for you guys I don't have a picture of the event fortunately for me. Um I'll try and bring the same nervous energy to this. Now hopefully the ice is broken. Um my name is uh Elliot Thompson and I'm a UK based principal security consultant over at SureCloud and I believe I've spelt it wrong on this slide. Come on. Nope that's the donkey. That's me. So uh yeah so uh that's my my alphabet soup there. So it's OSCP CTL over in the UK um as well as uh two CVEs so a uh a privilege escalation in uh Beyond Trust's bomb government support application and a browser based remote code execution in the VTEC Android tablet. Um now I jump onto the meat of the presentation. So the core assumption that MeCASA relies upon is if you're connected to your own network and browse to 192.168.1.1 then connect to my network and browse to the same IP address as far as your browser's concerned they're exactly the same thing. Um now this alone certainly isn't like a new discovery but we can stack a few of the behaviors together and make something exploitable. So digging deeper into the internal IPs thing. So I said that browsers treat them the same no matter what network you're on. But what do I actually mean by that? So I'll go through three examples. Uh the first is caching, then cookies, then JavaScript. So this is a just a rough example of a sticky captive portal that uh that I built. So normally any pages served by a captive portal are aggressively not cached. The last thing Starbucks want is for you to keep seeing the captive portal page after you've signed in. Um and when connected to my Starbucks network I serve a page with the cache control header set to a max age of one year so uh when you go home back to your your corporate network um you'll keep seeing that same uh that same captive portal. So that that kind of quickly demonstrates the the caching side of things. Now on to cookies. So the next thing I want to kind of go over is the behavior of cookies in this kind of same situation. So cookies that are set by a login interface on one network are automatically attached to requests for anything accessed through the same URL on a different network. At least until the cookie expires. Um and to many of you especially on the website that this is like super obvious expected behavior. But stick with it, the fun stuff is coming. So here we have PF sends running on my home AB12 wireless network. Um the page is hosted on 10 10 10 1. Um and when we log in we see the PHP session ID is expected is kind of stored as expected against that kind of domain 10 dot 10 dot 10 dot 1. So far so standard. Um but if I then rush out for some junk food um and connect to this fake McDonald's open wifi network um in this case the fake captive portal happens to be on the same IP address as the uh the PF sends machine. So they mean the browser sends our PF sends PHP session ID to this totally unrelated captive portal. But so what right? So sure McDonald's now has a session token for my PF sends box on my internal network to actually use that session they need to get inside my network. Um and there's another problem as well. So we have to contend with how long these cookies are going to last. So cookies can be set to expire in like a specific set amount of time um or at the end of a session. Um and the definition of kind of session um varies between browsers. It gets a bit fuzzy. So Chrome, Chrome um when you close the the browser and all kind of profiles that you've got open um that's when the session kind of ends. Um for IE it's the same kind of without the profile thing you have to close all the windows down um and then the kind of sessions are, sessions are cleared. For Firefox it removes the cookie as soon as the tab is closed. Um and when I tested it on, on Android the flag was just completely ignored. It was just kept for as long as they needed it. Um so the window of a cookie being available um is either going to be the date specified um in the expires flag or kind of when the session ends or when the browser closes. Um and on the subject of browsers being closed so these days it's fairly common to leave browsers open for a long period of time especially if you've got like a laptop. Um and in fact if uh if any of you have seen these arrows in Chrome like feel shame like the the green one is uh Chrome has like needed an update um for two days and you just left it. Not uh not uh updating it. Not closing Chrome. Uh and red is like a week. You've left Chrome needing an update for a week without restarting it. Um so it's safe to say like I'm sure some of you have probably seen at least one of these arrows um but it's safe to say that uh browsers that require the entire process to be stopped um we can rely on users not closing their browsers uh meaning the kind of the expires session cookies um a kind of fair game. Um as well as any cookies either no expiration or some expiration kind of far in the future. Um but of course we're still limited by anything expiring server side as well. Now onto the the last of the three browser behaviors. Here we go. Um in the previous cookie example we first started on my safe home network um and then logged into PF uh so we started on the first safe home network, logged into PF Sense and then ran to McDonald's and joined the unsafe network. But what if we reverse the order? So if instead the victim starts somewhere unsafe and then connects back to their own secure network um could something um be left behind? And the answer is yes. I wouldn't be standing here if the answer was no. Uh so instead of just serving the McDonald's captive portal on 10 dot 10 dot 10 dot 1 let's hide some JavaScript on the page. Now I totally accept this is some hideous JavaScript. I just tried to collect as many deprecated functions as I could. Um and line 2 so I'll go through that. I'll go through the important lines. So line 2 um just gets the CSRF token from PF Sense on the new open VPN client page. Line 5 pulls the token out. Again it's horrific. I'm sorry I've done it this way. I apologize to any of you that uh deal with JavaScript. Um and lines 8 and 10 just build a uh malicious post request and then submit it to PF Sense along with the CSRF token. Um and all the post request just does something really simple. It just creates an additional uh open VPN user. So here we are. So now we're connected to the McDonald's free Wi-Fi connection uh McDonald's free Wi-Fi network and in the background our page has loaded that malicious uh JavaScript and it's cashed free uh um and that JavaScript will be continuously running uh while they're on this captive portal network and that PF Sense request that kind of get to the open VPN stuff to grab the CSRF token that will be continuously failing um until they go back home again. So then when they try and log into their PF Sense web admin interface they'll instead see the McDonald's captive portal page and probably think huh that's weird um hit refresh and they're back into their kind of standard dashboard dashboard. Um but by this point it's already too late. That malicious script has executed and we have a new VPN user added into it. So as the attacker we can connect straight into their internal network without ever having to have connected without ever having to have connected in the first place. Um but and of course if if we actually check the VPN configuration we can see all the malicious changes so uh I just want to stress it's not a vulnerability in PF Sense this was just an example I chose um we're just using the standard interface through JavaScript. Um the attacker work against just about any interface. Anything you access over IP address at least. So that goes over the the three browser behaviors that we're gonna look at. So caching, cookies and JavaScript um they're all shared between devices accessed through internal um RFC 1918 IP addresses. Um and the reason behind it is pretty simple. Browsers aren't really aware that the network you run has changed. So it totally makes sense. For origins like Google.com or VK.com or whatever um they only really exist once. Um so browsers that use those differentiate they use the kind of the the domain um to differentiate between things like caching cookies and like just resources in general that's what they use to differentiate them. Um there are a couple of exceptions like um cookies being scoped exclusively to uh certain pages or paths or specifically to HTTPS connections like with a secure flag. Um but anyway onto the second major component. So karma. So when writing this presentation um I remember the karma attack as being like a super recent thing that wouldn't need any kind of explanation or introduction. Um but after checking my definition of recent made me feel so old. So 15 years ago uh Dino D'Ozovi and Sean McCawley found that you can effectively coerce uh wifi devices to connect to networks that you control without user interaction. So how does the karma attack actually work? Um so when you connect to a network um and allow automatic reconnection to it um whenever your device is not connected to that network um it will send out probe requests asking if any of those networks are nearby. Um if one of those networks is nearby the access point will send a response saying that's me um and start initiating the connection. Um and Dino and Sean found that you can boot someone off there you can trivially boot someone off their own wireless network um with a deauthentication frame um and then respond to those probe requests asking for asking for kind of network access um as yeah sure I'm Starbucks underscore wifi that sounds about right connect to me. Um it's worth noting that it only works on open networks. So since encrypted ones require um the pre-shared key to be known by both sides. So I'll quickly do the uh I quick a quick go through. So this is what the karma attack lets us do. It lets us pull someone off their secure network and temporarily bring them to our dangerous network. So in this illustration we have uh two separate networks with all clients connected happily. We send the deauthentication frame um a spoof deauthentication frame effectively telling it uh effectively telling the client that hey router says uh right now you need to disconnect. And then the and then the client dutifully just does as it's told and disconnects. Once the client's disconnected um it starts searching for networks um anything that it remembers um but that searching involves shouting the names of all the networks it's previously connected to. I'm hoping that one of them will respond. So we respond to all of them. So if you're looking for Starbucks underscore wifi yeah sure that's me um you mean Hilton guess yeah me too. Um as long as those uh remembered wireless networks didn't require a PSK or a certificate or whatever. Um but now the target now the target's on our network thinking it's on on Starbucks wifi or whatever. Um but how does that look to the to the end user? So it isn't super obvious that isn't it super obvious that you've disconnected and reconnected um in most places you'll have like a couple of seconds of like the connecting animation um followed by the connected sign again. Um and if someone clicked on the wireless icon yeah sure they they'd see that they're now on Starbucks underscore wifi um despite being in their corporate office. But uh most of the time there's nothing that's going to be plainly obvious for them to see. Here we go. Um once it okay but now that the target is connected to our network um we can poison um we can poison the cash um on display whatever pages we want um but that's not particularly useful to us um while they're connected to our network um anything I drop down can only be used to attack me and I don't want them attacking me. I can do that already. Um but before moving on I just want to stress that obviously I had no part of discovering uh karma that was Dino and Sean um I was probably a teenager at the time um but onto the next bit. So at the start um I demonstrated that we can add JavaScript onto uh internal IP pages um that uses um enter onto um internal IP pages if users connect to our network and we demonstrated we can use karma to pull you pull victims onto our network or pull targets onto our network. There are only victims once they connect. Um while they're connected to the network we can poison anything we want but none of that matters until they're back on their original network again. So like a rescued animal we want to release them back into their home although unlike a rescued animal we'll be sending them back with more parasites. Um and this is by far the kind of the simplest part of the exploitation chain um though it is still absolutely critical. So all we need to do is boot them off our malicious network um and hopefully they'll automatically find their way home. So booting them off our initial fake network um is super easy we can just disconnect ourselves um and the device will the poor device will get confused. They'll start looking for it to know networks um and this time we shut the hell up and then targets back home again along with our JavaScript payload running um and we can attack the router or whatever it is that uh that we've poisoned earlier. And to the target this looks exactly the same as it did before a slight kind of brief moment of kind of connecting um and no internet access followed by connected back to the home network again. So, so in summary so far um we can use the camera attack um or just wait and pull someone onto a fake captive portal um poison a particular IP address domain or RFC 1918 um domain with JavaScript then have the target go back to their own network allowing the JavaScript to execute in the context of whatever internal network device that we just poisoned um but we're not done just yet. So now we reach the final and kind of most complex components which is the the automation side of things. Now this component uh exists purely to solve two specific problems with the chain of exploits so far. So the first problem is we need to know the IP address of the system that we're targeting um and the second problem is we need to know the HTML slash DOM structure um of whatever it is we're targeting um but we can we can overcome both of these. So starting with starting with the the IP address issue um we can switch from our kind of one-shot sniper method um and go thermonuclear. So RFC 1918 defines um all internal IP addresses um and in in total there are roughly uh 17 17 million um across these three ranges. Cool so let's hit them all. Let's try and poison 17 million IP addresses um as quick as we can um and no surprises that that that does not go well. Um I tried to uh but yeah every single browser you try to submit 17 million requests for immediately um just doesn't doesn't go well um but that's that's a surprise for no one but realistically we don't really need um to poison every single one of the 17 million addresses um so techspot.com um and a few other sites listed a ton a ton of uh common default router and uh firewall and switch IP addresses. So let's let's start with those guys. So the IPs have been helpfully separated by by vendor but we don't really care. So instead we just want the unique IPs. So I started with a list of about 500 default IPs um across various different sources and various different websites um of which 54 were unique um and 53 had the right number of octets um which sounds like a more reasonable starting point. So these were the the most common 53 default device IP addresses um which is a good a good starting point. Now if you guys look closely um can someone spot something which doesn't belong here and just shout it out? Yeah there we go. So there's one there's one in here at the bottom right which starts with 200. So 200 dot 200 dot 200 dot 5. So when I when I first saw this um I immediately thought ah it's just a typo. It's clearly just a typo. No one would really do that right? Um so but then before before just deleting it from the list um I thought maybe maybe I should check. Uh yeah now it turns out yeah trend net release device a good few years ago that uh the TEW 432 BRP which used those uh dot 200 IP addresses um in its management interface um and I checked the IP address myself um to see if it was like a a range that was defined for like documentation or something kind of uh something unusual that I hadn't seen before um but no it was a Brazilian ISP. So uh this uh the trend net are just handing out public IPs um for this Brazilian ISP to their um to their internal network devices um it gets better too. So it's not just that one management interface. There's like 200 um DHCP addresses or 100 DHCP addresses um that are owned by this Brazilian ISP that are just being handed out to internal trend net devices um my favorite part about it as well is um so I mentioned that it's like the V3 of the trend net device like the V4 had it as well like they this was a mistake they made twice um but showed and showed that there were there were multiple devices that were uh that were happily listening on um on the address um as an alternative um as an alternative interface um although I didn't get any responses from the real uh the real IP address unfortunately but moving on. So now we have a list now we have a list of 53 52 uh RFC 1918 IP addresses um and it was interesting to see there weren't any common defaults in the 172 dot 16 range um but just to make sure they all get loaded into the into the browser cache the first task was to create some sort of page kind of orchestration layer which submits a request to all of our 52 targets um and a few lines of a few lines of terrible JavaScript and we're ready to go. So all this does is iterate through like a fixed list um and send HTTP requests um it's not pretty um but it was quick um and it can also we can just add li uh add additional stuff to the list that's uh had me at any point. So we can add kind of all of uh one and two one one six eight um like the slash 24 of dot one or the slash 24 of dot zero whatever's the most common in the particular engagement. But cool now we're submitting requests to all of these IP addresses um but we still need a way to provide HTTP responses for them all. Now if we were just doing DNS hijacking um that would be super easy all we'd need to do would be to provide a DNS server through DHCP and then like submit like send anything through to a particular IP address that we controlled. Um there are modules and there are things that exist to do that. But we can't do that with RFC nineteen uh nineteen eighteen IP addresses um since we expect them to not require DNS. But the simplest option rather than sending specific routes through DHCP um was just to use IP tables. So just to quickly break down how this works um so I've got a server running on one seven two dot two one four dot one um that's the first time I've said that right first time. Um and any client that gets pulled onto my network gets assigned a DHCP address in that same slash 24 range. Um and the only reason that was chosen was because it seemed as far from um as far from one of the defaults as possible. So this IP table's rule effectively says anyone using this gateway so anyone who's joined my network um that attempts to connect to uh one and two one six eight slash sixteen or ten slash eight translate that to the server's gateway IP address um where we've got a an Apache server or an Nginx server listening. Uh so anything we host on that one seven two IP kind of our server IP address or our gateway IP address is going to be um uh kind of responding directly to any requests to those RFC nineteen AP or our default IP addresses. Um but now that we've got our orchestrator payload done um that submits uh so we now got our orchestrator payload which submits all the requests to the internal IPs and we have now an ability to respond to them all. But at the moment we're just providing the Apache um it works fifty times so we that's no fun. Um but before I get onto the actual payload um I'll quickly mention a fun optimization technique that uh you all like almost all of you probably already know about but I found it really interesting at the time which was if you go to say google dot com um and their page imports a piece of javascript from say the cloudflare CDN um then you go to a totally different website like LinkedIn. If LinkedIn imports the same script from the same CDN your browser doesn't need to make a request for it and it will just load it locally from its own cache. So instead of us having ten thousand lines of javascript sent fifty times we can send it once, cache it um and then have all the other pages look at that particular cache. Um so the number of requests that um that we're sending won't change or the number of responses that we're sending won't change um but the data goes from megabytes to kilobytes um which is what we need to kind of help get uh get increased from fifty to anything more than that. So anyway that's the optimization onto the actual payload. So at the current stage with what we've been through so far I need to create a payload for every different device that we want that I want to target. Um and the targeting projects like PF sense um that's fairly easy since uh we can just download a copy and uh and build our own payloads. Um similarly router interfaces they're they're pretty easy to um if we can just buy one of the routers off ebay. Um but there are plenty of devices that uh that we're not gonna be able to have this level of access to. So instead of building a million different payloads for a million different devices I needed a way of writing a single piece of javascript that was useful no matter what context it was running under. Something that could be used to attack any device in any state. So the first step was relatively easy. Um if the root page looks like a login interface the next step is pretty easy like try and log in. Um and detecting login in pages um thankfully isn't hugely difficult. So there are definitely plenty of options when it comes to detecting login interfaces um but most of them aren't gonna be super reliable. Um so let's let's kind of rule them out uh one by one. So firstly the obvious stuff uh the contents of things like titles, paragraphs and divs that are expected to change based on the device itself. So we can we can rule we can rule those out. Um but that's that's the first step. The next is the the form action. So credentials could be getting sent to to any any URL um or it might not be in the standard location it might not be the form action um at all. Um and same with the various names of the inputs um they could be something specific to the device or it might be in just in a different language. But uh but now we're narrowing it down. So with the input elements themselves um the type value is part of the html spec um and is unlikely to be uh unlikely to be custom. But we don't know whether the interface is gonna be asking for a username um or whether the submit button is handled elsewhere or you just hit enter or whatever um it could be missing like I say it could be missing entirely. But we can expect in 99 percent of cases for there to be an input somewhere of the type password if it's a login interface. So now we have our first check um which effectively fits in our if statement. So if it's a login page um what we want to do we want to log in. Um and we don't necessarily have uh have credentials um or we might not necessarily know credentials but we can just throw like a brute force it's on the inside of someone's network. We might be able to just log in with brute force or it might be already authenticated if um there's already a session that's active. But uh but what do we do if the target device either doesn't require authentication it's already logged in um or if the brute force attempt somehow succeeds um now this is where it gets a bit tricky um so if we see a router we might want to add um like we did before with a add a VPN connection um or extract or change the PSK. If we see a firewall we might want to punch a specific rule through um or if we see a CCTV camera we might we might want to just turn it off entirely but the answer. We can send the logged in interfaces to an off site um neural network trained to identify the most strategically relevant uh next steps when confronted by any uh any device interface um and by that I mean send it to you the human. Um and that was stolen from XKCD um so welcome to the most bizarre stock image I've ever paid real money for. Um now grabbing the uh the authenticated device pages isn't trivial um but thanks to the beef JS project um all the hard work has already been done um so it was surprisingly easy if you ignore the ridiculously hard work that's been put into the beef JS project. So to quickly explain uh that particular project um it was designed as an XSS uh cross-site scripting um exploitation framework by Wade Alcon um so the idea being if you found um like a stored cross-site scripting vulnerability on a page you can build a payload which includes the beef JavaScript hook um then anyone connecting to that page with the hook loaded um effectively gets the script running in their user context um on their machine with their session hooked as well um along with features like metasploit module integration um and integrated browser exploitation that kind of stuff um it's fantastic piece of kit um but the killer feature we want to use um is the ability to tunnel our requests through JavaScript running on the target's browser. So within the context of whatever interesting device that we're targeting um when they're connected back to their own network. And this means that uh when one of our poisoned pages is active we get a callback that we can uh we can tunnel straight to the device uh through the HTTP proxy through um through beefjet JS. So to clarify the the JavaScript tunnel itself runs over the runs over the internet um so we as an attacker we don't see um we don't necessarily need to be on the inside of their network to do this. Um but enough enough diagrams um I'm gonna try and uh see if you can so get a video result of me frantically trying to get this working um like an hour before the deadline to send it to Nikita. So I will try and get this on screen. I look I tape I I taped my notes over the touchpad on the laptop so this is the most awkward thing. Here we go can I full screen this? Yeah cool. So here we see the the victim device on the right um and then two um two laptops performing the attack on the left. So the the one on the far left um is performing the meek of the kind of the authentication and the poisoning um and the one in the middle is just the uh the like it's it's easier to show two screens at once and that's the uh the beef hook effectively. So here they are browsing uh a still uh still HTTP MSN dot com and then we do de-authentication. So then we we boot them off the home network while they're while they're browsing game of thrones. I think I spent too long scrolling through this but you're we're on the journey now you're all in it with me. So after a couple of seconds they should be getting disconnected from uh from their home network um and then this is this is the karma stuff. This is this is just the default karma getting pulled onto my network. So there they are disconnected from the home network um and then it should already be connected to the the fake McDonald's Wi-Fi stuff that's uh that's getting automatically responded to. Again it it's just karma. So far it's just karma as the loading pages. So now the I think after a page refresh the beef JS hook should be in um so it's not the beef JS hook itself that I'm loading in. It's a that that orchestration JavaScript which is loading uh 52 separate beef hooks on those various different router IP addresses. So if there are session cookies that it's hooked into that but uh as far as the user's concerned they're just seeing whatever unencrypted page that they're already on. There we go. So we've got the the beef hook there against uh the particular router IP address. So this is the the Fritzbox login uh the Fritzbox router interface. So in beef you just like right click and set like kind of use as proxy. This is like three in the morning. So forgive me for this not being uh the most kind of nicely cut together thing. So as they're browsing through hopefully a a long article to give you as long as possible to uh to interact with their stuff. They've been sent back to their home network again. So now they're back home with that JavaScript running on that page or any pages that were unencrypted that were opened. And now if we go to so this net this laptop again it's completely not on their network at all but it's proxy through that JavaScript running on the MSN page. I hope it works. I think it worked at the time. There we go. So that that's their internal router um login interface over the internet through JavaScript. Um I mean it's all thanks to beef but uh it's it meant we can now kind of uh we can change the PSK we can do whatever we want on their internal interface. But my uh so there are things that it won't work on like if there's a uh password or whatever on the device. But um I tried it on a on a on an engagement um fairly recently um and managed to access um the data center um fire suppression and HVAC system. Um it wasn't quite fully authenticated but the guest account did have uh right access to everything. Get back into the presentation. Full screen. There we are. So that's the that was the video. Now so this is the the project itself. So at the moment it's uh I've by the end of DEF CON it will be uh it'll be up in public. At the moment it's a combination of bash grips and apologies. So uh I'm hoping in the next week or two it should be kind of a nice relatively seamless piece of python. But at the moment yeah bash grips apologies I'm sorry um one more sorry to add to the pile that are already there. Um just on another separate quick note um something that was kind of funny um during this I found that uh so each of the different browsers if you've got say say for example you've got a router login interface one and two one six eight whatever um you've got your username and password stored um like remembered in um Chrome or IE or Firefox. In Firefox and IE when I when I tested it to use the stored credentials you needed to click from the drop down and select your username and then it would populate the fields and then it would be available in JavaScript and DOM. With Chrome and Chromium it was automatically populated but you needed to interact with the page in some way so if you like kind of left clicked anywhere on the page um then the the credentials would be available in DOM. Um so you could like there was a demonstration where you could uh have like a captive portal that store the credentials that the the inputs didn't need to be visible they could be kind of hidden away in CSS or whatever so you couldn't see them. Um on Firefox you needed to click on it if they weren't there you couldn't click on it so you couldn't use it but on Chrome you could you could just as long as they clicked somewhere on the page um then you'd have them um have the credentials that you could replay back again. Um so I submitted it to the uh the Chromium project um and we got to kind of it was a back and forth and then the kind of the overall consensus was uh yeah it's it's a usability um that kind of the the idea is it's meant to kind of make it easier for people to kind of log in to stuff rather than clicking and clicking on drop downs and completely agree with them like love the guys over there um but then they fixed it like uh so um so uh but I guess it was just like a number of things it was fixed like months and months later but anyway on to on to fixing it uh generally so uh we've seen that it can be realistically exploited but how can we defend against it? So the method that works best in enterprise environments um is accessing devices through DNS names um configuring trusted certificates there's the standard stuff that we do in enterprise anyway um but most importantly disabling the HTTP interfaces um especially if those interfaces work over like direct IP address like if you can connect over IP address directly then it's worth disabling them. Especially for the weird and wonderful like uh uh kind of like the scar that I say scar like especially like the the weird and wonderful um random stuff that's on the network. Um and for home users and uh and residential vendors um simply disabling the HTTP interface entirely and um having only HTTPS listing um it should be enough to stop the attack working on a mass scale um since no one is clicking through or I hope no one's clicking through uh 50 separate certificate warnings on the same page um but it still means it would be possible to target a specific a specific device um but it defangs the attack significantly. Um another potential um is the the wider adoption of IPv6 um since there are so many more addresses than IPv6 um local addresses don't necessarily need to be shared between um between networks um and that isn't really no that doesn't really exist in it. So uh but if if vendors still use like a common set of defaults um instead of using kind of unique ones um then the attack could potentially still be viable. And the final one is WPA v3. So based on the spec um and what if kind of a few other people have been through um so far the camera attacks still looks to be technically possible um so protected management frames um are enabled by by default so you can't trivially boot someone off their own network um but there's still the potential um as far as I can see for kind of just the good old fashioned signal to noise ratio um jamming um and as far as I understand the spec open networks are still a thing. So keys are generated and negotiated so there's no kind of unencrypted communications um but there's no uh trust on first use mechanism so uh it still it might still be possible to uh if for example you connect to McDonald's underscore Wi-Fi and connect to a different McDonald's underscore Wi-Fi there's nothing there saying this isn't the same network that you've seen before. Uh but it's largely conjecture anyway like I don't have any WPA 3 devices um and this is this is based off like other people going through blog posts uh other people going through the spec um and me reading their blog posts so it roughly makes sense. But and that brings us to uh towards the the end of the adventure um I think we have uh a few minutes left on the clock so uh if there are any questions.