*Disclaimer: The views, thoughts, and opinions expressed in this post are the sole views, thoughts, and opinions of the author in their personal capacity. The following is a representation of the author and does not reflect the views, thoughts, and opinions of any other entity, to include those of the author’s employer and shouldn’t be taken as such.
**Update May 14th, 2021. After further reviewing additional reports that were released after this post was published, I determined that CVE-2020-24586 needed to be downgraded from “Not Vulnerable” to “It Depends”. Cisco revealed by way of a Cisco Security Advisory that the Catalyst 9130 AP was in fact vulnerable to 24586. I had relied on Table 1 from Page 11 in the official report which indicated that the 9130 AP wasn’t vulnerable to that specific one. I give credit to Cisco for releasing this information which can be found here. Cisco has assigned this their own internal ID of CSCvx24456. I don’t blame the researchers for this but in my mind points to just how complex these attacks can be.
For the third time in the past 3 and a half years, Wi-Fi and the vulnerabilities with Wi-Fi are back in the spotlight. Starting with KRACK in October of 2017, then Dragonblood in April of 2019, Mathy Vanhoef (NYUAD) is back again with the FragAttacks of 2021. FragAttacks stands for FRagmentation and AGgregation Attacks and to be fair to Mathy, based on the CVE’s that are included in his report, he was ready to go public in 2020 but he chose the route of responsible reporting; allowing all those affected the time to get their ducks in a row and have responses ready for when the news went public.
May 11th, 2021, is that date that his work went public.
Before getting into the report a little more, I need to stop and give props to Mathy and the folks he is working with. The stuff that they are finding is some pretty critical vulnerabilities and things that need to get corrected. Also, especially with this latest report, some of the things they are finding are beyond technical. I mean, get down in the weeds with a pair of tweezers and pick at things with a microscope type of technical. I can tell you one thing, they have a lot more patience than I do!
With that in mind, there are some things I want to talk about. I’m not going to go into details about everything, the report is that technical that if you want to, you can go read that here. First off, NONE of the 12 CVE’s contained in this report are against the encryption or the cryptography used in securing Wi-Fi (at least not the current versions with the fixes and patches and yes, WEP is still broken). This report covers the way in which 802.11 devices receive, store, and process frames that are transmitted using the 802.11 protocol. A lot of these vulnerabilities appear to have been around for a while (since 1997 a while) so this report really hits at the heart of how Wi-Fi has been operating all this time. The report surmises one reason why it has taken this long to discover and while their reasoning might play a part, I have a different reason I would purpose:
Wi-Fi is hard enough to just get working, and then working well, that none of us have the energy to try and break it and figure out what it might be doing that isn’t quite copasetic, and then figure out how someone could abuse that to make things worse.
Jim Palmer – About halfway through reading the report
From a high level, let me try and surmise what I take from this report.
Fragmentation and Aggregation
Ethernet, especially Ethernet over wireless (802.11), requires devices to break down the data it wants/needs to transmit into manageable chunks before transmitting. For those new to networking, that is generally described as the Maximum Transmission Unit, or MTU size. Maybe you have heard of it. When this happens (data being broken down to fit the MTU size) rarely does the data being transmitted fit precisely into the packet or frame that is carrying that data. While some packets/frames are full, others aren’t. Also, especially in Wi-Fi, not all the “stuff” that needs to be sent will fill up a frame (that’s the basis of Wi-Fi 6 really) so there are a lot of “not full” frames happening. Lastly, while data is transmitted over the air, the receiving device will hold any fragmented data until it gets the full payload before doing anything with it.
What was discovered that when this fragmentation happens, there are vulnerabilities with how the devices receive and store these fragments so if exploited at the right time, it could change the way the device aggregates that data, and in some scenarios, causing the device to do something different than the user intended.
What happens is when devices are receiving fragments of data, and storing it until the rest comes in, there are processes and checks that we all assumed that were happening that are in fact, not happening. Combined with the extra space left in the frames that weren’t completely filled, Mathy Vanhoef figured out a way to exploit that.
- CVE-2020-24588 – Accepting non-SPP A-MSDU frames. Attackers can exploit this and get devices to aggregate frames that appear to come from the same source, but don’t, allowing for manipulation of the payload.
- CVE-2020-24587 – Reassembling fragments encrypted under different key. Turns out, a device will cache, or store, fragmented frames waiting for the final frame, and will accept that final frame under a different encryption key.
- CVE-2020-24586 – Not clearing fragments from memory when (re)connecting to a network. That cache from right above? Turns out an attacker can drop some extra bits and bytes into a frame that is being stored by the device (waiting for the rest of the fragmented data) so when it does finally reassemble it, even after disconnecting and reconnecting to the network, it’s not as pure as the wind driven snow, if you get my drift.
- CVE-2020-26146 – Reassembling encrypted fragments with non-consecutive packet numbers. Again, something that sounds like a no brainer to wired folks, is happening in Wi-Fi. We expect that things might arrive a little out of order (multi-path and spatial streams type stuff) but how the device is processing these received frames isn’t as logical as one might hope.
- CVE-2020-26147 – Reassembling mixed encrypted/plaintext fragments. Yup, about as bad as it sounds, a device will accept and then aggregate encrypted and plaintext fragments. Encrypted from an AP, plaintext from a random stranger, then combine together. Not a good thing.
- CVE-2020-26145 – Accepting plaintext broadcast frames as full frames (in an encrypted network). An attack more targeted at client devices, they are accepting broadcast frames (or at least frames that are crafted to say they are broadcast frames but are really data frames) and processing them anyways, and in plaintext from whomever.
- CVE-2020-26144 – Accepting plaintext A-MSDU frames that start with an RFC1042 header with EtherType EAPOL (in an encrypted network). RFC1042 identifies handshake frames. Similar to the broadcast attack, devices are accepting and processing frames with blind trust on the flags in the headers (flags are how our tools know to categorize a frame as broadcast, data, management) which can be abused.
- CVE-2020-26139, 26140, & 26143. These three CVE’s deal with how devices will accept plaintext fragments of frames, even in a protected (encrypted) network and then do something with them when aggregated back together. Forwarding packets to other devices within the same WLAN being one of them. In certain APs (NetBSD 7.1), they are accepting these frames from unauthenticated devices and still forwarding them to authenticated devices on the same network. Nice little workaround to not being able to break encryption.
- CVE-2020-26141 – Not verifying the TKIP MIC of fragmented frames. If, for some unknown reason you are still using TKIP, here is another reason why it’s not a good idea. Seeing as the first reasons should have had you running away from TKIP, here is a security reason. Maybe now you finally have a good excuse (I hope) to not use it.
- CVE-2020-26142 – Processing fragmented frames as full frames. Certain APs (APs running OpenBSD 6.6) don’t support A-MSDUs. Granted, A-MSDUs feature a lot in this report since any device certified as Wi-Fi 4 (802.11n) is required to support it. This CVE is for that weird place where devices don’t support A-MSDUs, don’t know what a fragmented frame is, so it treats all frames as non-fragmented frames, meaning that if you could socially engineer the target to navigate to a specially crafted URL while connected in this scenario, an attacker could exploit this.
Not to sound like Chicken Little and screaming that “the sky is falling” but some of these exploits are both ingenious and scary all at the same time. If you deal in Wi-Fi as a professional, you need to take some time to read this report. Then read it again, then read it again and this time take notes. Talk to others and make sure you have a handle on what is going on.
Vulnerabilities were found in Enterprise grade APs, consumer grade APs (the kind routinely found in homes), as well as all types of client devices. By my count, 25% of the CVE’s listed in this report can be carried out by targeting the receiving client device alone. That means that a network administrator can do EVERYTHING right (patching their infrastructure, deploying the highest enterprise security, and have a full WIDS/WIPS implementation in place) and if the end user has a vulnerable device that they haven’t patched, they are still at risk.
This leads me to patching. Yes, there is going to need to be a bunch of patching going on. Patches are going to need to be done on both client devices as well as the AP side. Now for the bad news. Not all devices are going to have patches available today, or next week, or even in the next month. For those who specialize in Wi-Fi the answer to why this is the case will come as no surprise. For everyone else, hang with me.
It Depends™
Yes, there it is, the ever present hallmark of a Wi-Fi professional. The answer that is worth nothing. Truth be told, it pains me to even type it. This also factors in later, so I’ll try to expand on this topic some.
As me and some co-workers struggled to really understand and figure out what it happening, in order to fix it, there became a pretty graphical answer to our struggle, and I will share it here.
You see, in the report, the researchers tested on a couple of APs (three in total) that we would consider “Enterprise Grade” as well as some consumer grade APs and client devices. I’m a super nerd so I didn’t pay attention to those devices. For me, I focused only on what I could help with, and that is Enterprise grade. That included two APs that are 802.11ac Wave 2 and one AP that was 802.11ax. I don’t fault the researchers here, but it does lead to some opportunities I will discuss later. No, what I noticed coming out of a lot of testing (thanks to the research team for making the tests available) were results that for the most part, were inconsistent across the board.
For a lot of people, Wi-Fi is Wi-Fi is Wi-Fi. However, in reality it is lot of moving parts. There are the chipsets the APs are based off of, the vendor firmware, how that is tied together, and then the secret sauce poured over that stack to make people buy one product over another. That doesn’t even count configuration issues I will get into later. Then, I want you to factor in generations of APs that need to be supported. When I combined all of this testing, across scores of variables, into a chart, what I found was the classic case of “Whack a Variable” that complicates things greatly.
Of the twelve CVE’s, only two one had a clear answer. All of the testing I could find, internal and now other vendors reports, including the researchers from their paper, only CVE-2020-24588 was vulnerable across the entire mix of moving parts. No matter what was changed, the Enterprise grade APs still had that problem. CVE-2020-24586 was subjected to the same mix of moving parts, and originally from the test results I saw, none of those mixes resulted in an Enterprise grade AP being vulnerable. HOWEVER, when Cisco released their official report on their website, found here, they indicated that the Catalyst 9130 AP was in fact VULNERABLE to 24586. The researchers themselves indicated in their report, in Table 1 on Page 11, that the 9130 wasn’t vulnerable. Cisco doesn’t agree. I tip my hat to Cisco for coming forth with this report truthfully. To me it also reinforces how complex these attacks are that the researchers missed a result that Cisco found.
The rest of the results? Yeah, that got confusing.
While some vulnerabilities were there for the majority of tests, there were times when the mix was just so that there was an instance of not being vulnerable. In other cases the vulnerabilities weren’t there for the majority of tests, but in certain circumstances, with the right unfortunate mix of variables, the vulnerability existed. For those instances I had to use “It Depends” because really, it depended on the mix of variables tested. Then, there are the last two CVE’s. I’ll be honest with you, I didn’t have enough data to make a firm call on if APs are vulnerable or not. I “think” they aren’t, but without definitive proof from all the tests, I had to use the “Maybe”. Since the researchers only found a select configuration of their own variables that were vulnerable to this, I am leaning towards more green than yellow, but thanks to the other tests showing a firm mix of possibilities, I’m not ready to rule those out.
Most non Wi-Fi professionals don’t realize that Wi-Fi 5 (802.11ac) had 2 “waves”, if you will, and that means different chipsets in the AP. Between the 2 waves of Wi-Fi 5, Wi-Fi 6, and then still a fair number of Wi-Fi 4 APs in use, that alone means most AP vendors have, at minimum, 4 generations of APs to test against 12 different CVE’s. Different chips, different firmware, different results. What does all of this variability mean in the end? It means that testing with Enterprise grade APs is harder than it sounds. I think we have an opportunity here actually to help them out, at least a little.
Then the question is how far back to go? The researchers tested Wi-Fi 6 and second generation Wi-Fi 5, where as ALL the Wi-Fi generations are still supported in one way or another. First generation Wi-Fi 5 and Wi-Fi 4 are very much in play, and in some locations, even 802.11g is still in play. I’m not even touching 802.11b. This is also on the client side as well as AP side. It also means there are a TON of patches to write from the chipset vendor side, test, provide to device vendors to be wrapped and manipulated, then tested again, and then finally released. That is a TON of work that has to be done, and it is going to take a TON of time. That is why not every device is going to have a patch available on the first day. It is just an economy of scale.
Now, with that being said, I need to take some issues with other parts of this report.
No, the Sky is NOT Falling!
While the vulnerabilities that deal with how a device will receive data from some random source and still process that frame scares the crap out of me, there is still one thing to keep in mind. All Wi-Fi attacks, and I do mean ALL Wi-Fi attacks, have a limited radius of vulnerability. What I mean is that an attacker needs to be close to you to pull this off. Someone with their Wi-Fi contraption in Cleveland can’t hurt me in Denver. Hell, someone with their Wi-Fi contraption in Denver can’t hurt me because I don’t live in Denver, I live just outside Denver. What I’m saying is they need to be CLOSE to do any of this.
Next, these attacks are not trivial to pull off. Some of these attacks are multifaceted and require both a Man-in-the-Middle type position in conjunction with a social engineering front (getting the end user to navigate to a specific website with a specific length of URL) AND all of this has to happen in a specific order to pull this off. While possible, I put some of these attacks into the “Not Probable” category. If you are being targeted by a Nation State with teams of highly skilled attackers, then you might need to be concerned.
Side note here. If you are the target of a Nation State with multiple teams of Advanced Persistent Threat (APT) groups then I might not be your best source of advice so I would maybe go talk with someone else, and sooner than later. Just sayin’.
Really, my point here is that most of these threats are not the “smash and grab” type attack. These attacks play the long game so their appeal isn’t as wide as something that allows an attacker to crack password hashes and start decrypting data over the air. Again, WEP is still broken, and has been, since 2004 and NO ONE IS GOING TO “FIX” IT!
That leads me to my final rant, and then an offer.
How Things Work
As I read the report, this line from an esurance commercial kept coming to mind. And I mean it came to mind A LOT!
Courtesy of any number of meme generators out there
So, in no particular order, my rant.
WEP and TKIP
No offense to the research teams, but WEP and TKIP? Really? WEP was broken in 2004 and TKIP has a limitation that causes any network that’s using it to slow down to 54 Mbps. If you are unfortunate enough to have to use WEP and TKIP because of legacy devices you are forced to support, use this report to show how vulnerable this makes you and get devices that were manufactured some time in the past decade. That’s right, try to upgrade to like 2010 or something.
Also, when can we stop dragging this dead weight behind us as Wi-FI professionals? I mean, it’s like a bad dream. We don’t expect car part stores to stock every part for a ’57 Chevy, why are we being asked to defend these things? Might as well throw 802.11b in there for good measure. We need to get this legacy scruff cleaned up.
Period. End of Statement.
I really want to hate on the researchers right now but they didn’t write the rules so it really is fair game.
Hotspot 2.0 ≠ Hotspot
In some of the vulnerabilities, the researchers chose to somehow compare Hotspot 2.0 and/or eduroam networks with the network at your local coffee shop or restaurant. While not explicitly stated, here are 2 excerpts from the report from sequential paragraphs:
“Vulnerable APs. Our attack will exploit vulnerable APs in hotspot-type networks such as eduroam, and Hotspot 2.0 networks…”
Followed by this paragraph:
“Vulnerable clients. We assume the client will connect to a protected Wi-Fi network of which the adversary also knows the password.”
I hate to break it to people, but that isn’t how Hotspot 2.0 or eduroam works. There isn’t a big poster on the wall with a password for the Wi-Fi that hasn’t changed in 3 years for these networks. The report then goes on to explain how an attacker, armed with this never changing password information, can establish a MITM position by emulating that “hotspot” network and fooling the target device into connecting with that MITM AP.
That’s not how Hotspot 2.0 or eduroam works. That’s not how ANY of that works!
SSID ≠ BSSID
This sounds weird if you are a Wi-Fi professional (or even Wi-Fi hobbyist) but give me a minute.
“To attack a client, the adversary first spoofs the MAC address of the trusted (company) network but advertises the SSID of the untrusted (coffee shop) network. …Once the client connected to this rogue network, the adversary injects fragment Frag0(s) into the victim’s memory. This packet contains the packet to be injected. …the client is disconnected from the untrusted network, after which it connects to the trusted (company) network. While the client is connecting, the adversary establishes a multi-channel MitM position between the client and the AP.”
That is just stage 1 of a 2 stage process to exploit the vulnerability listed in CVE-2020-24586 in a client device. Stage 2 starts with the attacker waiting for a specific numbered fragmented frame (the injected fragment number from above plus 1 number) to be sent so it can intercept that frame, inject a modified payload, and then send it to the client. The example given in this attack is to trick the end user into using a malicious DNS server.
To be honest with you, I am at a loss for words. I mean, devices use the BSSID (the “MAC address” of that Wi-FI network) for a number of things, but I have yet to hear of a time when a device relied solely on the BSSID seen as a method to establish “trust” on that network. Maybe someone else has an idea here, because I don’t. I change my APs at my house out all the time (drives my family INSANE by the way) so the devices will see more than their fair share of BSSIDs, all using the same SSID. Not once has any of those devices said “Wait! That’s a BSSID I’ve seen before so even though nothing else matches, I will treat it like that WPA2-Enterprise network I use a lot of the times!”
If a corporate network is sophisticated enough to trust one network over another, and limit what is allowed on that network, simply spoofing the BSSID of a corporate resource isn’t going to work. Besides, if that network is that sophisticated, it’s going to have some other things happening as well that I will cover in a minute.
That’s not how that works. That’s not how ANY of that works!
Not all EAP Types are created equal
Anyone who has gone through the CWNP CWSP (Certified Wireless Network Professionals, Certified Wireless Security Professional) training knows this, or at least should know this. Not all EAP types are the same. The one type called out in the report, EAP-PWD, was one I had to go look up. While looking it up I found a report on Dragonblood, which features EAP-PWD and the 7 known CVE’s against that EAP type. Also included in the Dragonblood report from April of 2019 is this line:
That report might sound familiar because I mentioned it in the opening as the second paper that Mathy and the team published. While their reliance on their one known EAP type might not be a problem for them, I had a hard time when I realized they used an EAP type that they had already exploited, and known about, instead of any of the other EAP types. While there are some EAP types that aren’t as secure as we (the Wi-FI community) would like there are some EAP types we consider very secure. They offer a function called “Mutual Authentication” where the client device will also authenticate the network that it’s joining, and not just using a PSK type 4-way handshake.
It’s at this point I need to take off my “Angry Jim” hat and put on my “Olive Branch of Peace” hat and make an offer to the team. You probably haven’t taken any of the courses from CWNP, but there is a community of people that have. We might not be as big as the security community, but I can tell you we are just as passionate about what we do as any technology group out there. Next time you start to work on this, please reach out to us and ask for help. We love to help and explain and teach people all about Wi-Fi, and personally I want to help you guys. You think differently than us, and that is a good thing. Just let us help you as you help us. I’m on Twitter @WirelessJimP and my DMs are open. Or send me a message through here. If not me, then I can get you in contact with someone else.
I think together we (the security professionals and Wi-Fi professionals) can do some amazing things.
Simplicity is not the watchword
Most of the vulnerabilities in this report require multiple things to happen for any attack to be successful.
- The target device needs to be vulnerable to the attack.
- The target network needs to be vulnerable to the same attack.
- In some instances, the client device, the network configuration, and the infrastructure AP needs to be vulnerable.
- MITM positioning features extensively across the report. While it sounds simple, in practice in a mature network, maybe not so much. Remember that mutual authentication line from a minute ago? Yeah, while not all EAP types have a yes in that category, more than one type does mutual authentication. You can get as many antennas as you want sticking off your rack of Raspberry Pi’s mounted in a backpack and if you ain’t got the right creds, that client won’t fall for your trick.
- BEAST threat model. This one took me forever to figure out. It’s a social engineering attack. Some attacks will work with just the BEAST threat model, while others require the MITM and BEAST to work. For someone who has never seen the Dynamic Coordination Function drawn out in a flow chart (Thanks Peter!) that is a lot of moving parts (DCF, MITM, BEAST) to get lined up so you can execute the attack.
- Time is not on their side. While executing attacks like the ones explained in the report are probably easier in a lab with a network designed for the attack, the real world isn’t like that. Most security researchers are used to being able to attack from anywhere on the internet, and do it without being seen. Literally getting into the middle of an RF network, and then hanging out there why you advertise a corporate SSID for a while in an attempt to set up the rest of the attack is easier said than done. If the value of the target is that high that you are willing to risk that approach, I’m guessing someone is going to notice you and call security. “See something, Say something” has changed not only transit locations.
Now, none of this is to say that we shouldn’t be concerned about what they found. We should be, and we should definitely fix these problems. I will state again that I have the utmost respect for what they are doing and what they found. I also greatly respect them for reporting these in a responsible manner. I also hope that in the future maybe we can work together to build a better solution for everyone.
What can be done?
Like I mentioned earlier, some of these vulnerabilities are serious, and updates and patching will need to be done. Look for these patches and the corresponding notifications. Just be prepared that some of these patches might take longer than others. Like I was talking about earlier, devices are affected differently across the 12 CVE’s (at one point, 68 device combinations were reported as being tested) and not all devices are susceptible to the attacks the same way. It’s confusing, so admitting that you are confused is not a shame.
Next, there are some things that can be done to help out, now and in the future.
- Keep your devices updated and patched. I used to think updates were just a way to take up more room on my device for things I didn’t use, but not any more. Some of these attacks are directed from the attacker directly to the target, and nothing I mentioned is going to help you out in this case. Get your devices updated and then tell all your family and friends to update their devices.
- 802.11w – Protected Management Frames. This is a tool that we have had in our belt for a while, but thanks to a lack of client side support, it’s still not widely implemented. Even the researchers call out that there is a mechanism in place to prevent knocking clients off of networks (step 1 for a MITM attack) but that it isn’t widely used. Their assumption, and rightly so, is that thanks to this lack of implementation a MITM is still a feasible approach.
- WPA2/WPA3-Enterprise Security. If it’s a device you care about, and care about the data it sends, use some security that cares as much as you do. Pick an EAP type that does mutual authentication of the network. Better yet, pick a device that can do WPA3-Enterprise because that requires 802.11w. With those combined, you can have a network that protects against random disassociation frames from random devices and even if an RF attack (like an AirHORN) is used, the device still won’t associate to just any AP, mutual authentication ensures it only associates with the network they should be associating to.
- Looks at a WIDS/WIPS solution. Upgrading security and enabling 802.11w is a long-term approach that takes planning and investigation and for your network isn’t something that can happen overnight. While using both this and the KRACK vulnerability from earlier is helpful to convince your organization that it is time to make that move to improved security, WIDS/WIPS is a “faster” solution. For any CommScope RUCKUS networks, I have great news for you! WIDS/WIPS is a built in solution that is free to enable on SmartZone and Unleashed. Granted, the RUCKUS WIDS/WIPS might not be the most robust WIDS/WIPS solution on the market today but you can’t beat the cost and certain key alerts that are there. The hallmark alerts of a MITM attack you are looking for are:
- SSID Spoofing – Unknown AP beaconing the same SSID as a managed SSID.
- MAC Spoofing – Unknown AP beaconing the same BSSID as a managed SSID.
- Deauthentication Flood – An abnormally high number of deauthentication frames from the same transmitter.
- Disassociation Flood – An abnormally high number of disassociation frames from the same transmitter.
- Another feature for RUCKUS networks is DPSK. If every device has a unique password to join the network, there isn’t a poster or website to look at to find that never changing PSK passphrase. I happen to know of something in the works around that idea that is actually REALLY cool, so stayed tuned for that!
- Social Engineering awareness/training. Some of these attacks require a little social engineering go on to make the attack work. Social Engineering, including phishing and vishing, are really the preferred method of intruders gaining access to your network and information and/or introducing malware/ransomware into your network. Some of us make fun of the phising training we see but unfortunately it is still on the rise. Talk to co-workers, friends, relatives, and especially older relatives, about being suspicious about emails and calls. It’s the success of these attacks that is lowering attackers reliance on MITM style attacks, but if both are needed to work, for me that might be a bridge too far.
Final Thoughts
If somehow you made it this far, I feel for you. The vulnerabilities described in the paper are complicated, and figuring out the report wasn’t any easier. Like I said in the beginning, I think the reason no Wi-Fi professional has done the type, and amount of work, that Mathy has done is simply because trying to get Wi-Fi right is not an easy task and we spend so much time trying to get it right, the idea of breaking it apart to look for things we might find just isn’t in our blood. We are builders, not hackers, and there is no shame in that.
I also want to extend the offer to not only Mathy and his team, but to any security researcher. There is a Wi-FI community, albeit not as large as the security community, and we are here to help you as you help us. Certified Wireless Network Professionals is a great place for agnostic Wi-Fi training and learning about Wi-Fi, and the Wireless LAN Association is a group of Wi-Fi professionals that are always eager to share our knowledge. I’m a member of both because I really do care about Wi-Fi. If anyone has questions about these organizations, feel free to reach out to me. Also, if anyone would be gracious enough to forward this to Mathy, I’d appreciate it!
At the end of the day Wi-Fi continues to be a tradeoff. We tradeoff channel width for number of channels, speed versus capacity, and ease of use versus security. The fact that devices work at all is still an amazement. A traveler can get off a plane in any part of the world, turn on their Wi-Fi, and if there is an AP beaconing, it can try to make it work. There is usually come other component above Layer 3 that gets in the way (like navigating a captive portal or getting a text message password in a country you don’t have cell service) but the Wi-Fi part WORKS! Sure, as security researchers continue to look into this weird way that we do things (remember, there are a lot more of them than there are of us) there are going to be more discoveries about more vulnerabilities. I don’t know when, and I don’t know what, but I know it’s coming.
The idea of turning off Wi-Fi and not using it has long since passed and no, I don’t care what the 5G cellular commercials say, they can’t handle what Wi-Fi can handle. What we as professionals need to do is make sure that the networks we design, and the people that are using them, are not using outdated standards from 2003.
I Don't Know Squat About Networking 
111 comments